[ITP, take 2] Re: [ITP] libelf

Dave Korn dave.korn.cygwin@googlemail.com
Wed Dec 30 17:57:00 GMT 2009


Yaakov (Cygwin/X) wrote:
> On 30/12/2009 11:38, Dave Korn wrote:
>> Nevermind; I figured it out.  I have a local patch in my binutils (which
>> I'm about to send upstream) that accounts for the difference.  I'll
>> upload libelf without libgcc1 in the requires: line, since the DLL that I
>> build won't have the import.  (DLLs built using unpatched binutils will
>> continue to pull in this redundant dependency, but that's not a problem
>> for me, only for anyone who for whatever reason decides they want to
>> repackage it themselves.)
> 
> Why is a dependency on libgcc1 redundant?

  Because it doesn't actually need anything from libgcc1.  It gets pulled in
by the weak reference here in gcc/config/i386/cygming-crtbegin.c:

---------------------------------------------------
extern void __register_frame_info (const void *, struct object *)
				   TARGET_ATTRIBUTE_WEAK;
extern void *__deregister_frame_info (const void *)
				      TARGET_ATTRIBUTE_WEAK;
[ ... ]
  if (h)
    register_frame_fn = (void (*) (const void *, struct object *))
			GetProcAddress (h, "__register_frame_info");
  else
    register_frame_fn = __register_frame_info;
  if (register_frame_fn)
     register_frame_fn (__EH_FRAME_BEGIN__, &obj);
---------------------------------------------------

  This is a PE weak external, and if there aren't any strong definitions
elsewhere in the program, it should fall back to the default value (zero); in
particular it should not cause the import stub to be pulled in from the libgcc
import library.  The bug in binutils causes the weakness of the symbol to be
forgotten, causing the reference to be pulled in; the result is that at
startup the program unnecessarily calls into the libgcc dll to register empty
EH frame tables.  Harmless but wasteful.

  The reason this only happens sometimes when linking a DLL is because it
depends on the order in which LD encounters the weak reference and other
undefined references to the same symbol; the weakness can get lost.  It's
another side of the same bug as here,

http://cygwin.com/ml/cygwin/2009-12/threads.html#00583

where it resulted in a weak reference giving an undefined symbol error; here,
there is a version of the symbol in question available, so it just ends up
pulling the symbol in when it wasn't wanted.

  (I'll post the fix to the binutils list shortly, I'm writing it up now.)

    cheers,
      DaveK




More information about the Cygwin-apps mailing list