RE: [microblaze-uclinux] Building microblaze toolchain

[Scott Thibault <thibault@xxxxxxxxxx>]

Okay, with that info. it was easy to find.  The output file is opened
with open, closed, and then re-opened with fopen.  When it is re-opened
with fopen it is not opened in binary mode, thus some extra data is
getting stuffed into the file.  Made the one character fix of adding a
'b' to the mode and everything is working fine.

Thanks for pin-pointing the error for me.  Your help was invaluable.

--Scott

> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au 
> [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On Behalf Of 
> John Williams
> Sent: Thursday, October 28, 2004 6:04 PM
> To: microblaze-uclinux@itee.uq.edu.au
> Subject: Re: [microblaze-uclinux] Building microblaze toolchain
> 
> 
> 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/

___________________________
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/