Re: [microblaze-uclinux] Setting up for Microblaze work.

["David H. Lynch Jr" <dhlii@xxxxxxxxxxx>]

    Thank You;

          That clears things up alot. I was not aware that ELF files did
not contain relocation information. That is very surprising.

          I have been at this along time. I am aware of tricks like
compiling a program at two different base addresses and then comparing
them to produce a relocation table (as in CP/M)
          Untold centuries ago, I wrote a binary patch for Heath's HDOS
operating system that caused the kernel of the OS to load in a small
hunk of unused static RAM. 80% of that patch
          was patching the relocation table entries. I have worked in
alot of OS's and on alot of hardware, that either did not have an MMU,
or was oblivious to it (MSDOS as an example)
          that had relocatable executables.

          I am not yet intimate with the MicroBlaze, doesn't it have the
relative addressing needed for PIC ?

          I will look at binfmt_flat.

    Thanks again.


John Williams wrote:
> David,
>
> David H. Lynch Jr wrote:
>
>>           I am still trying to sort out whether and why  MMUless cpu
>> can not use an ELF file.
>
> ELF application binaries have no relocation info - All relocations are
> resolved to a base address of zero.  The final link phase of building
> an ELF app strips out all relocation data - gone.
>
> Try this:
>
> [jwilliams@g512-9423 Core]$ objdump -r /bin/sh
>
> /bin/sh:     file format elf32-i386
>
>
> No relocations.
>
> MMU-full CPUs map applications into their own zero-based virtual
> address space, and the MMU + kernel page fault handlers do the rest.
>
> On NOMMU, we can't do that.  Each app runs in a physical address
> space, based at whatever address is given by the kernel when memory is
> allocated for the text segment.
>
> At load time, the binfmt_flat loader must instead go through the
> binary, and relocate all the jumps, address references - anything that
> needs relocation.
>
> So, a flat binary is sort of a binary dump of the object code, plus a
> relocation table to allow the kernel to do its job, relocating the
> binary to whatever address the text, data and bss segments ultimately
> get placed at.
>
> As an aside, this is why PIC compilers are so useful for NOMMU targts
> - if you can generate fully position independent code, you can get
> away with few, or no relocations.  That speeds app load time, and lets
> you do great things like directly mmap()ing the filesystem backing
> store into the app's text segment - load time is zero, just start
> executing straight off the "disk" (or rather flash, or mem file system).
>
> See fs/binfmt_flat.c for the gory details.
>
> Regards,
>
> John
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>
>


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@xxxxxxxxxx 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

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