Finding BFD bug

[Ian Lance Taylor]

pladow@pullman.com writes:

> 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?

It's also possible that the relocation processing is wrong: perhaps
the object file contents are supposed to be ignored when processing
the relocation.

> > A key question, which can not be answered without knowing the intended
> > ABI.
> 
> I have the ABI.  What can I glean from there?

If it is a typical ELF processor supplement document, it will document
the precise computation which the relocs are supposed to perform.
What is that computation?

> 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?

It suggests that the src_mask field should be 0 rather than
0xffffffff.

Ian