[MIPS][bfd] Merging mips .reginfo sections

[Simon Atanasyan]

On Wed, Apr 1, 2015 at 10:46 AM, Matthew Fortune
<Matthew.Fortune@imgtec.com> wrote:
>> It looks like the ld.bfd linker does not merge .reginfo sections from
>> input object files and just writes registers masks
>> (ri_gprmask/ri_cprmask) taken from the first object file.
>>
>> $ objdump -s -j.reginfo 1.o
>> Contents of section .reginfo:
>>  0000 04000000 00000000 00000000 00000000
>>
>> $ objdump -s -j.reginfo 2.o
>> Contents of section .reginfo:
>>  0000 02000000 00000000 00000000 00000000
>>
>> $ ld.bfd -m elf32ltsmip -shared 1.o 2.o
>> $ objdump -s -j.reginfo a.out
>> Contents of section .reginfo:
>>  00d4 04000000 00000000 00000000 00000000
>>
>> $ ld.bfd -m elf32ltsmip -shared 2.o 1.o
>> $ objdump -s -j.reginfo a.out
>> Contents of section .reginfo:
>>  00d4 08000000 00000000 00000000 00000000
>>
>> $ ld.bfd -version
>> GNU ld (GNU Binutils) 2.25.51.20150318
>>
>> Could anybody explain why the ld.bfd uses this approach and takes
>> ri_gprmask from the first object file and ignores other .reginfo
>> sectons?
>
> The code below (from bfd/elfxx-mips.c) is intended to do this merging.
> I'm not sure why this appears to be failing according to your example
> above. There is an inconsistency it seems in the output you show as
> the 08000000 bit is not set in either input file.
>
> I'm afraid I don't entirely understand how the map_head.link_order is
> put together but it seems that either objects are missing from that
> or the special case relating to bfd_data_link_order is kicking in.

I saw this code and could not understand why I did not get expected
result. I thought that I missed something well known or trivial.

> What is the source/content of the 1.o/2.o?

$ cat 1.s
  .text
  .globl  foo1
foo1:
  addiu   $2,$2,1

$ cat 2.s
  .text
  .globl  foo2
foo2:
  addiu   $3,$3,1

$ as -mips32r2 -EL -o 1.o 1.s
$ as -mips32r2 -EL -o 2.o 2.s

Thanks for your help.

--
Simon Atanasyan