[fedora-arm] dietlibc port?

[Gordan Bobic]

On 01/06/2011 11:15 PM, Rich Mattes wrote:
>>> Andy Green wrote:
>>> > On 01/06/11 16:17, Somebody in the thread at some point said:
>>> >
>>> > Hi -
>>> >
>>> >> Digging a bit more, it seems that bin-arm/diet segfaults when
>>> executed
>>> >> without any parameters, so it seems that this is the bit that
>>> >> miscompiled somewhere.
>>> >
>>> > Did you try running it in gdb and get a clue about what blows?
>>>
>>> Not yet, no.
>>>
>>> >> It turns out that the problem is actually to do witha GCC bug.
>>> When it
>>> >> is building bin-arm/diet with -Ox (x = {s,2,3}) , the resulting
>>> binary
>>> >> segfaults. When the binary is built with -O1 or -O0, it works fine.
>>> >
>>> > Is there a particular gcc bug you traced it down to? Because it does
>>> > not follow that all changes to program behaviour with different
>>> > optimization options are necessarily gcc bugs; it can show up
>>> > broken-ness in code that happens to not show symptoms according
>>> to how
>>> > it is compiled.
>>>
>>> That's fair, but an awful lot seems to break. If dietlibc really is that
>>> broken, I have to question how it ever worked for anyone reliably. I'm
>>> also wondering if it might be some of the Fedora patches that are
>>> breaking it. I'll try it without any post-0.32 patches.
>>>
>>> You should also probably try the F13 gcc. Bugs reported against the
>>> F12 gcc are going to be ignored, since nobody is working on any F12
>>> stuff anymore.
>>
>> I am slowly shifting things over to F13, but there is a lot to DIY
>> build. For example, things like Firefox don't work because of an API
>> version mismatch with xulrunner. And it helps to have a relatively
>> usable system to do development on. :)
>>
>> Besides, the reason I need dietlibc is because util-vserver requires
>> it and I want to work on F13 stuff in a vserver chroot in order to
>> ensure that the host system remains operational even if I badly break
>> important low-level things.
>>
> Ah, I see. I've just been using a plain chroot into the f13 rootfs with
> /proc bind mounted to the rootfs /proc, but it looks like vserver has
> some more features.

OK, I have tried F13 gcc. It turns out that dropping in the koji 
repository and doing yum update gcc does the trick without clobbering 
too much, and without causing the whole of F12 to fall over. This is a 
good sign. :)

It is only a small update, it seems, from 4.4.2 to 4.4.4.

It also makes absolutely no difference. The same thing happens. The 
build fails with segfaults during the build (the "diet" binary built 
during the build gets used) with -On, n={s,2,3}. The build succeeds with 
-On, n={0,1}. However, even with -O0 about half of the tests fail with 
segfaults.

I also tried a vanilla dietlibc 0.32 build from a tarball, and 
predictably, that doesn't work any better at all.

gdb reveals the following:
# gdb atexit
(gdb) run
Starting program: /usr/src/redhat/BUILD/dietlibc-0.32/test/atexit

Program received signal SIGSEGV, Segmentation fault.
0x00008230 in ?? ()
(gdb) backtrace
Cannot access memory at address 0x0
#0  0x00008230 in ?? ()
#1  0x000081dc in __libc_exit (code=0) at lib/atexit.c:25
#2  0x00008104 in _start () at arm/start.S:34

So the problem seems to be in arm/start.S on line 34.

_start:

         mov     fp, #0                  @ clear the frame pointer
         ldr     a1, [sp], #4            @ argc
         mov     a2, sp                  @ argv
         ldr     ip, .L3
         add     a3, a2, a1, lsl #2      @ &argv[argc]
         add     a3, a3, #4              @ envp
         str     a3, [ip, #0]            @ environ = envp
         bl      main

@
@ The exit status from main() is already in r0.
@ We need to branch to 'exit' in case we have linked with 'atexit'.
@
         bl      exit

Line 34 is the one with "bl exit" on it. My ARM assembly isn't really up 
to the task of debugging this further at the moment.

Has anyone ever managed to get dietlibc to build on ARM Linux before?

Having said that, I just tried building the F12 and F14 dietlibc 
packages from src.rpms on a RHEL6b2 machine (x86-64), and some of the 
tests fail with segfaults there, too...

It's almost half tempting to install the broken build for dependency's 
sake and see if util-vserver actually trips any of it at run-time. But I 
am a little concerned WRT whether this actually works and passes all 
self-tests even on x86 Fedora.

Gordan