[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dumper problems and a possible solutions

From: Rich Felker
Subject: Re: Dumper problems and a possible solutions
Date: Wed, 25 Jun 2014 18:07:58 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]