This is the mail archive of the
mailing list for the binutils project.
Re: protected __start_section and __stop_section symbols
On Mon, Feb 05, 2018 at 02:49:40PM +0100, Cimbali wrote:
> Hi again,
> I was able to find that commit f3996791 is what changed this:
> Why was this change made? It's sort of unexpected, and for what it's worth
> breaking some codes (not a lot I guess, but at least mine and it took some
> time to track down :) ).
Commit f3996791 changed the visibility of __start/__stop symbols from
hidden to protected. From the nature of your complaint, I assume you
would have liked hidden visibility symbols even less.
As to why these changes were made, the answer is that a change to the
order of processing various things in the bfd linker meant that we had
to change the way __start/__stop symbols were handled. For more
details, see PR 11133, 19161, 19167, 20022, 21557, 21562, 21571,
If you want to know specifically why the symbols were changed from
default visibility, that reason is given in the git log for commit
> On 05/02/18 11:21, Cimbali wrote:
> >According to readelf, when I define a section in GCC code with
> >__attribute__(("section")) in a shared library, the __start_section and
> >__stop_section symbols (which allow me retrieve the start and end of said
> >section) are now protected with ld v2.29.1.
> >I had some code that relied on having those symbols overruled by a program
> >to which the library is linked, that is if the section exists in the
> >program then use it from the library, otherwise fall back to the library's
> >section (details and reproducible example here:
> >https://stackoverflow.com/q/48591224/1387346 ).
> >This is no longer possible, but used to work with ld v2.26.1. I could not
> >find any decent changelog for ld, nor any mention of this in the man page,
> >and cannot figure out if this is a bug or a feature. Why did this change
> >of behaviour happen?
> >I am aware that the __start_section and __stop_section symbols are barely
> >documented to start with, but I'd like to know if there is a way for the
> >symbols not to be protected even with newer versions of ld, or if I have
> >to use another way of accessing data in a program from a library's
Australia Development Lab, IBM