Re: [Gc] Re: Valgrind patch

Ivan Maidanski ivmai at mail.ru
Mon Mar 8 23:05:26 PST 2010


Mon, 08 Mar 2010 22:06:26 +0100 письмо от ludo at gnu.org  (Ludovic CourtХs):

> Hi,
>
> No Itisnt <theseaisinhere at gmail.com>
> writes:
>
> > It does this by using pthread
> > attributes to get the stack base when the environment variable
> > 'GC_VALGRIND' is set. A more elegant method would be to check
> > /proc/self/maps for valgrind,

The patch suggests using for GC_linux_stack_base() the same code as in GC_get_stack_base(),
so the simpler fix would be just define GC_get_main_stack_base() to use GC_get_stack_base() for valgreed case.

And, my question is: why are we not using pthread_attr_getstack() for GC_get_main_stack_base() on Linux at present?

>
> Actually Valgrind has an API for this:
>
>   http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq
>
> It boils down to:
>
>   #include <valgrind/valgrind.h>
>
>     if (RUNNING_ON_VALGRIND)
>       ...
>
> The presence of <valgrind/valgrind.h> can be checked for at
> configuration time.  The manual reads this:
>
>   The code added to your binary has negligible performance impact: on
>   x86, amd64, ppc32 and ppc64, the overhead is 6 simple integer
>   instructions and is probably undetectable except in tight loops.
>   However, if you really wish to compile out the client requests, you
>   can compile with -DNVALGRIND (analogous to -DNDEBUG's effect on
>   assert).

I don't like using GETENV("GC_VALGRIND") neither.

>
> Thanks,
> Ludo'.

Bye.


More information about the Gc mailing list