This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [davidm@napali.hpl.hp.com: Re: [PATCH] i386 vsyscall DSOimplementation]


Jim Wilson wrote:

 On Sat, 2003-06-14 at 21:19, H. J. Lu wrote:
 > Under what condition will the offset between 2 segments change? Even
 > with shared library, I don't think the offset between 2 segments
 > will change.

 I dunno.  I'm not an expert with this stuff.  However, I do believe that
 there are systems that will load segments and then relocate them.

This is indeed the case.  HP-UX does that, as would any other
single-address space OS, because they can't have two segments with
different contents at the same address.  So the text segment will get
loaded at a particular (fixed) address and the data segment will get
at some different (non-fixed) address.

Jakub wrote:

 > You certainly cannot change the distance between 2 loadable
 > segments.  If you did, it would e.g. break all @gprel relocations
 > in one of the segments, so I don't see why segrel shouldn't be
 > supported accross segments.

Actually, @gprel relocations between segments are also illegal.  We
used to have them in some GCC startup bits, but then removed them
because it was causing grief for gcc/ia64 on hp-ux.

Having said all this, of course for the particular case that we need
the cross-segment segment-relative relocations, we know that the
distance between the two segments in question will never change.  So,
yes, we're invoking behavior that's undefined according to the psABI,
but the patch makes sense because it converts useless behavior into
something useful (I suppose if we wanted to be paranoid, we could
issue a warning when such relocs are encountered).

	--david


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]