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-users&data=02%7C01%7Cben.white%40cohu.com%7C4af3d19203134610feef08d7bf220529%7Ceacc2a35149847488d1f03fb953672f8%7C0%7C0%7C637188025165390441&sdata=CkROtsN2ADGpGORSPKlYSEqmibqd3VLSA0LfO8U2giU%3D&reserved=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