Re: [Gc] Re: Valgrind patch
ivmai at mail.ru
Fri Mar 12 05:29:02 PST 2010
Thu, 11 Mar 2010 04:17:42 -0600 письмо от No Itisnt <theseaisinhere at gmail.com>:
> I think I understand now. GC_get_stack_base is likely not used
> because it can provide an undesirably large value in non-threaded
> builds, as per the comment at about os_dep.c:1300.
> The attached patch will prefer pthread_attr_getstack on linux when
> available, via GC_get_stack_base. It will fallback to the other
> methods if pthread_getattr_np fails.
Ok. I've committed the patch (see attachment)) which should solve your problem. Use -D USE_GET_STACKBASE_FOR_MAIN (without it the behavior is unchanged). Does it work for you?
what do you think about using pthread_attr_getstack() in GC_get_main_stack_base() by default for Linux with threads?
> > I find the phrase Linux threads confusing since that s the name of the
> > former thread library used on GNU/Linux. It s not what you meant, is
> > it?
> No, sorry, I just meant builds on Linux with threads enabled.
> > Again, I don t think the kernel matters much here. The use of
> > __libc_stack_end should be in #ifdef __GLIBC__ so that it will just
> > work on all GNU variants (currently GNU/Linux, GNU/Hurd, and
> > GNU/kFreeBSD).
> > Also, /proc is the third method in this list, so it may be that it will
> > never be used in that list. If that is the case, code that handles it
> > could be dropped altogether.
> The third case would be used when building on non-glibc linux systems.
> According to the comments, __libc_stack_end is improperly set under
> some conditions, so it is required even with glibc.
> ATTACHMENT: application/x-patch (valgrind5.patch)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1183 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20100312/0fd35c2b/bdwgc-ivmai-237.obj
More information about the Gc