Re: Linker script using INSERT AFTER

[Jan Blunck <jblunck at suse dot de>]

On Tue, Oct 27, Alan Modra wrote:

> On Mon, Oct 26, 2009 at 06:07:04PM +0100, Jan Blunck wrote:
> > I'm trying to come up with a clever linker scripts, actually as an so-file,
> > that is inserting some symbols if they are not provided by the objects being
> > linked. Therefore I tried to use INSERT AFTER like this:
> [snip]
> > I get this error during linking:
> > 
> > /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld:
> > warning: /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../lib64/libust.so
> > contains output sections; did you forget -T?
> 
> You also got this warning.  ;-)
> 

Yes, I know. But I don't want to replace the default linker script. I don't
know how to get rid of this warning and achieve what I want.

> > /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld:
> > .data not found for insert
> > collect2: ld returned 1 exit status
> > make: *** [basic] Error 1
> 
> The reason for the error is due to the order of script parsing.  -T
> scripts are parsed before the default linker script, and files that
> are found to be scripts when opening input files are parsed later.  So
> your script is placed after the default script in the linker's
> internal representation of script statements.  As the ld info doc
> says, INSERT "inserts all prior linker script statements after (or
> before) output_section".  In your case, "all prior statements" is the
> entirety of the default script plus your script.  The linker can't
> find a ".data" statement outside of this set.

Now I'm confused. I thought that this is exactly how it should work. First use
the default linker script and after that augment it by inserting another
section. I thought it is searching for .data in the statements that it already
found, which includes the default linker script where .data should be defined.

If I understand you correctly there is no chance of adding another (empty)
section in linker scripts that are found when opening input files? I don't
care that much where this section gets added though.

> > Anyway, since I though that it isn't necessary to add an empty section (if
> > __start___markers isnt' there I know that the section will be empty anyway) I
> > thought that I can live with the following:
> > 
> > SECTIONS
> > {
> > 	PROVIDE_HIDDEN(__start___markers = .);
> > 	PROVIDE_HIDDEN(__stop___markers = .);
> > 
> > 	PROVIDE_HIDDEN(__start___tracepoints = .);
> > 	PROVIDE_HIDDEN(__stop___tracepoints = .);
> > }
> > INSERT AFTER .data;
> > 
> > That actually works, but it seems to override the hidden symbol that comes
> > with on of the objects to link with. Somehow I think this isn't correct due to
> > the description of PROVIDE_HIDDEN().
> 
> PROVIDE and PROVIDE_HIDDEN should only provide definitions for
> undefined or common symbols.  Perhaps you have one of the latter?

Right, the symbol is usually undefined. But when an object files defines
markers or tracepoints (so the __markers or __tracepoints section exists in
it) it is defined as a global hidden symbol. Actually the symbol get created
by the linker itself when it finds a __markers or __tracepoints section.

Regards,
	Jan

-- 
Jan Blunck <jblunck@suse.de>