Re: Finding BFD bug

[pladow at pullman dot com]

Thanks for a quick reply!

> First step - check the relocs in the object file.  (eg using "objdump 
> -dr").  If the relocs have +8 and +16 in them then it is an assembler 
> bug rather than a linker bug.

The output looks good.  Here's the output:

$ mb-objdump -r main.o

main.o:     file format elf32-microblaze

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
00000000 R_MICROBLAZE_64   test
00000008 R_MICROBLAZE_64   test+0x00000004
00000010 R_MICROBLAZE_64   test+0x00000008


RELOCATION RECORDS FOR [.data]:
OFFSET   TYPE              VALUE
00000000 R_MICROBLAZE_32   test
00000004 R_MICROBLAZE_32   test+0x00000004
00000008 R_MICROBLAZE_32   test+0x00000008

But in fact, a full dump shows:

$ mb-objdump -s main.o

main.o:     file format elf32-microblaze

Contents of section .text:
 0000 b0000000 30600000 b0000000 30800000  ....0`......0...
 0010 b0000000 30a00000 b60f0008 80000000  ....0...........
Contents of section .data:
 0000 00000000 00000004 00000008           ............

So both the relocs and the data have the offsets.  So we get 0+0, 4+4, and 
8+8.  This explains the doubling.  But which is wrong?  The relocs?  Or the 
embedded offsets?

> If the relocs contain +4 and +8 then have a look for a file in the 
> sources called something like bfd/elf32-xilinix.c o or 
> bfd/elf32-microblaze.c.  This will/should contain the Xilinix specific 
> code that is probably causing the problem.  Look for a function with 
> "final_link_relocate" as part of its name.  This is probably where the 
> bug can be found.

I've dug around in elf32-microblaze.c.  In fact, I've stepped through the code 
in the debugger for ld, and in microblaze_elf_relocate_section, the default 
case is called that calls _bfd_final_link_relocate.  The arguments passed for 
relocation (value in _bfd_final_link_relocate) is the base address of test, 
but addend is set to 0, 4 or 8.  I see that _bfd_final_link_relocate adds 
value and addend.

>From Ian:
> A key question, which can not be answered without knowing the intended
> ABI.

I have the ABI.  What can I glean from there?
 
> What does the relocation information look like--objdump -r or readelf
> -r?

See above.

> In a sense, it doesn't matter.  It just has to be self-consistent.  It
> sounds like the easiest way to be consistent is to make the object
> file contents zero.  The easiest way to do that is to tweak

Wouldn't this break the assembler for other architectures?  Regardless it 
fixes our problem for now.

> tc_gen_reloc, or track down the howto function and make it do the
> right thing.  Does the howto function call bfd_elf_generic_reloc()?

Most of the howtos have bfd_elf_generic_reloc().  The one that is used when 
these are broken is:

   /* A standard 32 bit relocation.  */
   HOWTO (R_MICROBLAZE_32,     	/* type */
          0,			/* rightshift */
          2,			/* size (0 = byte, 1 = short, 2 = long) */
          32,			/* bitsize */
          false,			/* pc_relative */
          0,			/* bitpos */
          complain_overflow_bitfield, /* complain_on_overflow */
          bfd_elf_generic_reloc,	/* special_function */
          "R_MICROBLAZE_32",   	/* name *//* For compatability with coff/pe 
port.  */
          true,			/* partial_inplace */
          0xffffffff,		/* src_mask */
          0xffffffff,		/* dst_mask */
          false), 		/* pcrel_offset */

And it does have bfd_elf_generic_reloc() as the special function.

However, I can't seem to find where it is called.  I did stumble across a 
comment in the code that might be revealing:

   /* Addends are stored with relocs.  We're done.  */

That give any hints?

Thanks again,
Pete

---------------------------------------------
This message was sent by First Step Internet.
           http://www.fsr.net/