[Gc] trouble with gc-7.2d compiling against musl libc

John Spencer maillist-boehm at barfooze.de
Tue Jan 15 07:24:32 PST 2013


Ping.

It's now over a week that we didnt hear from you, at first i thought the 
radio silence is due to holidays or even an accident, but your github 
activity tab says otherwise.

btw, i forgot to mention that you don't need to use sabotage linux in 
order to test the GC against musl, it is sufficient if you install musl 
into a custom prefix (/usr/local/musl) with --enable-wrapper and then 
use "musl-gcc" wrapper to compile boehm gc.

also, Rich and I did some debugging and it seems that boehm gc still 
uses some hacks related to ancient LinuxThreads. like raising 
SIGPWR/SIGXCPU and similar oddities. any such workarounds/hacks cant 
work on musl libc of course, since the pthread implementation was done 
from scratch and is completely unrelated to LinuxThreads.

oh, and at least in 6.8, there's a race condition:
the wrapper for pthread_join performs the join, _then_ removes the 
pthread_t from the GC's list of threads.
however the pthread_t value may have already been reused at this point.

is there a switch that makes the boehm GC disable all ugly hacks ? i 
guess not...



On 01/09/2013 07:55 PM, John Spencer wrote:
> Hi Ivan,
>
> did the results of "make check" give you any clue ?
>
> On 01/08/2013 11:31 AM, Ivan Maidanski wrote:
>>>>>> which algorithm is used for detection of main stack base in your
>>>>>> case? which macro is defined - STACKBOTTOM, HEURISTIC1,
>>>>>> LINUX_STACKBOTTOM?
>>>>>
>>>>> out of these 3, only LINUX_STACKBOTTOM seems to be defined (i added
>>>>> #warnings into os_dep.c in order to find out)
>>>> Seems to be correct.
>>>> Does GC_get_main_stack_base return reasonable value?
>>>
>>> how can i check ?
>> What is the difference between this value and address of any local var
>> of main() function? (It should not be bigger than several K.) Is this
>> value bigger than that local var address? (stack grows down on your
>> target, right?)
>
>
> ~/GC/bdwgc # cat test.c
> #include "include/private/gc_priv.h"
> #include <stdio.h>
>
> int main() {
> int a;
> dprintf(2, "a: %p, stack: %p\n", &a, GC_get_main_stack_base());
> }
>
> ~/GC/bdwgc # gcc test.c -L".libs/" -lgc
> ~/GC/bdwgc # LD_LIBRARY_PATH=.libs ./a.out
> a: 0x7fff6ff6728c, stack: 0x7fff6ff672e0
> ~/GC/bdwgc #
>
>
>>
>>>>>
>>>>>>> in any case, i'd welcome advice on how to workaround this issue,
>>>>>>> so that
>>>>>>> i get a working libgc.so in order to use inkscape.
>>>>>> Thanks for reporting the problem, I'll definitely fix the gc
>>>>>> source if we understand how to do it correctly. (Typically, first
>>>>>> I apply the fixes to master branch and, then, cherry-pick to 7.2
>>>>>> release.)
>>>>>
>>>>> thank you. is there anything else i can help with in order to get this
>>>>> fixed ?
>>>> Also, static data roots should be checked (GC_static_roots[], all
>>>> global/static variables should be within one of the regions).
>>>
>>>
>>> how can i check ? List all root ranges.
>> Compile with linker map output, it will show addresses of global
>> variables. These addresses (excluding read-only data) must be inside
>> of a root range.
>
> sorry, i dont know how to do that. please provide a test program and/or
> required command line.
>
> i tried:
> ~/GC/bdwgc # gcc -shared -fPIC -DPIC .libs/allchblk.o .libs/alloc.o
> .libs/blacklst.o .libs/checksums.o .libs/db
> g_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o
> .libs/gcj_mlc.o .libs/headers.o .libs/mach_dep.o .lib
> s/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o
> .libs/new_hblk.o .libs/obj_map.o .libs/os_d
> ep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o
> .libs/reclaim.o .libs/specific.o .libs/stubborn.o
> .libs/thread_local_alloc.o .libs/typd_mlc.o .libs/fnlz_mlc.o -ldl
> -Wl,-soname -Wl,libgc.so.1 -o .libs/libgc
> .so.1.0.3 -Wl,--print-map > link.map
> but the resulting file does not contain any reference to GC_static_roots
>
> link.map: http://sprunge.us/gHCQ
>
> maybe objdump or readelf can do what you want ?
>
> i uploaded the entire ~/GC directory including all object files (and
> .git dir) here for your convenience:
> http://mirror.wzff.de/sabotage/GC.tar.gz (10 MB)
>
>
> in case you want to try yourself (i suggest you do so, since i am not an
> expert with BOEHM GC internals), here is an image file of sabotage linux
> (150 MB only)
>
> http://mirror.wzff.de/sabotage/sabotage-0.9.7-x86_64-898897d9.img.xz
>
> extract using
> xzcat sabotage-0.9.7-x86_64-898897d9.img.xz > sabotage.img
>
> you can directly start it in qemu using
>
> qemu-system-x86_64 sabotage.img
>
> or convert to virtual box hdd format with
> VBoxManage convertfromraw sabotage.img sabotage.vdi
>
> root pass is "sabotage"
>
> the only thing missing in the image is libtool, but this is not required
> if you simply unpack the above GC tarball which has the configure script
> already generated.
> otherwise libtool compiles without any patches from source.
> the other auto* utils, gcc, binutils, gdb, strace, etc are installed.
>
> if you need network connectivity, try "dhclient eth0" or the usual
> ifconfig.
>
> if you want to connect to the vm using SSH use :
> source /src/config
> butch install sshd-keys
> /bin/sshd
>
>
> latest musl precompiled is available here
> http://mirror.wzff.de/sabotage/musl.tar.gz (700KB)
> just unpack into /opt and everything will automatically be up-to-date.
> (the musl installed in the image is one release behind, i am unsure if
> it makes any difference though.)
>
> thanks,
> --JS
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>



More information about the Gc mailing list