[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Setting up for Microblaze work.
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.
John Williams wrote:
> 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.
> microblaze-uclinux mailing list
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
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."
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/