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: ld-elf/exclude1.s, exclude.exp


On Tue, 19 Oct 2004, Daniel Jacobowitz wrote:
> On Tue, Oct 19, 2004 at 12:57:02AM -0400, Hans-Peter Nilsson wrote:
> > On Mon, 18 Oct 2004, Hans-Peter Nilsson wrote:
> > Hmm.  I don't know what you're trying to test here (hint:
> > missing comment), but it seems use of include_sym is important
> > due to its globalness.  Strange: this isn't really a PC-relative
>
> Hint: it's in the .exp file.

Well, duh...  I mean, if there was a test-specific reason the
code was written the way it was *besides* the things told in
exclude.exp, and not just confusion.

> Yes, the globalness is important; we need to verify that the one symbol
> was exported and the other wasn't.

Right, but subtracting one global symbol from an unknown isn't
what you wanted.  It seems you realized it, but for told for the
record: what you wanted is either or both (I couldn't tell
which):

	.globl include_sym
include_sym:
	.long	include_sym - .

(a PC-reloc for a global symbol defined in this object file,
a definition which can be overridden for PIC.)

or:
	.long	exclude_sym - .

(a PC-reloc for a global symbol, undefined in this object)
because (as you mentioned) ELF does not support a relocation for
two symbols.  The definition of include_sym should be treated as
an unknown wrt. the relocation, supposedly flagged as an error
as H.J. saw.

> > reloc;  another DSO or the executable should be able to override
> > include_sym and I don't see how that could work for any normal
> > ELF target.  Let's include exclude1.s for completeness:
>
> Yeah, I've been wondering a little about that.  I believe gas defines
> the thing on the right side of the relocation to be locally bound

A bug!  A bug I say!

> (in
> fact, it has to be defined in the same .o - no other way to represent
> it).

For PIC, it should be flagged as an error.  Some targets require
GAS options to describe this PIC-specific quirk to GAS, so that
GAS doesn't optimize away relocs for "known" symbols.  Maybe
that's why you didn't see an error for the target you tested.

> In any case I've verified that cris-linux now passes with HJ's changes.

Thanks.  (BTW, what I wanted to check was cris-*-elf, slightly
different: no PIC, but it's covered too, according to autotester
logs.)

brgds, H-P


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