Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.