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

[Ivan Maidanski]

 Hi John,

5 Jan 2013, 22:28 +01:00 John Spencer <maillist-boehm at barfooze.de>:
>i tried to compile the gc on sabotage linux[1] using musl libc[2]
>
>there are multiple issues:
>
>In file included from os_dep.c:44:0:
>/usr/include/asm/sigcontext.h:134:8: error: redefinition of 'struct 
>_fpstate'
>/usr/include/bits/signal.h:6:16: note: originally defined here
>/usr/include/asm/sigcontext.h:157:8: error: redefinition of 'struct 
>sigcontext'
>/usr/include/bits/signal.h:18:8: note: originally defined here
>
>userspace and kernel headers are mixed up. this patch here fixes it:
>
>--- gc-7.2.org/os_dep.c 2013-01-03 17:13:21.878000003 +0000
>+++ gc-7.2/os_dep.c     2013-01-04 07:57:17.766000002 +0000
>@@ -26,6 +26,7 @@
>  #   define __KERNEL__
>  #   include <asm/signal.h>
>  #   undef __KERNEL__
>+# elif 1
>  # else
>      /* Kernels prior to 2.1.1 defined struct sigcontext_struct instead 
>of */
>      /* struct sigcontext.  libc6 (glibc2) uses "struct sigcontext" in 
>     */
Use -DNO_SIGCONTEXT_H instead (I've added this macro recognition to master branch for now).
I don't know whether we still need inclusion of sigcontext.h for any target.

>
>
>
>also to the CFLAG -DNO_GETCONTEXT must be passed by hand to get it to 
>compile.
>
>but the big issue is that os_dep.c unconditionally uses 
>pthread_getattr_np. as the _np suffix suggests, this function is 
>non-posix or in other words non-portable, and is missing in musl.
Unfortunately, pthread_getattr_np and pthread_get_stackaddr_np are the most portable ways to get stack base, other solutions seem to be hacks
(both for GC_get_main_stackbase and GC_get_stack_base).
>
>the build succeeds, but later on one gets link errors as soon as the dso 
>is used.
>
>i tried to work around it by using this macro:
>#define pthread_getattr_np(A, B) (-1)
Use -DNO_PTHREAD_GETATTR_NP instead (I've added it to master branch today).

If you provide me with the target test macros, I'll include definitions of NO_SIGCONTEXT_H, NO_PTHREAD_GETATTR_NP, NO_GETCONTEXT,... to gcconfig.h

>
>
>that makes a valid dso, and a warning is printed that pthread_getattr_np 
>failed.
>
>however when GC_init is called a segfault happens
>in GC_allochblk_nth
which algorithm is used for detection of main stack base in your case? which macro is defined - STACKBOTTOM, HEURISTIC1, LINUX_STACKBOTTOM?

>
>
>preprocessed code: somewhere in the dark depths of this expanded macro 
>GET_HDR the segfault happens.
>
>         for(; 0 != hbp; hbp = hhdr -> hb_next) {
>/* GET_HDR(hbp, hhdr);*/
>             { register hdr ** _ha;
>                 { register bottom_index * bi;
>                   { register word hi =
>                       (word)(hbp) >> (10 + ((size_t)12));
>                          register bottom_index * _bi = 
>GC_arrays._top_index[((hi) & ((1 << 11) - 1))];
>                          while (_bi -> key != hi && _bi != 
>GC_arrays._all_nils)
>                                 _bi = _bi -> hash_link;
>                                 (bi) = _bi;
>                   };
>                   (_ha) = &(((bi)->index[((word)(hbp) >> ((size_t)12)) 
>& ((1 << 10) - 1)]));
>                  }; (hhdr) = *_ha; };
>
>
>i suspect the fallback code when pthread_getattr_np fails is just buggy.
>afaics this code is only there to find the stack address of the main 
>thread. in that case i wonder why not simply /proc/pid/maps is used 
>instead of using non-portable constructs ?
As I've said, /proc/pid/maps is a hack (it will not work for non-Linux targets or in sandboxes like valgrind) but it is ok to use this approach for particular targets (no other way).

GC_linux_main_stack_base reads /proc/self/stat

>
>
>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.)

Regards,
Ivan

>
>
>best regards,
>--JS
>
>[1]  https://github.com/rofl0r/sabotage
>[2]  http://www.musl-libc.org
>
>_______________________________________________
>Gc mailing list
>Gc at linux.hpl.hp.com
>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130106/6f58eac4/attachment.htm