protected __start_section and __stop_section symbols

Michael Matz
Mon Feb 5 22:39:00 GMT 2018


On Mon, 5 Feb 2018, Cimbali wrote:

> I was able to find that commit f3996791 is what changed this:

Actually that just relaxed the visibility again to protected.  Before that 
commit they were even hidden and not even exported.  They were initially 
made hidden by cbd0eecf.

Since then we're recovering from this.  See
  (no nice bugzilla entry because of intermittant bugzilla db corruption)

> 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 :) ).

Hmm, so you want them interposable.  But others actually don't (as in, 
references from inside a shared lib should resolve to the one form the 
share lib).  Target conflict, where I don't see a solution :-/

(The intricate usage I know about is pacemaker, and they're using 
dlopen/dlsym, so don't actually care for interposition or not; they'd be 
fine with the old rules).

> Thanks,
> Cimbali
> On 05/02/18 11:21, Cimbali wrote:
> > Hi,
> >
> > 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:
> > ).
> >
> > 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 constructor.
> >
> > Thanks,
> > Cimbali
> >

More information about the Binutils mailing list