This is the mail archive of the cygwin mailing list for the Cygwin 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: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1

Dave Korn wrote:

>   Ok, now I'll try debugging it.

  Ah.  Right.  Ouch.  I see what's going on.  Rebasing does not interact well
with the presence of unresolved weaks.  Gah.

  The problem arises here, in cygming-crtbegin.c:

extern void __register_frame_info (const void *, struct object *)
/* We need to indirect through a variable, as gcc assumes
 that a function label used as a constant is never zero.  */
void (*register_frame_info_ptr) (const void *, struct object *) =
                 < comments, #ifdefs folded >
__gcc_register_frame (void)
  void (*register_frame_fn) (const void *, struct object *) = 0;
  HANDLE h = GetModuleHandle (LIBGCC_SONAME);
  if (h)
    register_frame_fn = (void (*) (const void *, struct object *))
			GetProcAddress (h, "__register_frame_info");
  if (!register_frame_fn)
    register_frame_fn = register_frame_info_ptr;

  if (register_frame_fn)
     register_frame_fn (__EH_FRAME_BEGIN__, &obj);

  The purpose of playing these games is in order not to drag in the whole
exception handling machinery into a statically-linked application unless we
actually need it.  We're relying on detecting an unlinked weak symbol by it
having a value of zero at runtime.  That usually works, but the pointer
variable register_frame_info_ptr must have some kind of reloc pointing at it,
because rebase adjusts it, so instead of zero it becomes equal to the
difference between the new and old base addresses.

  I'll need to do some thinking about this, as it might be possible to make it
work, but in any case, the rule should be that DLLs are *always* linked
against shared-libgcc, regardless; even plain old C with no exceptions.  It's
OK if you're linking an entire app statically to link against static libgcc,
but it's definitely bad practice when building a DLL.  I should probably warn
against this usage in the compiler, if not fail it altogether; not sure yet,
because it does basically work, even if the DLL it produces isn't rebaseable,
and because it might not be difficult to make rebase skip relocating
unresolved weaks, and because I have this long-term scheme to make weaks work
properly on win32 like they do on ELF which would avoid the problem altogether.

  Take-home point: never use -static-libgcc when building a DLL.


Unsubscribe info:
Problem reports:

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