unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, dmantipov@yandex.ru, emacs-devel@gnu.org
Subject: Re: Dumper problems and a possible solutions
Date: Wed, 25 Jun 2014 18:07:58 -0400	[thread overview]
Message-ID: <20140625220758.GE179@brightrain.aerifal.cx> (raw)
In-Reply-To: <jwvbntgsmb5.fsf-monnier+emacs@gnu.org>

On Wed, Jun 25, 2014 at 05:43:00PM -0400, Stefan Monnier wrote:
> > With the approach of dumping a C array containing references to
> > offsets within itself, this is completely transparent to the
> > application. The linker (ld) produces the right R_${ARCH}_RELATIVE
> > relocation records in the data segment and the dynamic linker applies
> > them at runtime.
> 
> Two problems, here:
> - we're still talking about performing relocation of all heap references
>   during startup (not that it's a problem, of course).  Maybe we don't
>   need to do it ourselves, but it still has to happen.

Indeed. The difference is just between having to write non-portable
code that does it manually, and having it happen automatically as
consequences of the requirements of the C language.

> - Can the ld.so loader generate the *tagged* references used in the heap?

My understanding is that the tagged references are using the low bits
of otherwise-aligned pointers as flags. Is this correct? If so, then
these are just constant offsets applied to an address, and thus they
are still valid C address constant expressions, so they have to be
supported.

My understanding is that emacs also supports a mode for targets where
alignment up to 8 bytes cannot be guaranteed, where the high bits of
the pointer are used rather than the low bits, and where all pointers
are required to reside in "low addresses". This should also be able to
be supported at the dynamic-linker level as an addend. But at the C
source level, it's undefined behavior since the offsets go outside the
range of the array object. Of course this model is also incompatible
with PIE and with most modern systems where malloc may return "high"
addresses, and thereby likely buggy even on the systems it's currently
used on (if any). It could probably be fixed by using mmap to ensure
that the entire "high" memory space is filled with PROT_NONE mappings
before doing anything else, though, but I think fixing this build mode
is low priority since, in practice, all modern targets support 8-byte
alignment.

Rich



  reply	other threads:[~2014-06-25 22:07 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-24 17:19 Dumper problems and a possible solutions Rich Felker
2014-06-24 19:27 ` Stefan Monnier
2014-06-24 19:40   ` Rich Felker
2014-06-24 20:24     ` Stefan Monnier
2014-06-24 21:15       ` Rich Felker
2014-06-24 21:37         ` Stefan Monnier
2014-06-25 18:03 ` Dmitry Antipov
2014-06-25 18:08   ` Rich Felker
2014-06-25 18:30     ` Dmitry Antipov
2014-06-25 18:36       ` Rich Felker
2014-06-25 18:36       ` Eli Zaretskii
2014-06-25 18:41     ` Eli Zaretskii
2014-06-26  0:16     ` Stephen J. Turnbull
2014-06-25 18:20   ` Eli Zaretskii
2014-06-25 18:32     ` Rich Felker
2014-06-25 18:49       ` Eli Zaretskii
2014-06-25 19:03         ` Rich Felker
2014-06-25 19:18           ` Eli Zaretskii
2014-06-25 19:57             ` Rich Felker
2014-06-25 20:15               ` Eli Zaretskii
2014-06-25 20:34                 ` Rich Felker
2014-06-26  2:44                   ` Eli Zaretskii
2014-06-26  4:28                     ` Rich Felker
2014-06-26 15:02                       ` Eli Zaretskii
2014-06-25 20:11             ` Stefan Monnier
2014-06-25 20:06           ` Stefan Monnier
2014-06-25 20:24             ` Rich Felker
2014-06-25 21:43               ` Stefan Monnier
2014-06-25 22:07                 ` Rich Felker [this message]
2014-06-25 23:04                   ` Paul Eggert
2014-06-25 23:21                     ` Rich Felker
2014-06-25 23:05                   ` Stefan Monnier
2014-06-25 23:19                     ` Rich Felker
2014-06-26  3:02                   ` Dmitry Antipov
2014-06-26  4:14                     ` Rich Felker
2014-06-26  4:32                       ` Dmitry Antipov
2014-06-26 11:49                         ` Rich Felker
2014-06-26 15:03                         ` Eli Zaretskii
2014-06-26 15:10                           ` Rich Felker
2014-06-25 22:33               ` Andreas Schwab
2014-06-25 20:53       ` Samuel Bronson
2014-06-25 21:24         ` Rich Felker
2014-06-25 18:38   ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140625220758.GE179@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=dmantipov@yandex.ru \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).