This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: BFD questions
- To: tm2 AT best dot com
- Subject: Re: BFD questions
- From: Ian Lance Taylor <ian AT zembu dot com>
- Date: 17 Sep 1999 16:50:48 -0400
- CC: binutils AT sourceware.cygnus dot com
- References: <199909171904.MAA18892@shell14.ba.best.com>
From: Toshi Morita <tm2@best.com>
Date: Fri, 17 Sep 1999 12:04:06 -0700 (PDT)
> Is it possible that the attribute refers to a symbol in a section
> which was removed because it was a linkonce section? Or is it
> possible that you are building a shared library and the attribute
> refers to a symbol which is not defined in the shared library?
Could be a linkonce section, but is definitely not a shared library.
Shouldn't LD remove symbols referencing deleted copies of a
linkonce symbol?
Yes, it should. However, I'm thinking about the case where we have a
relocation in a .debug section which refers to a symbol which has been
deleted. The symbol doesn't have a value. We can't simply remove the
address being relocated, because who knows what that would do.
I don't know if this is the problem. It's just a thought.
> As far as I know, the linker has no special handling for DWARF. It
> simply applies the relocations it finds in the object files.
Oh duh, I think I understand what you mean now.
So basically the problem could be in several places:
1) GCC could be emitting something weird (non-symbolic) for the AT_pc_high
field of a TAG_global subroutine (unlikely)
2) AS could be failing to emit a relocation for the symbol (possible)
3) LD could be failing to fixup the relocation for the symbol (possible)
Correct?
Yes.
Ian