gold linker: Access section start & end address w/o using a linker script

gold linker: Access section start & end address w/o using a linker script

[Raphael Zulliger]

Hi

After having read several things about gold in the net, my impression is that gold mainly supports linker scripts to be backward compatible to the bfd linker. But the "gold style of linking" is to avoid using linker scripts. Am I roughly right with this conclusion?

Assuming yes:
The problem that arises when no linker script should be used is that our RTOS (and probably embedded system in general) requires to know the start address and end address of certain sections, such as data, sbss, etc. We need to know these addresses in order to create copies of these section during startup to support 'soft reset OS' features. Moreover, according to my understanding, gcc itself requires certain such symbols when compiled for powerpc-*-eabi from gcc 4.7.2 sources: libgcc/config/rs6000/eabi.S:
…
/* Do any initializations needed for the eabi environment */

	.section ".text"
	#include "ppc-asm.h"

#ifndef __powerpc64__

	 .section ".got2","aw"
	.align	2
.LCTOC1 = . /* +32768 */

/* Table of addresses */
.Ltable = .-.LCTOC1
	.long	.LCTOC1				/* address we are really at */

.Lsda = .-.LCTOC1
	.long	_SDA_BASE_			/* address of the first small data area */

.Lsdas = .-.LCTOC1
	.long	__SDATA_START__			/* start of .sdata/.sbss section */
...


Finally, the question: What is the concept of gold to support the symbols as required by gcc and to create "project-specific" symbols at the start and end of sections? Should we continue using linker scripts or is there something else we can/should do?

Thanks,
Raphael

Re: gold linker: Access section start & end address w/o using a linker script

[Ian Lance Taylor]

On Sun, Apr 21, 2013 at 9:04 AM, Raphael Zulliger <zulli73@gmail.com> wrote:
>
> After having read several things about gold in the net, my impression is that gold mainly supports linker scripts to be backward compatible to the bfd linker. But the "gold style of linking" is to avoid using linker scripts. Am I roughly right with this conclusion?

Yes.

> The problem that arises when no linker script should be used is that our RTOS (and probably embedded system in general) requires to know the start address and end address of certain sections, such as data, sbss, etc. We need to know these addresses in order to create copies of these section during startup to support 'soft reset OS' features.

With both gold and GNU ld, if the name of the section is a valid C
identifier (e.g., does not start with '.') then the symbols
__start_SECNAME and __stop_SECNAME will be automatically defined by
the linker and available for use by the program.

Ian

Re: gold linker: Access section start & end address w/o using a linker script

[Raphael Zulliger]

Thanks Ian!
__start_SECNAME / __stop_SECNAME: I've been googling for something like this almost for hours…

That certainly answers my question for "project specific" section names. But I cant see yet how it solve my question for pre-defined sections like .sbss, .sdata, etc.? Is there another trick I don't know yet? E.g. can I create section-aliasses or something like that? (again, a short google session didn't give useful results)

Raphael

On Apr 21, 2013, at 7:42 PM, Ian Lance Taylor <iant@google.com> wrote:

> On Sun, Apr 21, 2013 at 9:04 AM, Raphael Zulliger <zulli73@gmail.com> wrote:
>> 
>> After having read several things about gold in the net, my impression is that gold mainly supports linker scripts to be backward compatible to the bfd linker. But the "gold style of linking" is to avoid using linker scripts. Am I roughly right with this conclusion?
> 
> Yes.
> 
>> The problem that arises when no linker script should be used is that our RTOS (and probably embedded system in general) requires to know the start address and end address of certain sections, such as data, sbss, etc. We need to know these addresses in order to create copies of these section during startup to support 'soft reset OS' features.
> 
> With both gold and GNU ld, if the name of the section is a valid C
> identifier (e.g., does not start with '.') then the symbols
> __start_SECNAME and __stop_SECNAME will be automatically defined by
> the linker and available for use by the program.
> 
> Ian

Re: gold linker: Access section start & end address w/o using a linker script

[Ian Lance Taylor]

On Sun, Apr 21, 2013 at 12:27 PM, Raphael Zulliger <zulli73@gmail.com> wrote:
> Thanks Ian!
> __start_SECNAME / __stop_SECNAME: I've been googling for something like this almost for hours…
>
> That certainly answers my question for "project specific" section names. But I cant see yet how it solve my question for pre-defined sections like .sbss, .sdata, etc.? Is there another trick I don't know yet? E.g. can I create section-aliasses or something like that? (again, a short google session didn't give useful results)

Yes, for those sections you do need to use a linker script, or to
arrange for some file defining the appropriate symbols to be at the
start and end of your link.

For specialized purposes like this you do need to use a linker script
with gold.  gold is optimized to not use a linker script for the
ordinary case of a hosted system.  It's OK to use a linker script for
an embedded system.

Ian

Re: gold linker: Access section start & end address w/o using a linker script

[Raphael Zulliger]

Thanks.
Is there a chance to enhance gold to better support such use cases? Or is that out-of focus for gold? I'm not familiar with linking internals, but I think that providing additional start/end address symbols for section names starting with a '.' wouldn't be that tricky to be added, right?

On Apr 21, 2013, at 9:42 PM, Ian Lance Taylor <iant@google.com> wrote:

> On Sun, Apr 21, 2013 at 12:27 PM, Raphael Zulliger <zulli73@gmail.com> wrote:
>> Thanks Ian!
>> __start_SECNAME / __stop_SECNAME: I've been googling for something like this almost for hours…
>> 
>> That certainly answers my question for "project specific" section names. But I cant see yet how it solve my question for pre-defined sections like .sbss, .sdata, etc.? Is there another trick I don't know yet? E.g. can I create section-aliasses or something like that? (again, a short google session didn't give useful results)
> 
> Yes, for those sections you do need to use a linker script, or to
> arrange for some file defining the appropriate symbols to be at the
> start and end of your link.
> 
> For specialized purposes like this you do need to use a linker script
> with gold.  gold is optimized to not use a linker script for the
> ordinary case of a hosted system.  It's OK to use a linker script for
> an embedded system.
> 
> Ian

Re: gold linker: Access section start & end address w/o using a linker script

[Ian Lance Taylor]

On Mon, Apr 22, 2013 at 4:39 AM, Raphael Zulliger <zulli73@gmail.com> wrote:
>
> Is there a chance to enhance gold to better support such use cases? Or is that out-of focus for gold? I'm not familiar with linking internals, but I think that providing additional start/end address symbols for section names starting with a '.' wouldn't be that tricky to be added, right?

I'm fine with it.  Look for uses of is_cident in the gold source code.

Ian

Re: gold linker: Access section start & end address w/o using a linker script

[Raphael Zulliger]

To complete the story: While adding such symbols would be quite easy (see prototype-hack below), it's by far not enough to abandon linker scripts from our embedded project (and probably for embedded project  in general). In order to abandon linker scripts, we'd probably first need to analyse all relevant use-cases to come up with something else... 

Therefore, I stop investigating towards this direction. Just in case that someone stumbles over this thread and would find having start and end symbols useful, I post the code I came up with. But again: This is just a prototype.

Raphael

### Eclipse Workspace Patch 1.0
#P binutils-cvs
Index: gold/gold.h
===================================================================
RCS file: /cvs/src/src/gold/gold.h,v
retrieving revision 1.50
diff -u -r1.50 gold.h
--- gold/gold.h	24 Oct 2012 02:26:39 -0000	1.50
+++ gold/gold.h	12 May 2013 11:56:47 -0000
@@ -262,6 +262,15 @@
 	  == '\0');
 }
 
+inline bool
+matches_predefined_sectionname_scheme(const char* name)
+{
+	if ((strlen(name) > 0) && (name[0] == '.') ) {
+	    return is_cident(name+1);
+	}
+	return false;
+}
+
 // We sometimes need to hash strings.  Ideally we should use std::tr1::hash or
 // __gnu_cxx::hash on some systems but there is no guarantee that either
 // one is available.  For portability, we define simple string hash functions.
Index: gold/incremental.cc
===================================================================
RCS file: /cvs/src/src/gold/incremental.cc,v
retrieving revision 1.56
diff -u -r1.56 incremental.cc
--- gold/incremental.cc	1 Nov 2012 22:35:06 -0000	1.56
+++ gold/incremental.cc	12 May 2013 11:56:55 -0000
@@ -1947,16 +1947,20 @@
   struct Got_plt_view_info view_info;
   view_info.got_count = target->got_entry_count();
   view_info.plt_count = target->plt_entry_count();
-  view_info.first_plt_entry_offset = target->first_plt_entry_offset();
-  view_info.plt_entry_size = target->plt_entry_size();
+  if( view_info.plt_count ) {
+	  view_info.first_plt_entry_offset = target->first_plt_entry_offset();
+	  view_info.plt_entry_size = target->plt_entry_size();
+  } else {
+	  view_info.first_plt_entry_offset = 0;
+	  view_info.plt_entry_size = 0;
+  }
   view_info.got_type_p = pov + 8;
   view_info.got_desc_p = (view_info.got_type_p
 			  + ((view_info.got_count + 3) & ~3));
   view_info.plt_desc_p = view_info.got_desc_p + view_info.got_count * 8;
 
   gold_assert(pov + view_size ==
-	      view_info.plt_desc_p + view_info.plt_count * 4);
-
+		  view_info.plt_desc_p + view_info.plt_count * 4);
   // Write the section header.
   Swap32::writeval(pov, view_info.got_count);
   Swap32::writeval(pov + 4, view_info.plt_count);
Index: gold/layout.cc
===================================================================
RCS file: /cvs/src/src/gold/layout.cc,v
retrieving revision 1.249
diff -u -r1.249 layout.cc
--- gold/layout.cc	15 Apr 2013 16:40:59 -0000	1.249
+++ gold/layout.cc	12 May 2013 11:57:02 -0000
@@ -2122,6 +2122,40 @@
 					0, // nonvis
 					true, // offset_is_from_end
 					true); // only_if_ref
+	} if (matches_predefined_sectionname_scheme(name)) {
+		  std::string name_string(name + 1);
+		  std::transform(name_string.begin(), name_string.end(),name_string.begin(), ::toupper);
+		  const std::string start_name("__"
+					       + name_string + "_START");
+		  const std::string stop_name("__"
+					      + name_string + "_END");
+
+                  fprintf(stderr, "Geil2: '%s', '%s'\n", start_name.c_str(), stop_name.c_str());
+		  symtab->define_in_output_data(start_name.c_str(),
+						NULL, // version
+						Symbol_table::PREDEFINED,
+						*p,
+						0, // value
+						0, // symsize
+						elfcpp::STT_NOTYPE,
+						elfcpp::STB_GLOBAL,
+						elfcpp::STV_DEFAULT,
+						0, // nonvis
+						false, // offset_is_from_end
+						true); // only_if_ref
+
+		  symtab->define_in_output_data(stop_name.c_str(),
+						NULL, // version
+						Symbol_table::PREDEFINED,
+						*p,
+						0, // value
+						0, // symsize
+						elfcpp::STT_NOTYPE,
+						elfcpp::STB_GLOBAL,
+						elfcpp::STV_DEFAULT,
+						0, // nonvis
+						true, // offset_is_from_end
+						true); // only_if_ref
 	}
     }
 }

 
On Apr 22, 2013, at 7:51 PM, Ian Lance Taylor <iant@google.com> wrote:

> On Mon, Apr 22, 2013 at 4:39 AM, Raphael Zulliger <zulli73@gmail.com> wrote:
>> 
>> Is there a chance to enhance gold to better support such use cases? Or is that out-of focus for gold? I'm not familiar with linking internals, but I think that providing additional start/end address symbols for section names starting with a '.' wouldn't be that tricky to be added, right?
> 
> I'm fine with it.  Look for uses of is_cident in the gold source code.
> 
> Ian

Re: gold linker: Access section start & end address w/o using a linker script

[Kevin]

Ian Lance Taylor <iant <at> google.com> writes:

> 
> On Mon, Apr 22, 2013 at 4:39 AM, Raphael Zulliger
 <zulli73 <at> gmail.com> wrote:
> >
> > Is there a chance to enhance gold to better support such use cases? 
Or is that out-of focus for gold? I'm not
> familiar with linking internals, but I think that providing additional 
start/end address symbols for> section names starting with a '.' wouldn't
 be that tricky to be added, right?
> 
> I'm fine with it.  Look for uses of is_cident in the gold source code.
> 
> Ian
> 
> 


Thanks for the tip Ian.  In that routine one could easily ignore a
leading ".".  In abstract one might want to handle "." inside the
name, or translate characters (such as "$") allowed in ELF symbols but
not in C (or in some other language), whereby a simple concept starts
to get out of hand; thus:

- Could we assume that standard ELF section names can be mapped to C
identifiers just by mapping the leading "."?

- What mapping would you suggest?  If the leading "." is dropped then
the resulting would collide with a common name (text or data in
particular).  This problem seems unsolvable in general, so should one
make an effort at all (mapping "." to a single underscore for
example)?

Re: gold linker: Access section start & end address w/o using a linker script

[Ian Lance Taylor]

On Sat, Feb 1, 2014 at 5:14 PM, Kevin <ancafe@ymail.com> wrote:
> Ian Lance Taylor <iant <at> google.com> writes:
>
>>
>> On Mon, Apr 22, 2013 at 4:39 AM, Raphael Zulliger
>  <zulli73 <at> gmail.com> wrote:
>> >
>> > Is there a chance to enhance gold to better support such use cases?
> Or is that out-of focus for gold? I'm not
>> familiar with linking internals, but I think that providing additional
> start/end address symbols for> section names starting with a '.' wouldn't
>  be that tricky to be added, right?
>>
>> I'm fine with it.  Look for uses of is_cident in the gold source code.
>>
>> Ian
>>
>>
>
>
> Thanks for the tip Ian.  In that routine one could easily ignore a
> leading ".".  In abstract one might want to handle "." inside the
> name, or translate characters (such as "$") allowed in ELF symbols but
> not in C (or in some other language), whereby a simple concept starts
> to get out of hand; thus:
>
> - Could we assume that standard ELF section names can be mapped to C
> identifiers just by mapping the leading "."?
>
> - What mapping would you suggest?  If the leading "." is dropped then
> the resulting would collide with a common name (text or data in
> particular).  This problem seems unsolvable in general, so should one
> make an effort at all (mapping "." to a single underscore for
> example)?

The linker doesn't define symbols that are the section names: it adds
"__start_" and "__stop_" before them.  I think it would be fine to
just turn a leading '.' into a '_' for this purpose.

Ian