ld: SHF_MERGE sections on both sides of a symbol assignment

ld: SHF_MERGE sections on both sides of a symbol assignment

[Song Fangrui]

For the following example (SHF_MERGE sections on both sides of a symbol assignment), shall we perform *(.foo*) constant merge and *(.foo*) constant merge separately?

cat > a.lds <<e
 SECTIONS {
   .out : { start = ABSOLUTE(.); *(.foo*) middle = ABSOLUTE(.); *(.bar*) end = ABSOLUTE(.); }
 }
e
cat > a.s <<e
 .section .foo.0,"aM",@progbits,1; .byte 1; .byte 1
 .section .foo.1,"aM",@progbits,1; .byte 2; .byte 2
 .section .bar.0,"aM",@progbits,1; .byte 1; .byte 1
 .section .bar.1,"aM",@progbits,1; .byte 2; .byte 2
e
gcc -c a.s
ld.bfd -T a.lds a.o -o a
readelf -x .out -s a

The current output (start=0, middle=end=2, i.e. section contents are before `middle`)

Symbol table '.symtab' contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
     2: 0000000000000002     0 NOTYPE  GLOBAL DEFAULT  ABS middle
     3: 0000000000000002     0 NOTYPE  GLOBAL DEFAULT  ABS end
     4: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS start

Hex dump of section '.out':
  0x00000000 0102                                ..

If we treat `middle` as a delimiter and perform merges separately, we will see 0102 on both sides of `middle`.

Re: ld: SHF_MERGE sections on both sides of a symbol assignment

[Alan Modra]

On Fri, May 01, 2020 at 01:11:29AM +0000, Song Fangrui wrote:
> For the following example (SHF_MERGE sections on both sides of a symbol assignment), shall we perform *(.foo*) constant merge and *(.foo*) constant merge separately?
> 
> cat > a.lds <<e
>  SECTIONS {
>    .out : { start = ABSOLUTE(.); *(.foo*) middle = ABSOLUTE(.); *(.bar*) end = ABSOLUTE(.); }
>  }
> e
> cat > a.s <<e
>  .section .foo.0,"aM",@progbits,1; .byte 1; .byte 1
>  .section .foo.1,"aM",@progbits,1; .byte 2; .byte 2
>  .section .bar.0,"aM",@progbits,1; .byte 1; .byte 1
>  .section .bar.1,"aM",@progbits,1; .byte 2; .byte 2
> e
> gcc -c a.s
> ld.bfd -T a.lds a.o -o a
> readelf -x .out -s a
> 
> The current output (start=0, middle=end=2, i.e. section contents are before `middle`)
> 
> Symbol table '.symtab' contains 5 entries:
>    Num:    Value          Size Type    Bind   Vis      Ndx Name
>      0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
>      1: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
>      2: 0000000000000002     0 NOTYPE  GLOBAL DEFAULT  ABS middle
>      3: 0000000000000002     0 NOTYPE  GLOBAL DEFAULT  ABS end
>      4: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS start
> 
> Hex dump of section '.out':
>   0x00000000 0102                                ..

Looks fine to me.  After string merging into .out section there are no
contents remaining in either of the .bar* sections.  You would get
exactly the same result for "middle" if .bar* were empty.  Note also
that symbols defined in the .bar* input sections may well be reordered
with respect to symbols define in the .foo* input sections.

> If we treat `middle` as a delimiter and perform merges separately, we will see 0102 on both sides of `middle`.

I don't see any reason to do this at all.  If people want separate
merges then they should use separate output sections.

-- 
Alan Modra
Australia Development Lab, IBM