Re: Request to extend symbol visibilities (st_other)

Skip to first unread message

Jim Dehnert

Aug 17, 2007, 2:31:45 AM8/17/07
Rod Evans wrote:
> Thanks for the input Jim ... comments in-line ...
> Jim Dehnert wrote:
> ...
>> This is certainly a reasonable concern. But given that it is a
>> debugging
>> concern, I wonder if it wouldn't be more appropriate to deal with it
>> in the
>> debugging information instead. I don't feel strongly about it,
>> though.
> Hmm, good point, however it wouldn't do us much use. Our linker doesn't
> even look at debugging information (it might relocate it, but that's all).
> The compilers create the information, we "concatenate" it together and
> put in the output file, and debuggers use it. This has given the
> traditional debuggers and compilers a great deal of flexibility to
> control their information without ld(1) getting involved.

Of course, what you're suggesting is that ld get involved. :-)

But to be constructive, what I had in mind was something
along these lines: The linker optimizes STV_HIDDEN
symbols by removing them. Always. Tools that generate
such symbols that want them available later for debugging
can put them in a debugging section, which gets relocated
just like any other debugging sections, so it doesn't involve
any special ld processing. That "section" could look just
like an ELF symbol table section, or be something understood
only by your debugger, or whatever else is convenient. The
only significant difference to the debugger is that it needs
to know about and read that symbol table. If you want it
to be robust about linkers that _don't_ remove STV_HIDDEN
symbols, it also needs to explicitly ignore them.

Something that occurred to me after last night's message
was that using a new visibility attribute for this will force
equivalence between STV_HIDDEN and STV_INTERNAL
(for those symbols that you change to STV_ELIMINATE).
Given the preponderance of implementations that don't
distinguish them today, that might not be a big deal...

> According the ABI I know of:
> The attributes, ordered from least to most constraining, are:
> And this is all we've followed - but then we've taken hidden and
> internal as being equivalent. Perhaps for your implementation,
> the words should be tightened up to convey what should happen
> if different visibility attributes are specified for distinct
> references to or definitions of STV_HIDDEN/STV_INTERNAL symbols.

Yes, we were not clear about this. (Partially because we
were still working out combination issues when it was

> Folks have suggested that STV_INTERNAL should perhaps be given the
> STV_ELIMINATE capabilities I've been proposing. If everyone agreed
> to this I'd be happy, but it sounds like you have a implementation
> where STV_INTERNAL and STV_HIDDEN differ, and thus I think we
> should not redefine STV_INTERNAL. Whether others will implement
> STV_INTERNAL as you describe, who knows. I'll probably continue
> to view STV_INTERNAL/STV_HIDDEN the same - but we shouldn't steal
> the name for another purpose.

That's what I would suggest. I believe that SGI's implementation did
actually distinguish, but I don't even know who to ask these days.

> So to sum up, I think we've discovered/proposed a few things.
> i. STV_INTERNAL can provide a unique class of visibility.
> Perhaps Jim could provide the description that should
> be defined in the ABI (part of the Symbol Table description).

What does it say now? Before you ask for such things, you
should be aware that I haven't worked with this stuff for at
least 7 years. :-)

> And to clarify another point in regards to where I'm coming from.
> I don't believe that defining an ABI namespace, and the implementation
> behind that namespace dictates that everyone must provide the
> associated capability. There are a number of things in the ABI
> that we don't implement. But we shouldn't steal the namespace for
> a different/conflicting purpose. Hence I wouldn't want to use
> visibility 4 for some other purpose than STV_EXPORT now that I know
> STV_EXPORT exists. And, I'm also not comfortable taking STV_INTERNAL
> for a new purpose (unless Jim gave his blessing :-) .

Given that I no longer work for SGI, and don't know precisely
how they use it these days, my blessing wouldn't be worth
much... I do believe that STV_INTERNAL can be useful, but
only in a link-time (interprocedural) optimization context, and
it may be limited enough there not to be a concern.


Jim Dehnert

Reply all
Reply to author
0 new messages