Re: [Valgrind-users] detecting uninitialized values in debug builds
Thanks. Obviously, I should have tried that before posting my question,
although I would not have known how to obtain the answer without seeing your
answer below.
Not being familiar with the x86 asm language, I modified the foo.cpp program
(explicitly assign y=0) and then g++ again, so I could compare the two asm lang
outputs. After that, it was fairly clear that the compiler is not initializing
y.
Ben
-Original Message-
From: John Reiser
Sent: Monday, March 2, 2020 7:20 PM
To: valgrind-users@lists.sourceforge.net
Subject: Re: [Valgrind-users] detecting uninitialized values in debug builds
On 3/2/20 22:02 UTC, Ben White wrote:
> I've also been told that the g++ compiler will initialize all stack
> objects to zero when compiling for debug (the -g option).
Obviously you didn't try it. g++ 9.2.1 does not do that.
$ cat foo.cpp
int g(int x, int y);
int f(int x)
{
int y;
return g(x, y); // uninit use of y
}
$ g++ -g -S foo.cpp
$ cat foo.s
.file "foo.cpp"
.text
.Ltext0:
.globl _Z1fi
.type _Z1fi, @function
_Z1fi:
.LFB0:
.file 1 "foo.cpp"
.loc 1 4 1
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$32, %rsp
movl%edi, -20(%rbp)
.loc 1 6 17
movl-4(%rbp), %edx // -4(%rbp) is never initialized
movl-20(%rbp), %eax
movl%edx, %esi // 2nd parameter to g
movl%eax, %edi
call_Z1gii
.loc 1 7 1
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size _Z1fi, .-_Z1fi
[[snip]]
.section.debug_str,"MS",@progbits,1
.LASF1:
.string "foo.cpp"
.LASF0:
.string "GNU C++14 9.2.1 20190827 (Red Hat 9.2.1-1) -mtune=generic
-march=x86-64 -g"
.LASF3:
.string "_Z1fi"
.LASF2:
.string "/home/user"
.ident "GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
.section.note.GNU-stack,"",@progbits
$
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fvalgrind-usersdata=02%7C01%7Cben.white%40cohu.com%7C4af3d19203134610feef08d7bf220529%7Ceacc2a35149847488d1f03fb953672f8%7C0%7C0%7C637188025165390441sdata=CkROtsN2ADGpGORSPKlYSEqmibqd3VLSA0LfO8U2giU%3Dreserved=0
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] detecting uninitialized values in debug builds
Hello, I have seen cases where valgrind (memcheck) will report conditional jump or move based on uninitialized value, and when examining the relevant source code, I can see that the value or variable is indeed uninitialized. However, I've also been told that the g++ compiler will initialize all stack objects to zero when compiling for debug (the -g option). Yet, valgrind still detects the un-init condition. Does anybody know how this works behind the scenes? This is mainly a curiosity question, no need to research it. Ben White Diagnostics, Calibration, and Verification (DCV) Cohu Inc. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind: Unrecognised instruction
I have never used cachegrind, but I’ve seen a similar message before when using memcheck. In my case, the problem was that I was using the wrong version of memcheck for my CPU type. For example, I think I was trying to run a 32-bit version of memcheck with a 64-bit executable. Ben From: Alexandre Azevedo Sent: Wednesday, February 5, 2020 10:50 AM To: valgrind-users@lists.sourceforge.net Subject: [Valgrind-users] valgrind: Unrecognised instruction Hello guys, I'm currently trying to profile my program's cache behaviour using cachegrind. I can confirm the program seems to be working as I first tested cachegrind compiling my code with GCC. The problem is that I'm now using Intel C compiler and for some reason I keep getting the same error as I try to run it with cachegrind. Following is the error message. vex amd64->IR: unhandled instruction bytes: 0xF3 0xF 0x1E 0xFA 0x41 0x56 0x41 0x89 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=1 ==23029== valgrind: Unrecognised instruction at address 0x4032e0. ==23029==at 0x4032E0: __intel_new_feature_proc_init (in /home/arthur/Documentos/Prog.Paralela/intelseqkron) ==23029==by 0x565282F: (below main) (libc-start.c:291) ==23029== Your program just tried to execute an instruction that Valgrind ==23029== did not recognise. There are two possible reasons for this. ==23029== 1. Your program has a bug and erroneously jumped to a non-code ==23029==location. If you are running Memcheck and you just saw a ==23029==warning about a bad jump, it's probably your program's fault. ==23029== 2. The instruction is legitimate but Valgrind doesn't handle it, ==23029==i.e. it's Valgrind's fault. If you think this is the case or ==23029==you are not sure, please let us know and we'll try to fix it. ==23029== Either way, Valgrind will now raise a SIGILL signal which will ==23029== probably kill your program. ==23029== ==23029== Process terminating with default action of signal 4 (SIGILL) ==23029== Illegal opcode at address 0x4032E0 ==23029==at 0x4032E0: __intel_new_feature_proc_init (in /home/arthur/Documentos/Prog.Paralela/intelseqkron) ==23029==by 0x565282F: (below main) (libc-start.c:291) ==23029== My best regards, Alexandre ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
