Re: [rfc] declaring new object format "FDPIC ELF"

[Mike Frysinger <vapier at gentoo dot org>]

On Monday 21 April 2008, Daniel Jacobowitz wrote:
> On Mon, Apr 21, 2008 at 06:49:58PM -0400, Mike Frysinger wrote:
> > what i have a problem with is this:
> >  - bfin-uclinux-{gcc,as,ld} produces elf without users having to do
> > anything - bfin-linux-uclibc-{gcc,ld} produces fdpic without users having
> > to do anything
> >  - bfin-linux-uclibc-as produces elf if user doesnt do anything which
> > means any linking steps bombs out with ugly/confusing binary format
> > mismatches - if you want to execute bfin-linux-uclibc-as directly, you
> > need to explicitly specify "-mfdpic"
>
> I see.  My personal feeling is to not care about this.  We tell all our
> users (and our IDE) to assemble files using the GCC driver; this keeps
> all configuration in one place and everything works like a charm.

FRV addresses the issue in their source code by saying "if it's a linux 
target, we'll default to FDPIC".  i really dont like that at all and it isnt 
usable for us anyways.

> Interesting, you use fdpic for full Linux too?  We have only been
> looking at it for uClinux so far, but of course SH has a working PIC
> model already and I don't know if FRV/bfin do besides FDPIC.

there is currently no Blackfin part with an MMU.  some magical day in the 
future if we do get a MMU, we'll most likely support both FDPIC ELF and ELF.  
the ELF support will just be an extension of what we already have in place 
for producing bare metal ELFs / FLAT binaries.

we say uClinux is Linux ;) ... after all, the uClinux patchset nowadays is 
just a vendor patchset -- full of drivers/arch updates.  kernel.org has 
everything we need.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.