[uClibc] brk, mmap and unwinding in uclibc

Peter S. Mazinger ps.m at gmx.net
Fri May 14 20:58:42 UTC 2004


On Fri, 14 May 2004, Erik Andersen wrote:

> On Fri May 14, 2004 at 09:03:40PM +0200, Peter S. Mazinger wrote:
> > Hello!
> > 
> > I have tried to build upx (a compressor) against uclibc, and had some 
> > discussions w/ the developers of upx. Here are their relevant comments:
> > 
> > part1:
> > I created a synthetic testcase 'short.c' [attached], and built it.
> > 
> > The required datafile 'empty' is created by:
> > 	dd if=/dev/zero bs=45424 count=1 > empty
> > Finally, I ran
> > 	LD_LIBRARY_PATH=. ./short
> 
> Why are you messing with LD_LIBRARY_PATH?

this was running on the upx developers system, non-uclibc

> 
> > On a kernel-2.4.20-28.9 system, running the 'short' example always works;
> > the output is "39992\n".  But on a kernel-2.6.5 system that uses
> > exec-shield-randomize, it aborts with SIGSEGV about 25% to 30% of the time.
> > Turning off exec-shield-randomize on the same kernel-2.6.5-1.358 system
> > enables the 'short' testcase to work 100% of the time.  This behavior
> > indicates that uClibc cannot handle the random placement of mmap()
> > that the kernel uses when exec-shield-randomize is 1.  Also, I suspect
> > that there may be a problem with the uClibc implementation of brk()
> > under exec-shield-randomize.
> 
> 
> Your example (after fixing up a few obvious things like the main
> prototype, casting the printf arguments to match the conversion
> specifier, including stdio.h, etc) outputs "39992\n" with uClibc
> with stock 2.4.26 and 2.6.6 kernels.
> 
> As has been discussed several times, uClibc does not presently
> support exec-shield-randomize stuff.  As you are the only person

well I do not use exec-shield-randomize myself, but all the redhat 
kernels as of 2.4.20 - 2.6.x, i am using PaX (ok, it is another 
randomization)

> I am presently aware of that is using uClibc in this way, the
> burden for adding support for this stuff lies with you...  Thus
> far, it is pretty clear you have not managed to interest any of
> the uClibc maintainers in researching this stuff and adding
> support for this.  Repeatedly posting the details of your
> favorite unsupported feature is guaranteed to not help much.

I wanted to show you that there are other cases as well, that do not work 
correctly w/ the current implementation

> 
> > part2:
> > > Under glibc running upx against an already packed file exits w/ code 2, on 
> > > uclibc it gets signal 6, coredumps (and the protection in my kernel 
> > > catches this, exits w/ 134), the kernel is although the same
> > 
> > There are signs of an incompatibility between uClibc startup code
> > and libgcc_s 'throw'.  Under glibc, trying to pack a file that is
> > already packed gets a message on stderr:
> > 	upx: date: AlreadyPackedException: already packed by UPX
> > This occurs as a result of throwing a C++ exception with a constructor
> > that takes a  char *  argument.  The exceptions are caught, the message
> > is printed, and then exit(2).
> > 
> > I tried packing an already-packed executable using upx with uClibc.
> > I saw no message on stderr, did see the kill() that results from
> > not finding the right catcher, and the traceback was:
> [----------snip-----------]
> > So, the throw+catch are not hooking up properly under uClibc.
> > This is uClibc's problem.
> 
> What version of uClibc?  gcc?  binutils?  How did you build your
> toolchain?  Was gcc built with --enable-sjlj-exceptions?  What
> kernel version are you using?

The uclibc tested was as of cvs2004050x, sjlj-exceptions were enabled (all 
the used options from buildroot were used). I have rpm's that do the same 
as buildroot for binutils/gcc building, unless the stages, because I am 
in a pure uClibc environment.
gcc-3.3.3 and gcc-3.4.0
binutils-2.14.90.0.8 and 2.15.90.0.3
kernel-2.4.26 (pax/grsecurity enabled), kernel-2.4.22 (redhat)
kernel headers used by uclibc are 2.4.26

> 
> > part3:
> > comment on gdb #5: __cxa_throw ()
> > >From the backtrace above it looks that somethings goes wrong during stack 
> > unwinding - does exception catching work for other C++ programs ?
> 
> It does if gcc was built properly...
> 
>     http://codepoet.org/throw1.cpp
>     http://codepoet.org/throw2.cpp

i'll test them later on and report back what I have found.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2


____________________________________________________________________
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu



More information about the uClibc mailing list