* microblaze port committed
@ 2012-09-29 5:41 Rich Felker
2012-09-30 7:01 ` Isaac Dunham
0 siblings, 1 reply; 4+ messages in thread
From: Rich Felker @ 2012-09-29 5:41 UTC (permalink / raw)
To: musl
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
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.
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).
4. Until very recently, qemu did not support the lwx/swx instructions
needed for implementing atomics, and treated them instead as plain
lw/sw (load/store). I've added one otherwise-wasteful instruction
to the atomic asm in atomic.h so that atomic cas/swap will at least
behave as an equivalent non-atomic operation on older qemu, rather
than randomly going into infinite loop. Older hardware may be
affected by this issue too.
I'm sure we'll find other problems once there's a better build/test
environent in-place, but overall this seems to be the best
initial-commit quality of any port yet, probably due to the fact that
the microblaze ISA+ABI is the sanest, simplest ISA+ABI I've ever coded
to.
Rich
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: microblaze port committed
2012-09-29 5:41 microblaze port committed Rich Felker
@ 2012-09-30 7:01 ` Isaac Dunham
2012-09-30 13:16 ` Rich Felker
2012-10-27 6:51 ` [Aboriginal] [musl] " Rob Landley
0 siblings, 2 replies; 4+ messages in thread
From: Isaac Dunham @ 2012-09-30 7:01 UTC (permalink / raw)
To: musl; +Cc: aboriginal
On Sat, 29 Sep 2012 01:41:57 -0400
Rich Felker <dalias@aerifal.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
>
> 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)
-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.)
-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?
--
Isaac Dunham <idunham@lavabit.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: microblaze port committed
2012-09-30 7:01 ` Isaac Dunham
@ 2012-09-30 13:16 ` Rich Felker
2012-10-27 6:51 ` [Aboriginal] [musl] " Rob Landley
1 sibling, 0 replies; 4+ messages in thread
From: Rich Felker @ 2012-09-30 13:16 UTC (permalink / raw)
To: musl
On Sun, Sep 30, 2012 at 12:01:41AM -0700, Isaac Dunham wrote:
> On Sat, 29 Sep 2012 01:41:57 -0400
> Rich Felker <dalias@aerifal.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
> >
> > 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)
It's also worth noting that their toolchain is somehow (gratuitously?)
incompatible with objects from a standard toolchain, or at least the
old binary one they released was. I haven't checked if the current
source still has issues.
> -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.)
For mips (32-bit with o32 abi), this is definitely true. For
microblaze, I'm not sure. I would have to try compiling a test program
that uses global vars from libc and see which type of relocations get
used.
> -The possibility of using mapfiles instead of -Bsymbolic-functions
> was mentioned, but Rich doubts that they were supported in older
> binutils.
It's also incredibly ugly. I don't intend to make such a change
upstream.
Rich
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Aboriginal] [musl] microblaze port committed
2012-09-30 7:01 ` Isaac Dunham
2012-09-30 13:16 ` Rich Felker
@ 2012-10-27 6:51 ` Rob Landley
1 sibling, 0 replies; 4+ messages in thread
From: Rob Landley @ 2012-10-27 6:51 UTC (permalink / raw)
To: Isaac Dunham; +Cc: musl, aboriginal
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@aerifal.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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-10-27 6:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-29 5:41 microblaze port committed Rich Felker
2012-09-30 7:01 ` Isaac Dunham
2012-09-30 13:16 ` Rich Felker
2012-10-27 6:51 ` [Aboriginal] [musl] " Rob Landley
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).