Finding BFD bug

[pladow@pullman.com]

Thanks a lot for the prompt reply!

> This is a more or less typical relocation problem.  BFD's handling of
> relocations is poorly designed and basically broken.  Historically
> people just workaround the issues.

I'm wide open to a workaround.  We refer to externed symbols extensively in 
the code.  And as I showed, just referring to external assembly symbols is a 
problem.

How does one workaround this?  Get rid of externs?  That's nearly impossible.

> The problem is most likely in the assembler.  Perhaps the tc_gen_reloc
> function needs some tweaks, or perhaps the special howto function
> needs work.

I'm going to dig around in the assembler.  Thanks for the pointer.

> To tell just where the problem is requires looking at the contents of
> the object file generated by the assembler: the relocation information
> and, perhaps, the section contents.  The assembler needs to generate
> something which the linker will process correctly.
> 
> It's difficult to be more specific without more information.

We did more digging, and I found more info.  References to external symbols 
from the text section are not broken.  For example:

file1.s:
globl test

data

/* Array of 6 32-bit integers */
test:
  .data32 0
  .data32 1
  .data32 2
  .data32 3
  .data32 4
  .data32 5

main.s:

globl main

data
p1:
  .data32 test
p2:
  .data32 test+4
p3:
  .data32 test+8

text
main:
  addik r3,r0,test
  addik r4,r0,test+4 /* &test[1] */
  addik r5,r0,test+8 /* &test[2] */
  rtsd  r15,8
  nop

However, I did notice that the values prior to relocation are all zeros in the 
text section, where the relocations in the data section have the offsets.  The 
disassembly shows:

mb-objdump -d main.o

main.o:     file format elf32-microblaze

Disassembly of section .text:

00000000 <main>:
   0:   b0000000        imm     0
   4:   30600000        addik   r3, r0, 0
   8:   b0000000        imm     0
   c:   30800000        addik   r4, r0, 0
  10:   b0000000        imm     0
  14:   30a00000        addik   r5, r0, 0
  18:   b60f0008        rtsd    r15, 8
  1c:   80000000        or      r0, r0, r0

Note at 0x04, 0x0c, and 0x14 all have zero for the address of test, test+4, 
test+8.  However, doing a full dump of the data section:

$ 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           ............

$ mb-nm main.o
00000000 T main
00000000 d p1
00000004 d p2
00000008 d p3
         U test

The data for p1, p2, and p3 have the offsets embedded in the data.  So I'm 
guessing at link time it addes the contents of data section plus any 
relocation information in the object file.  Hence the "doubling" of the 
offsets.

So is the problem in the embedding of the offsets in the actual data?  Or 
should the relocation information in the object file be zero?


Thanks for your help,
Pete


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