"ld --verbose" omits SECTIONS-to-PHDRS mapping

"ld --verbose" omits SECTIONS-to-PHDRS mapping

[John Reiser]

"ld --verbose" should display the linker script being used.
However, the output omits the PHDRS paragraph and the mapping from
SECTIONS to PHDRS.  Thus the output lacks much necessary information,
and adapting the script for specific use requires a lot of work.
For instance, adding another PT_LOAD with designated SECTIONS
requires editing many existing SECTIONS lines that are unrelated
to the addition.

For example, in the specific case of "-m elf_i386" then the output
omits something like
-----
PHDRS
{
       headers  PT_PHDR   PHDRS ;
       interp   PT_INTERP ;
       text     PT_LOAD   FILEHDR  PHDRS  FLAGS ( 5 ) ;
       data     PT_LOAD  FLAGS ( 6 ) ;
       dynamic  PT_DYNAMIC ;
       note     PT_NOTE ;
       eh_frame PT_GNU_EH_FRAME  FLAGS ( 4 ) ;
       gnu_stack PT_GNU_STACK  FLAGS ( 6 );
}
-----
and the SECTIONS lines have only:
  .interp         : { *(.interp) }
but instead should say:
  .interp         : { *(.interp) } :interp :text

Also, the output of "ld --verbose" is not even a valid script.
The header and trailer lines (marked with a long string of
equal signs "====================") should be enclosed in comment
delimiters "/* ... */".

Who can help me fix this?

-- 

Re: "ld --verbose" omits SECTIONS-to-PHDRS mapping

[Nick Clifton]

Hi John,

> "ld --verbose" should display the linker script being used.

It does.


> However, the output omits the PHDRS paragraph and the mapping from
> SECTIONS to PHDRS.

Not according to the tests that I ran.  Can you provide an example that 
demonstrates the problem ?  Plus - which version of the linker are you 
using ?  If it is not one built from the current head of the mainline 
sources then this might be the source of your problem.


> Also, the output of "ld --verbose" is not even a valid script.

Nor should it be.  The output of --verbose is more than just a linker 
script.  It is also version information, a list of the supported 
emulations and, if you are performing an actual link, a lot of output 
describing what the linker is doing.


> The header and trailer lines (marked with a long string of
> equal signs "====================") should be enclosed in comment
> delimiters "/* ... */".

No they shouldn't.  If you really want to just see the linker script and 
nothing else then run the output through a filter.  Eg:

  ld --verbose | gawk -- "/===/ { show = 1 - show } ; /*/ { if (show) 
print }"


> Who can help me fix this?

Well I can, but so can you.  Anyone is free to work on the binutils 
sources, and everyone who does so is encouraged to submit their work 
back to the project so that other people can benefit as well.


Cheers
   Nick

Re: "ld --verbose" omits SECTIONS-to-PHDRS mapping

[John Reiser]

>> However, the output omits the PHDRS paragraph and the mapping from
>> SECTIONS to PHDRS.

Nick wrote:
> Not according to the tests that I ran.  Can you provide an example that demonstrates the problem ?  Plus - which version of the linker are you using ?  If it is not one built from the current head of the mainline sources then this might be the source of your problem.

The output from my "ld --verbose" starts:
-----
GNU ld version 2.21.51.0.6-2.fc15 20110118
  Supported emulations:
   elf_x86_64
   elf32_x86_64
   elf_i386
   i386linux
   elf_l1om
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
              "elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(_start)
SEARCH_DIR("/usr/x86_64-redhat-linux/lib64"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/x86_64-redhat-linux/lib"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
SECTIONS
{
	...
-----
and the full output includes no PHDRS paragraph.

When I tried building binutils from today's CVS:
	cvs -z 9 -d :pserver:anoncvs@sourceware.org:/cvs/src co binutils
then I encountered problems.  Following the suggestion in src/binutils/README,
I made a new directory src/objdir and started:
	$ cd src/objdir
	$ ../binutils/configure --enable-targets=elf_i386 --prefix=/usr/local/binutils
	$ make

The first problem:
-----
make[1]: Entering directory `.../binutils/src/objdir/doc'
	...
../../binutils/doc/binutils.texi:8: @include `bfdver.texi': No such file or directory.
../../binutils/doc/binutils.texi:84: warning: undefined flag: VERSION.
makeinfo: Removing output file `binutils.info' due to errors; use --force to preserve.
make[1]: *** [binutils.info] Error 1
-----

After a web search on "bfdver.texi 2011", I found
	http://www.mail-archive.com/commits@crater.dragonflybsd.org/msg17596.html
and so created likely files
	src/bfd/bfdver.h
	src/bfd/doc/bfdver.texi

The second problem:
-----
make[2]: Entering directory `.../binutils/src/objdir'
	...
make[2]: *** No rule to make target `../libiberty/libiberty.a', needed by `size'.  Stop.
-----

How should I overcome this problem with libiberty.a?

-- 

Re: "ld --verbose" omits SECTIONS-to-PHDRS mapping

[John Reiser]

> -----
> make[2]: Entering directory `.../binutils/src/objdir'
> 	...
> make[2]: *** No rule to make target `../libiberty/libiberty.a', needed by `size'.  Stop.
> -----
> 
> How should I overcome this problem with libiberty.a?

By backing up to the top-level src/ directory and running ./configure there,
without the --enable-targets, then running 'make'.

My "./ld/ld-new --verbose" output now identifies the version as
	GNU ld (GNU Binutils) 2.21.52.20110610
and still contains no PHDRS paragraph, nor mappings from SECTION to PHDRS.

-- 

Re: "ld --verbose" omits SECTIONS-to-PHDRS mapping

[Nick Clifton]

Hi John,

> The output from my "ld --verbose" starts:
> -----
> GNU ld version 2.21.51.0.6-2.fc15 20110118

OK, I have this version as well.

> and the full output includes no PHDRS paragraph.

What PHDRS paragraph ?  The default linker script for the x86_64 
architecture does not contain a PHDRS paragraph.  In fact the only 
binutils target which includes a PHDRS paragraph by default is the 
sh-symbianelf target.

Cheers
   Nick

Re: "ld --verbose" omits SECTIONS-to-PHDRS mapping

[John Reiser]

>> and the full output includes no PHDRS paragraph.

> What PHDRS paragraph ?  The default linker script for the x86_64 architecture does not contain a PHDRS paragraph.  In fact the only binutils target which includes a PHDRS paragraph by default is the sh-symbianelf target.

That's my point: the default linker script (for any output format
that generates ElfXX_Phdr) always should contain a PHDRS paragraph.
Omitting the PHDRS paragraph, and the mapping from SECTION to PHDR
["readelf --segments" calls this the "Section to Segment mapping"],
omits vital information about the default behavior.  Instead,
"ld --verbose" should include this information.

For instance, on x86_64 the SECTIONS paragraph of "ld --verbose"
contains a line:
  .interp         : { *(.interp) }
but neither this line nor any preceding line designates the
segment in which the .interp section should reside.  The line should be:
  .interp         : { *(.interp) } :interp :text
and there should be lines such as these in a PHDRS paragraph:
       interp   PT_INTERP ;
       text     PT_LOAD   FILEHDR  PHDRS  FLAGS ( 5 ) ;
Without those lines the description of ld's behavior is incomplete.

Omitting the PHDRS paragraph and the SECTION to PHDR mapping matters
when a user wants to change the default, such as by moving some
section to a different segment, or by introducing a new segment,
or by changing the output alignment or permissions, etc.
In order to do this using the current output from "ld --verbose",
then the user must conjure up a suitable PHDRS paragraph that matches
the default behavior, and designate the proper segment for each section.
The information required to make an explicit PHDRS paragraph that is
equivalent to the current default is scattered and incomplete.
This creates a significant barrier to Usability of ld.

-- 

Re: "ld --verbose" omits SECTIONS-to-PHDRS mapping

[Ian Lance Taylor]

John Reiser <jreiser@bitwagon.com> writes:

> That's my point: the default linker script (for any output format
> that generates ElfXX_Phdr) always should contain a PHDRS paragraph.

I just want to note that gold does not use a default linker script at
all, because a default linker script slows down the linker with no
benefit to 99.9% of linker users.  Extending ld's default linker script
to include PHDRS information, rather than representing it
algorithmically as is done today, would be another way of slowing down
ld with no benefit to 99.9% of users.

Ian

Re: "ld --verbose" omits SECTIONS-to-PHDRS mapping

[John Reiser]

On 06/13/2011 01:50 PM, Ian Lance Taylor wrote:
> John Reiser <jreiser@bitwagon.com> writes:
> 
>> That's my point: the default linker script (for any output format
>> that generates ElfXX_Phdr) always should contain a PHDRS paragraph.
> 
> I just want to note that gold does not use a default linker script at
> all, because a default linker script slows down the linker with no
> benefit to 99.9% of linker users.  Extending ld's default linker script
> to include PHDRS information, rather than representing it
> algorithmically as is done today, would be another way of slowing down
> ld with no benefit to 99.9% of users.


Correcting that last line for you:
... ld with no _direct_ benefit to 99.9% of users.

A major part of the _indirect_ benefit to all users of having a default
linker script is forcing the creation and maintenance of documentation
that matches what the algorithm actually _is_.

Nick's message "Commit: Fix test for .dynstr section" of 2011-06-10
was because of a bug I encountered while trying to figure out what
the PHDRS section should be.  I believe that the cause of the bug
was poor documentation of what the algorithm is.

-- 

Re: "ld --verbose" omits SECTIONS-to-PHDRS mapping

[Ian Lance Taylor]

John Reiser <jreiser@bitwagon.com> writes:

> A major part of the _indirect_ benefit to all users of having a default
> linker script is forcing the creation and maintenance of documentation
> that matches what the algorithm actually _is_.

Only partially.  Typical linker output on a current GNU/Linux system
includes a PT_GNU_STACK and a PT_GNU_EH_FRAME segment.  There is no way
to describe those segments in the current linker script language.  As
far as I can see, any attempt to add them with the current semantics
would amount to saying "created magically," and as such would add
little.  Similarly, although the PT_GNU_RELRO segment is partially
represented in the current linker script language via
DATA_SEGMENT_RELRO_END, little tricks like putting the first few
.got.plt entries into the relro segment can not be represented in the
current linker script language.

Ian