[lttng-dev] Problem with UST related to dlload
gerlando.falauto at keymile.com
Wed May 28 10:30:11 EDT 2014
On 05/28/2014 04:14 PM, Woegerer, Paul wrote:
> On 05/28/2014 03:04 PM, Gerlando Falauto wrote:
>> So the hidden symbols are *NOT* weak at all (at least with my buggy
>> compiler). They are just automagically defined by the linker.
> I wrote "weak, in the sense that it can be linked without providing a
> definition somewhere".
> See: http://en.wikipedia.org/wiki/Weak_symbol "... When linking a binary
> executable, a weakly declared symbol does not need a definition. ...."
I agree with you. My initial understanding of weak symbol was probably
wrong. I was not aware of the optional definition part, where in case of
a missing definition the symbol assumes a value of all-zeroes.
But that was clear to me already when I wrote my previous mail.
Still, I don't get your point.
In our context, what would be the point of having those symbols as weak?
This would mean we could have zero, one or more definitions for it.
Don't we instead want exactly _one_ definition (per shared object), the
one PROVIDEd by the linker when emitting the output file?
>> As a matter of fact, I don't think they should have ever been weak in
>> the first place. We *WANT* those symbols to exist and be well-defined,
>> and we should make sure the linker complies with this requirement, as
>> this is crucial to the correct behaviour of lttng-ust.
>> If we generate an inconsistency like the above and keep the weak
>> attribute, we would end up with code which compiles perfectly but
>> still will not work!
>> BTW, the only reference I could find to how and why ldd defines those
>> symbols for section __start__/__stop__ is , which admittedly
>> states: "I couldn't find any formal documentation for this feature,
>> only a few obscure mailing list references". :-(
> "If an orphaned section's name is representable as a C identifier then
> the linker will automatically see PROVIDE
> <https://sourceware.org/binutils/docs-2.24/ld/PROVIDE.html#PROVIDE> two
> symbols: __start_SECNAME and __stop_SECNAME, where SECNAME is the name
> of the section. These indicate the start address and end address of the
> orphaned section respectively."
Wonderful, thanks for sharing this! [Actually, yes, linker's ld, not ldd
-- my mistake!]
More information about the lttng-dev