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

Ivan Maidanski ivmai at mail.ru
Sun Jan 6 06:34:14 PST 2013


 Hi John,

Does single-threaded gc pass all tests? If no, it's better to fix the problem in the single-threaded gc first (--enable-threads=none).

Also, please check GC assertion checking on (--enable-gc-assertions).

Воскресенье,  6 января 2013, 13:00 +01:00 от John Spencer <maillist-boehm at barfooze.de>:
>Hi Ivan,
>
>On 01/06/2013 11:30 AM, Ivan Maidanski wrote:
>
>> 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.
>>
>
>thanks, i will try.
>
>>
>> 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
>
>musl deliberately does not define any __musl__ or similar macros.
>read the author's reasoning here:
>http://openwall.com/lists/musl/2012/06/18/8
>
>basically, any hardcoded assumption about which platform has which 
>functionality is broken by design. a function just needs to be added or 
>removed, and your built-in assumption is invalidated.
>testing for the availability of such things is exactly what configure is 
>for.
Agree. It would be good to automate via configure (but later after figuring out where is the problem).

>
>
>> 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?

>
>
>>> 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).
>
>yes, i assumed this will be used as a fallback when pthread_getattr_np 
>fails.
>
>>> 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).

Regards,
Ivan

>
>
>btw, there are ready to boot qemu/vbox images available on 
>http://mirror.wzff.de/sabotage in case you want to try "live" (they come 
>with the full set of development tools).
>
>>
>> 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/ac7e68df/attachment-0001.htm


More information about the Gc mailing list