This is the mail archive of the mailing list for the glibc 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: __gmon_start__ symbol vs. dependencies between shared libraries

On Tue, Dec 01, 2009 at 10:31:07AM +0100, Thomas Schwinge wrote:
> That is, __gmon_start__ is required for, and is bound to
>'s (weak) definition.  Correct would be that
> falls back to its *own* (weak) definition of it, unless the real
> definition of this symbol is linked in through gcrt1.o.
> The following tiny patch fixes this, and makes the following tests pass,
> which failed previously: elf/reldep3.out, elf/neededtest.out,
> elf/order2.out.

I'm not sure this patch has the effect you wanted.  If you have a
weak, hidden definition, will the linker ever call a strong version
if it's in a different DSO?  I don't think so; .hidden will suppress a
dynamic relocation against the __gmon_start__ name.

SH seems to be the only architecture with a weak definition of
__gmon_start__.  And it isn't doing anything, that I can see.
Should it be replaced with a conditional function call?

Daniel Jacobowitz

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