microblaze port committed

microblaze port committed

[Rich Felker]

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

Re: microblaze port committed

[Isaac Dunham]

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>

Re: microblaze port committed

[Rich Felker]

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

Re: [Aboriginal] [musl] microblaze port committed

[Rob Landley]

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