[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1351320712.16093.6@driftwood>
Date: Sat, 27 Oct 2012 01:51:52 -0500
From: Rob Landley <rob@...dley.net>
To: Isaac Dunham <idunham@...abit.com>
Cc: musl@...ts.openwall.com, aboriginal@...ts.landley.net
Subject: Re: [Aboriginal] microblaze port committed
My email was broken forever, but I've built a new one out of duck tape
and am attempting to deal with the backlog:
On 09/30/2012 02:01:41 AM, Isaac Dunham wrote:
> On Sat, 29 Sep 2012 01:41:57 -0400
> Rich Felker <dalias@...ifal.cx> wrote:
>
> > Hi all,
> >
> > I've committed the initial (and seemingly fully-working) version of
> > the microblaze port. Several caveats:
> >
> > 1. Upstream binutils has a serious bug in gas whereby the
> relocations
> > it generates for symbols with local weak definitions cannot be
> > resolved by the linker. Patch at:
> > http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11155
My current understanding is this bug was introduced _after_ 2.17, so
doesn't hit my frozen toolchain?
> > 2. The toolchain binaries from Xilinx seem to produce .o files
> > incompatible with standard binutils, and vice versa. Pick one or
> > the other; don't mix them.
> For Landley's sake, I'll mention what we discussed on IRC (+ some
> details):
> -The Xilinx toolchain is binutils 2.16 + gcc 4.1.2 (GPLv2); binutils
> support was merged upstream in 2009, so Aboriginal would need the
> Xilinx EDK toolchain (see http://git.xilinx.com/?
> p=mb_gnu.git;a=summary
> ofor source)
I've had a xylinx toolchain of approximately that vintage in my todo
heap for a couple years, the problem is their changes broke arm. (If
you build an arm toolchain from those sources, it didn't work.)
I can try refreshing from xylinx git, but getting basic musl support in
is comes first. (Maybe 1/3 through ccwrap.c rewrite, I'm doing the new
one to be a reasonable base for later qcc and distcc replacement work.)
> -Rich says that on microblaze, due to the way relocations are
> handled,
> using -Bsymbolic instead of -Bsymbolic-functions gives a libc.so that
> is either minimally broken or fully operational.
> (Mips also works with -Bsymbolic.)
I already updated binutils to the new version musl needs. I can build
musl, it's just my ccwrap is full of uClibc baked-in assumptions that
need to go away, and the code's brittle enough I'm just writing a fresh
one.
> -The possibility of using mapfiles instead of -Bsymbolic-functions
> was
> mentioned, but Rich doubts that they were supported in older
> binutils.
>
> > 3. Threads are untested because qemu is broken, at least my version
> of
> > qemu (app-level emu) has a bug where clone() does not advance
> the
> > program counter properly in the child, so it starts a
> forkbomb-like
> > cascade of clone syscalls (thankfully just linear growth rather
> > than exponential).
> Ow.
>
> Rob, any thoughts on an Aboriginal port?
I want to do one, but I want to start with x86, then arm, then the
other existing platforms I can compare against a known working version
of.
Rob
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
