Re: MIPS -gc-sections broken?

[Nick Clifton <nickc at redhat dot com>]

Hi Hiroki,

> You have mentioned that the symbol: gbl_common is swept away in your
> environment, do you have separate section against gbl_common symbol?

No.  In the object file it just appears in the symbol table and in some 
relocations:

  readelf --syms --relocs foo.o

  Symbol table '.symtab' contains 16 entries:
     Num:    Value  Size Type    Bind   Vis      Ndx Name
[snip]
      12: 00000004  7200 OBJECT  GLOBAL DEFAULT  COM gbl_common
[snip]

  Relocation section '.rel.text.func_not_called' at offset 0x594 
contains 3 entries:
   Offset     Info    Type            Sym.Value  Sym. Name
  0000000c  00000e05 R_MIPS_HI16       00000000   __gnu_local_gp
  00000010  00000e06 R_MIPS_LO16       00000000   __gnu_local_gp
  00000014  00000c09 R_MIPS_GOT16      00000004   gbl_common



> Since it is common symbol, there is no section against gbl_common 
> symbol in my environment, and since it is of type GLOBAL OBJECT, it
> is left in the final executable binary, causing the problem.

But in the executable I am getting there is no entry for gbl_common in 
the symbol table, and no relocs referencing anything.

From what you report is happening it looks like the gbl_common symbol 
has been deleted from the symbol table of your executable, but that 
there is still a dynamic reloc referencing it.  Can you confirm this by 
running "readelf -D --relocs test" ?

The problem I have is that I just cannot reproduce the problem locally.
I do not have a mips execution environment or a sysroot, so I cannot 
build an entire mips-linux toolchain.  I have tried faking it, but all 
of my toolchains appear to work and cannot reproduce the problem.  So my 
best answer is still to try modifying your loader.


> One solution could be modifying the loader to check such a symbol,
> however, it would result in slower startup time... 

Well your loader is already reporting an error for an undefined symbol. 
 All you would need to do is skip the error message, or maybe turn it 
into a warning.

> I'd appreciate if
> pointer to information regarding how section is swept in binutils is
> supplied.

Well the process is started in the ld/ldlang.c:ld_gc_sections() 
function.  This scans the linker script for any input sections that have 
been specially marked with the KEEP attribute and handles a special case 
for relocatable links before calling 
bfd/elflink.c:bfd_elf_gc_sections().  You can follow the process from 
there yourself.  The basic idea is to examine all the relocations for 
all of the input sections that have the KEEP attribute or contain the 
starting symbol.  For each of these relocations the section containing 
the symbol referenced by the relocation is checked and if it has not 
already been marked for inclusion, it is added to the list of kept 
sections.  Eventually all input sections that can be reached via 
relocations from the starting symbol (or the KEEP sections) will have 
been marked for inclusion and all of the remaining sections can be 
discarded.

Cheers
  Nick