Re: [microblaze-uclinux] Building microblaze toolchain

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Scott,

OK I think I've tracked down what's happening, but not quite sure why - 
that'll be your job! :)

First of all, I took your .elf file, converted it with my linux-based 
mb-elf2flt, and it runs fine.  Also, running your flat file, and I got 
the same error.

So, at least we know the problem is with your windows elf2flt build.

I suggest you run your linux-based elf2flt over hello.elf (call that 
lin-hello), so you can do the comparison I'm talking about below:

dump the good flat file:

$ hexdump -C lin-hello

 From offset 0xfc0:

00000fc0  80 00 00 18 00 00 00 84  80 00 00 68 80 00 00 70
00000fd0  80 00 00 8c 80 00 00 a0  80 00 00 a8 80 00 00 f8

This is the relocation table.  If you cross-check with the output of 
elf2flt -v, you can see reloc[1] is 0x18, reloc[2] is 0x84, and so on. 
The 0x80 in the MSB is a flag that is used to signal a special case of 
relocation.

Anyway, repeat the same on the bad hello flat:

$ hexdump -C hello

Again, from offset 0xfc0:

00000fc0  00 00 80 00 00 18 00 00  00 84 80 00 00 68 80 00
00000fd0  00 70 80 00 00 8c 80 00  00 a0 80 00 00 a8 80 00

See what's happened?  You've got a two-byte shift - the relocation table 
is not where it should be, and you can see now why the flat loader is 
picking up a bogus relocation of 0x8000...

Now, I'm not sure why you are getting this two byte shift - that will be 
for you to debug.  I suggest even parallel gdb sessions stepping through 
elf2flt on windows and linuxc, to see what's going on.

Hope this is useful,

John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/