RE: Rom based Shared Library

[johnmc at sidsa dot es]

hi jonathan

yes I am producing more than one binary - the minimum number is 2 but
there could be more so the linker script idea would not work. In fact I am
using linker scripts that I have wrote to relocate the code - I dont use
the default script.

About using the address translation mechanism to perform the location I
gather you mean using the MMU - its not something I thought about as I
dont have much experience using the MMU - could you point me in the
direction of some documents that have information on this as it sounds
interesting and I would certainly be interested in using it in the future
if it could work.

What I am doing is using a shared library which can be dynamically loaded
to an embedded flash memory over a satelite air interface - all necessary
address relocation and symbol binding are carried out by the embedded
software and the system can run with the new copy of the shared library.
Also I only have 256kbytes to use so I had to invent a my own protocol for
transmitting the shared library over the air - elf would have been too
large.
Its quite a little challenging project and I would be very interested if
anyone has attempetd such thing before

john

> John:
>
> Somebody else suggested that you investigate linker scripts. If you are
> dealing with a single binary image for your whole system, this is a
> *much* simpler solution than the one that you are contemplating. From
> your description below, though, it sounds like you need multiple binary
> images.
>
> The other thing that has me puzzled: I believe that the ARM 7tdi. Why
> not use the address translation mechanism to perform the relocation?
>
> shap
>
> On Mon, 2006-04-03 at 10:45 +0200, johnmc@sidsa.es wrote:
>> Hi Jonathan
>>
>> Thank you very much for your extensive relply. I can see that you have
>> extensive knowledge and experience in this field so I am begining to
>> have
>> some doubts - its pòssible that I have misunderstood the situation.
>>
>> At the moment I have not run this system that I am developing - I am
>> just
>> starting to debug it.
>> All the conclusions I have come to have been reached by analysing the
>> assembly output.
>> The conclusion about the accesing of the .bss data was reached by
>> looking
>> at the code and the addresses in the GOT to try and see if the data was
>> being accessed using the got .
>>
>> What I will do now is go ahead with the integration and check how the
>> actual code runs - I think it is the only way to be sure.
>>
>> The system that I am developing is based on the ARM 7tdi. It uses the
>> shared library concept to build part of the system "STATICALLY" i.e with
>> load and execution addresses known at load time and part of the system
>> "DYNAMICALLY" i.e. it can be loaded and run anywhere in the address
>> space.
>>
>> This "dyanamic" part can then, theoretically , be reloaded when this
>> system is running in the field . It will actually be reloaded by
>> satelite
>> up load i.e uploaded over the AIR INTERFACE.
>> I have developed my own protocol for transmitting over the air and my
>> own
>> software for dynamic binding etc.
>>
>> Its a complicated system and I would describe it as experimental in
>> nature
>> and this is why I have tried to analyse the compiler/linker output
>> before
>> testing to try and have some confidence that it will work.
>>
>> Anyway I will through caution to the wind and forge ahead with the
>> integration and I will let you know how the .bss situation plays out in
>> practice.
>>
>> thanks again
>>
>> john
>>
>>
>>
>> > On Fri, 2006-03-31 at 11:47 +0200, johnmc@sidsa.es wrote:
>> >> Hi jonathan
>> >>
>> >> The code has been compiled with the fpic option and IS therefore
>> >> position
>> >> independent .
>> >>
>> >> This means that it can be loaded anywhere in memory and the code will
>> >> work
>> >> as it uses PC relative instructions to access the data in the .bss
>> >> section
>> >
>> > John:
>> >
>> > I don't doubt that you are seeing what you are seeing, but this
>> doesn't
>> > sound right. The ELF PIC specification only requires that references
>> to
>> > *external* globals proceed indirectly through the GOT. For historical
>> > reasons (relationship in UNIX of start, etext, edata, ebss, and end),
>> > some compilers *did* use PC-relative references in their PIC
>> > implementations for non-exported data symbols. The requirements are
>> more
>> > stringent for non-static procedures (ALL of which have to be in the
>> > PLT), because these may be overridden by the executable and therefore
>> > must be referenced through a patchable table.
>> >
>> > But before you scream, see below about -fPIC.
>> >
>> >> The global data in the .data section IS referenced using the GOT
>> tables
>> >> so
>> >> this section can be located in
>> >> RAM and the code will still be able to access it as all I have to do
>> is
>> >> change the vectors in the GOT .
>> >
>> > Logically, the .bss section is *part* of the data section. It is very
>> > surprising that the compiler should emit PC-relative references for
>> one
>> > and not the other. Especially so since no processor built within the
>> > last 20 years actually *implements* a PC-relative addressing mode that
>> > can be used by the load/store unit. On modern machines the only way to
>> > implement a PC-relative load is to use something like
>> >
>> > 	call .+1 ; to get PC onto stack
>> > 	pop %somereg
>> > 	load some-offset-from(%somereg)
>> >
>> > Let's back up. Purely as a sanity check (and I'm really *not* trying
>> to
>> > be insulting here), why do you believe that PC-relative addressing is
>> > being used? Have you checked the *disassembly*?
>> >
>> > Also, before I forget, what processor architecture are we talking
>> about?
>> >
>> >> The difference between unix systems, that the shared library concept
>> was
>> >> designed for and the kind of system that I am developing is that the
>> >> data
>> >> does not have to be relocated from FLASH to RAM.
>> >> This is the underlying source of the problem.
>> >
>> > As it happens, you're talking to one of the guys who participated at
>> > only one step remove in the original ELF design -- my group at Bell
>> Labs
>> > built the first ELF-based debugger, and I drafted the original PIC
>> > specification for the MIPS architecture.
>> >
>> > More recently, work on address space randomization has motivated
>> people
>> > to try to avoid the "data=text+offset" assumption.
>> >
>> >> Could you expian to me the difference between
>> >> -fpic or -fPIC -fpie/-fPIE
>> >
>> > Difference between -fpic and -fPIC is the size of the supported data
>> > region. The -fpic option can only be used if the architecture's
>> > "register plus offset" addressing mode has sufficient span to cover
>> the
>> > entire data+bss region. When this is not true, -fPIC must be used,
>> which
>> > uses the GOT in more cases. It may be that compiling with -fPIC will
>> > solve your problem (in fact, it seems likely), though I'm still
>> puzzled
>> > about the data/bss thing.
>> >
>> > The -fpie/-fPIE difference is similar, but these options can only be
>> > used for executables. They permit some optimizations that are not
>> legal
>> > for libraries, such as inlining of certain procedures, removal of
>> > unreferenced procedures from the GOT, and no need to consider the
>> > possibility of a procedure being overridden by a library (this last
>> > permits use of PC-relative CALL in many places where indirection
>> through
>> > the PLT would otherwise be necessary).
>> >
>> > The following may be helpful:
>> >
>> > http://sourceware.org/ml/binutils/2003-05/msg00832.html
>> > http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.html
>> >
>> > It might be worth testing your problem under -fPIC, since this is
>> > specifically intended to suppress certain kinds of relative
>> references.
>> > Worth a shot, can't hurt to try it.
>> >
>> > Also, it may be helpful to look at the ELF portion of the ABI
>> > specification:
>> >
>> >   http://www.caldera.com/developers/devspecs/gabi41.pdf
>> >
>> > and your processor-specific supplement. Depending on your processor,
>> you
>> > might find that here:
>> >
>> >   http://www.linuxbase.org/spec/ELF/
>> >
>> > But also check out the relevant processor-specific spec for LSB:
>> >
>> > 	http://refspecs.freestandards.org/lsb.shtml
>> >
>> > Given how GCC is maintained, it's possible that GCC is implementing
>> LSB
>> > rather than ELF. Perhaps more to the point, the dynamic linking
>> > specification in LSB is reasonably clear.
>> >
>> >> Also why does the GOT table need to be relocated?
>> >
>> > See the description of how the dynamic linker manipulates the GOT at
>> > http://www.linuxbase.org/spec/ELF/ppc64/spec/x954.html in particular
>> the
>> > paragraph beginning "When the dynamic linker...". Basically, the GOT
>> > created by the static linker is a table of unresolved symbol entries.
>> > The job of the dynamic linker is to run through the GOT and PLT tables
>> > filling in the run-time absolute addresses of those symbols.
>> >
>> >
>> > shap
>> >
>> >
>>
>
>



--
For unsubscribe information see http://sourceware.org/lists.html#faq