This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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]

[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).



------- Comment #5 from mark at codesourcery dot com  2007-04-07 00:01 -------
Subject: Re:  [4.3 Regression] ld: Invalid symbol type
 for plabel (.libs/debug_list.o, __gxx_personality_v0).

dave at hiauly1 dot hia dot nrc dot ca wrote:
> ------- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2007-04-06 23:44 -------
> Subject: Re:  [4.3 Regression] ld: Invalid symbol type for plabel
> (.libs/debug_list.o, __gxx_personality_v0).
> 
>> That would emit the reference only in situations where we're actually
>> going to need the personality routine.  The reason for my earlier change
>> was that we were referencing it even when we'd optimized away all of the
>> EH information in the module.  I'm sorry this broke HP-UX; let me know
>> if I can help.
> 
> I must admit I'm to blame for this ;(
> 
> Importing functions that aren't used doesn't cause a problem on HP-UX,
> but I can see that it might cause the routine to be unnecessarily included
> in an executable on other systems.

Yes, the standard behavior for GNU as/ld on ELF systems is that a .globl
emission in the .as file becomes an undefined symbol in the ELF object
file, and the linker then pulls in files from an archive to satisfy that
reference at link-time, even if there are no relocations against the
symbol.  One could reasonably argue that the linker shouldn't do this,
but it does, and changing it might break things; people may well be
relying on this trick.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322


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