Alexander Stein wrote:
> I also read about FDELF_PIC, but according to Greg it is only
> supported on FRV and Blackfin. What is needed to be done, to get
> FDELF_PIC supported on Coldfires (m68k in general). AFAIK there is
> no distinction bewteen MMU and NOMMU with this type of binary. What
> would be the effort for doing this?
To support FDPIC-ELF, you need to:
- Define the ABI: choose a register, choose how a function descriptor
is represented and updated, and how functions are called through it,
and work out what new relocation types will be needed.
It's a really good idea to read the existing FDPIC-ELF ABI
documents, and write your own with the architecture bits
replaced. A familiarity with ELF PIC is helpful.
The function call sequence(s) should be small and fast, which
may affect the choice of registers. You may have to alter the
set of call-clobbered registers to accomodate the different
descriptor types (and if it's anything like ARM a whole bunch of
other things to interoperate with all the existing ABI quirks!).
Function descriptor update should be effectively atomic, perhaps
by choosing the right word order.
Register choices should be chosen to minimise breaking existing
assembly language code such as you might find in libc and
applications, and at least planning to be compatible with
NPTL/TLS is a good idea.
- Modify Binutils to assemble and link FDPIC-ELF code and create
the FDPIC function descriptors. Some of this is already in
Binutils generically, and you just have to add the
architecture-specific parts, mostly processing new relocation
types and patching together the FDPIC table.
- Modify GCC to produce FDPIC-ELF function calls and the
appropriate command line options.
- Modify uClibc and/or Glibc to provide an FDPIC-ELF dynamic
loader, dlopen() etc.
- Modify any other parts of uClibc and/or Glibc which make
assumptions about register usage, for example the system call
stubs and anything which tests if __PIC__ if defined.
I did some work on FDPIC-ELF for ARM, but that stopped due to
other priorities. I would classify it as a "medium" amount of work :-)
I.e. far from trivial but not a huge project, and breaks naturally
into easily checked pieces.
-- Jamie
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
