[Gc] Re: Valgrind patch

No Itisnt theseaisinhere at gmail.com
Thu Mar 11 02:17:42 PST 2010


 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.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind5.patch
Type: application/octet-stream
Size: 774 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20100311/579814ff/valgrind5.obj


More information about the Gc mailing list