linker behaviour for sections having flags SHF_MERGE/SHF_STRINGS

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

linker behaviour for sections having flags SHF_MERGE/SHF_STRINGS

shankarke@gmail.com
Hi,

I was trying to understand the linker behaviour when sections have SHF_MERGE/SHF_STRINGS property set.

Below are the test cases :-

merge_test.s
--------------

        .section .rodata.str,"aMS","progbits",1
.LC0:
        .asciz  "abc"
.LC1:
        .asciz  "c"
        .text
        .global _start
_start:
        .long   .LC0
.LT0:
        .long   .LC1
        .long   .LC0-.LT0
        .long   .LC1-.LT0

$ readelf -p 5 merge_test.o

String dump of section '.rodata.str':
  [     0]  abc
  [     4]  c

$ ld merge_test.o
$ readelf -p 2 a.out

String dump of section '.rodata':
  [     0]  abc

$gold merge_test.o
$ readelf -p 2 a.out

String dump of section '.rodata':
  [     0]  abc
  [     4]  c

Question :-
Why is the difference ?


Case 2
----------

merge_test.s
--------------
        .section .rodata.str,"aM","progbits",3
.LC0:
        .asciz  "abc"
.LC1:
        .asciz  "abc"
.LC2:
        .asciz  "cde"
.LC3:
        .asciz  "cde"
        .text
        .global _start
_start:
        .long   .LC0
.LT0:
        .long   .LC1
        .long   .LC0-.LT0
        .long   .LC1-.LT0

$ ld merge_test.o
$ readelf -p 2 a.out
String dump of section '.rodata':
  [     0]  abc
  [     4]  abc
  [     8]  cde
  [     c]  cde

Question :-

Isnt that the behaviour to expect abc, cde in the output

Case 3
---------
$ cat merge_test.s
        .section .rodata.str,"aMS","progbits",2
.LC0:
        .asciz  "ab"
.LC1:
        .asciz  "ab"
        .text
        .global _start
_start:
        .long   .LC0
.LT0:
        .long   .LC1
        .long   .LC0-.LT0
        .long   .LC1-.LT0

$readelf -p 5 merge_test.o
String dump of section '.rodata.str':
  [     0]  ab
  [     3]  ab

$gold merge_test.o
gold: warning: merge_test.o: last entry in mergeable string section '.rodata.str' not null terminated

$ld merge_test.o
(no error)

What is the linker expecting here ?

Other Questions:-

1) Are there documents that describe the behaviour when such SHF_STRINGS/SHF_MERGE is set ?
2) Why is there a difference when I specify sh_entsize with sections having SHF_STRINGS/SHF_MERGE flags ?

Thanks

Shankar Easwaran
Reply | Threaded
Open this post in threaded view
|

Re: linker behaviour for sections having flags SHF_MERGE/SHF_STRINGS

Alan Modra-3
On Fri, Nov 09, 2012 at 09:14:30AM -0800, [hidden email] wrote:
> $gold merge_test.o
> $ readelf -p 2 a.out
>
> String dump of section '.rodata':
>   [     0]  abc
>   [     4]  c
>
> Question :-
> Why is the difference ?

Possibly a gold bug.

> merge_test.s
> --------------
>         .section .rodata.str,"aM","progbits",3
> .LC0:
>         .asciz  "abc"
> .LC1:
>         .asciz  "abc"
> .LC2:
>         .asciz  "cde"
> .LC3:
>         .asciz  "cde"

Your testcase is broken.  With an entsize of 3, the elements are
abc,\0ab,c\0c,de\0,cde,\0

>         .section .rodata.str,"aMS","progbits",2
> .LC0:
>         .asciz  "ab"
> .LC1:
>         .asciz  "ab"

Similarly here.  The zero terminator should be entsize bytes wide.

> $gold merge_test.o
> gold: warning: merge_test.o: last entry in mergeable string section
> '.rodata.str' not null terminated
>
> $ld merge_test.o
> (no error)

And this is a ld bug.  It should complain too.  Nitpick on the gold
message: strings aren't null terminated, they are NUL terminated.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: linker behaviour for sections having flags SHF_MERGE/SHF_STRINGS

Cary Coutant-2
>> $gold merge_test.o
>> $ readelf -p 2 a.out
>>
>> String dump of section '.rodata':
>>   [     0]  abc
>>   [     4]  c
>>
>> Question :-
>> Why is the difference ?
>
> Possibly a gold bug.

Try running gold with the -O2 option. By default, gold won't do the
trailing substring optimization.

-cary
Reply | Threaded
Open this post in threaded view
|

Re: linker behaviour for sections having flags SHF_MERGE/SHF_STRINGS

Ian Lance Taylor-3
On Fri, Nov 9, 2012 at 5:40 PM, Cary Coutant <[hidden email]> wrote:

>>> $gold merge_test.o
>>> $ readelf -p 2 a.out
>>>
>>> String dump of section '.rodata':
>>>   [     0]  abc
>>>   [     4]  c
>>>
>>> Question :-
>>> Why is the difference ?
>>
>> Possibly a gold bug.
>
> Try running gold with the -O2 option. By default, gold won't do the
> trailing substring optimization.

And that is because we looked at some very large executables and found
that it almost never fired, but took something like 5% of total link
time.  It's available if you want it but on average it doesn't seem
like a good tradeoff by default.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: linker behaviour for sections having flags SHF_MERGE/SHF_STRINGS

shankarke@gmail.com
In reply to this post by Alan Modra-3

Hi Alan,

Thanks for your message. Made it more clear for me.

I dont know how critical are the linker and the gold bugs, think they are
not so critical.

I had more questions on the same topic and want to know

1) How is sh_entsize relevant when the section flags have SHF_STRINGS set ?

Thanks

Shankar Easwaran


Alan Modra-3 wrote:

>
> On Fri, Nov 09, 2012 at 09:14:30AM -0800, [hidden email] wrote:
>> $gold merge_test.o
>> $ readelf -p 2 a.out
>>
>> String dump of section '.rodata':
>>   [     0]  abc
>>   [     4]  c
>>
>> Question :-
>> Why is the difference ?
>
> Possibly a gold bug.
>
>> merge_test.s
>> --------------
>>         .section .rodata.str,"aM","progbits",3
>> .LC0:
>>         .asciz  "abc"
>> .LC1:
>>         .asciz  "abc"
>> .LC2:
>>         .asciz  "cde"
>> .LC3:
>>         .asciz  "cde"
>
> Your testcase is broken.  With an entsize of 3, the elements are
> abc,\0ab,c\0c,de\0,cde,\0
>
>>         .section .rodata.str,"aMS","progbits",2
>> .LC0:
>>         .asciz  "ab"
>> .LC1:
>>         .asciz  "ab"
>
> Similarly here.  The zero terminator should be entsize bytes wide.
>
>> $gold merge_test.o
>> gold: warning: merge_test.o: last entry in mergeable string section
>> '.rodata.str' not null terminated
>>
>> $ld merge_test.o
>> (no error)
>
> And this is a ld bug.  It should complain too.  Nitpick on the gold
> message: strings aren't null terminated, they are NUL terminated.
>
> --
> Alan Modra
> Australia Development Lab, IBM
>
>

--
View this message in context: http://old.nabble.com/linker-behaviour-for-sections-having-flags-SHF_MERGE-SHF_STRINGS-tp34661603p34669646.html
Sent from the Sourceware - binutils list mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: linker behaviour for sections having flags SHF_MERGE/SHF_STRINGS

shankarke@gmail.com
In reply to this post by Ian Lance Taylor-3

Hi Cary,

The testcase ran fine with -O2.

Is there any document, that specifies the optimizations done at each level ?

Thanks

Shankar Easwaran


Ian Lance Taylor-3 wrote:

>
> On Fri, Nov 9, 2012 at 5:40 PM, Cary Coutant <[hidden email]> wrote:
>>>> $gold merge_test.o
>>>> $ readelf -p 2 a.out
>>>>
>>>> String dump of section '.rodata':
>>>>   [     0]  abc
>>>>   [     4]  c
>>>>
>>>> Question :-
>>>> Why is the difference ?
>>>
>>> Possibly a gold bug.
>>
>> Try running gold with the -O2 option. By default, gold won't do the
>> trailing substring optimization.
>
> And that is because we looked at some very large executables and found
> that it almost never fired, but took something like 5% of total link
> time.  It's available if you want it but on average it doesn't seem
> like a good tradeoff by default.
>
> Ian
>
>

--
View this message in context: http://old.nabble.com/linker-behaviour-for-sections-having-flags-SHF_MERGE-SHF_STRINGS-tp34661603p34669662.html
Sent from the Sourceware - binutils list mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: linker behaviour for sections having flags SHF_MERGE/SHF_STRINGS

Ian Lance Taylor-3
In reply to this post by shankarke@gmail.com
On Mon, Nov 12, 2012 at 6:43 AM, Shankar Kalpathi Easwaran
<[hidden email]> wrote:
>
> I dont know how critical are the linker and the gold bugs, think they are
> not so critical.

I think the only gold bug is a slightly misleading error message.
Definitely not critical.

> 1) How is sh_entsize relevant when the section flags have SHF_STRINGS set ?

sh_entsize tells the linker the size of a character in a string.  This
permits the linker to correctly handle strings represented in, e.g.,
UTF-16 or UCS-2.

Ian