|
From: Alexander P. <gl...@go...> - 2009-10-01 15:37:15
|
Hi everyone,
It appears that the suppressions generated by Valgrind on Mac OS
contain function names with the gcc mangling scheme (ok for Linux, but
invalid for Mac OS).
For example, for the following code:
-------------------------
#include <stdio.h>
struct Foo {
void bar() {
int *a = new int;
*a = 12345;
delete a;
a = new int;
if (*a == 12345) printf("67890\n");
}
};
int main() {
Foo foo;
foo.bar();
return 0;
}
-------------------------
valgrind --gen-suppressions=all produces the following suppression:
-------------------------
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:_ZN3Foo3barEv
fun:main
}
-------------------------
This suppression really works on Mac OS, but _ZN3Foo3barEv can't be
demangled with c++filt on this platform (it should be
"__ZN3Foo3barEv")
The question is: is it the bug or a feature? Do the suppressions on
every platform rely on the same mangling algorithm?
Thanks,
Alexander Potapenko
Software Engineer
Google Moscow
|
|
From: Alexander P. <gl...@go...> - 2009-10-01 15:44:58
|
Oh, and running the same binary without any suppressions and the
demangling turned off prints the following report:
$ valgrind --demangle=no ./merror
...
==9457== Conditional jump or move depends on uninitialised value(s)
==9457== at 0x1F7B: _ZN3Foo3barEv (in ./merror)
==9457== by 0x1F2A: main (in ./merror)
...
That means that the same internal representation of the function name
is printed, while the real function name is:
$ nm merror | grep _ZN3Foo3barEv
00001f32 T __ZN3Foo3barEv
The only difference is in the leading underscore, but I still find
this a bit confusing.
PS: regarding the "function names with the gcc mangling scheme" in the
previous letter -- this is something platform-specific rather than
gcc-specific. Sorry for being unclear.
On Thu, Oct 1, 2009 at 7:36 PM, Alexander Potapenko <gl...@go...> wrote:
> Hi everyone,
>
> It appears that the suppressions generated by Valgrind on Mac OS
> contain function names with the gcc mangling scheme (ok for Linux, but
> invalid for Mac OS).
> For example, for the following code:
>
> -------------------------
> #include <stdio.h>
>
> struct Foo {
> void bar() {
> int *a = new int;
> *a = 12345;
> delete a;
> a = new int;
> if (*a == 12345) printf("67890\n");
> }
> };
>
> int main() {
> Foo foo;
> foo.bar();
> return 0;
> }
> -------------------------
>
> valgrind --gen-suppressions=all produces the following suppression:
>
> -------------------------
> {
> <insert_a_suppression_name_here>
> Memcheck:Cond
> fun:_ZN3Foo3barEv
> fun:main
> }
> -------------------------
>
> This suppression really works on Mac OS, but _ZN3Foo3barEv can't be
> demangled with c++filt on this platform (it should be
> "__ZN3Foo3barEv")
>
> The question is: is it the bug or a feature? Do the suppressions on
> every platform rely on the same mangling algorithm?
>
> Thanks,
> Alexander Potapenko
> Software Engineer
> Google Moscow
>
--
Alexander Potapenko
Software Engineer
Google Moscow
|
|
From: Nicholas N. <n.n...@gm...> - 2009-10-01 20:58:16
|
On Fri, Oct 2, 2009 at 1:44 AM, Alexander Potapenko <gl...@go...> wrote: > Oh, and running the same binary without any suppressions and the > demangling turned off prints the following report: > > $ valgrind --demangle=no ./merror > ... > ==9457== Conditional jump or move depends on uninitialised value(s) > ==9457== at 0x1F7B: _ZN3Foo3barEv (in ./merror) > ==9457== by 0x1F2A: main (in ./merror) > ... > > That means that the same internal representation of the function name > is printed, while the real function name is: > > $ nm merror | grep _ZN3Foo3barEv > 00001f32 T __ZN3Foo3barEv > > The only difference is in the leading underscore, but I still find > this a bit confusing. For some reason all symbols end up getting an additional leading underscore added to them on Mac. Valgrind avoids printing this so that the symbol matches the one in the original program. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-10-01 21:01:24
|
On Fri, Oct 2, 2009 at 1:36 AM, Alexander Potapenko <gl...@go...> wrote:
>
> It appears that the suppressions generated by Valgrind on Mac OS
> contain function names with the gcc mangling scheme (ok for Linux, but
> invalid for Mac OS).
> For example, for the following code:
>
> -------------------------
> #include <stdio.h>
>
> struct Foo {
> void bar() {
> int *a = new int;
> *a = 12345;
> delete a;
> a = new int;
> if (*a == 12345) printf("67890\n");
> }
> };
>
> int main() {
> Foo foo;
> foo.bar();
> return 0;
> }
> -------------------------
>
> valgrind --gen-suppressions=all produces the following suppression:
>
> -------------------------
> {
> <insert_a_suppression_name_here>
> Memcheck:Cond
> fun:_ZN3Foo3barEv
> fun:main
> }
> -------------------------
>
> This suppression really works on Mac OS, but _ZN3Foo3barEv can't be
> demangled with c++filt on this platform (it should be
> "__ZN3Foo3barEv")
>
> The question is: is it the bug or a feature? Do the suppressions on
> every platform rely on the same mangling algorithm?
Valgrind uses GCC's demangling algorithm. AIUI, this generally works
on Linux and Mac because most programs are compiled with GCC.
I guess it works because Valgrind internally adds the extra
underscore, even though it doesn't print this (see my other response
to you). If you play around with suppressions for C functions that
don't involve mangling, the underscore behaviour should become
clearer.
Nick
|
|
From: Paul P. <ppl...@go...> - 2009-10-02 03:19:31
|
On Thu, Oct 1, 2009 at 8:36 AM, Alexander Potapenko <gl...@go...> wrote: > This suppression really works on Mac OS, but _ZN3Foo3barEv can't be > demangled with c++filt on this platform It sure can: see "man c++filt", the "-n" option: $ c++filt _ZN3Foo3barEv _ZN3Foo3barEv $ c++filt -n _ZN3Foo3barEv Foo::bar() On Thu, Oct 1, 2009 at 1:58 PM, Nicholas Nethercote <n.n...@gm...> wrote: > For some reason all symbols end up getting an additional leading > underscore added to them on Mac. That's standard for COFF and most other pre-ELF object file formats; IIRC this was done to distinguish C symbols from Assembly ones in the very early days, when C was the newcomer. -- Paul Pluzhnikov |