g77 pic case vs. binutils & readelf

[Robert Lipe]

Good tip, Nick.   Thanx.


Interestingly, this problem goes away if I change the _link_ of
the testcase to not pick up ../i6*/pic/libf2c but instead to snare
../i6*/libf2c/ directly.  If we're somehow miscompliing pic/libf2c that
would explain a lot.  OpenServer is the only x86 target that builds a
pic version of libf2c, I think.  This would explain why the .s for the
testcase looks identical to the .s for the targets that pass.



(gdb) print symtab
$1 = (struct elf_internal_sym *) 0x806ca38
(gdb) print symtab_index
$2 = 283312

Chasing it back upstream, I see that rel_size is 4.  The entry that gets
us into trouble (relas[2]) looks like this:

(gdb) print /x relas[2]
$28 = {r_offset = 0x0, r_info = 0x452b28, r_addend = 0x3}

That r_info does seem to be what's getting us into trouble.   (That 
looks awfully ASCII-ish to me.)


dump is somewhat like objdump or readelf.  I think it's lending affirmation
to the problem that's making readelf (and presumably my dynamic linker) choke:

$ dump -rv xxx

xxx:

    **** RELOCATION INFORMATION ****

.rel.got:
Offset      Symndx                 Type

0x805582c   errno                  R_386_GLOB_DAT    
0x805586c   ungetc                 R_386_GLOB_DAT    
0           0                      R_386_NONE        
dump: xxx: invalid symbol table offset - 17707 - in .rel.got



Things are pointing to something in the build of pic/libg2c.a going bad,
no?   How to find where?

RJL



> : (gdb) 
> : Continuing.
> :   0805586c  02b06 R_386_GLOB_DAT        08048ab4  ungetc                   
> :   00000000  00000 R_386_NONE           
> : 
> : Breakpoint 2, dump_relocations (file=0x452b28, rel_offset=40, rel_size=4, 
> :     symtab=0x806ca38, strtab=0x806c6c0 "", is_rela=0)
> :     at /play/binutils/binutils/readelf.c:577
> : 577               psym = symtab + symtab_index;
> : (gdb) s
> : 579               printf (" %08lx  ", (unsigned long) psym->st_value);
> : (gdb) 
> : 
> : Program received signal SIGSEGV, Segmentation fault.
> 
> The most likely things is going wrong here is that 'symtab_index' is
> some stupid value (ppossibly negative).  It is extracted from the
> 'info' field of the reloc with the macro ELF32_R_SYM().  My guess is
> that this field is not being initialised correctly when the reloc is
> being created.
> 
> Cheers
> 	Nick