ramosian-glider / address-sanitizer

Automatically exported from code.google.com/p/address-sanitizer
0 stars 0 forks source link

Compiling with AddressSanitizer using gcc ≥4.9 breaks printng some variables in gdb on Linux #390

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
With certain configurations of variables on function's stack, when debugging 
32bit binary compiled with '-fsanitize=address', some variables in gdb are 
printed out as '<optimized out>' despite passing '-O0 -ggdb3' in compilation
switches.

Problem occurres (for me) only when debugging 32bit binary; same code in 64bit 
works OK. It doesn't matter if I'm cross compiling it 64b→32b nor if I 
compile it natively on i386. It was working OK with gcc <4.9.
I've checked it on different computers with different distros, and the result 
is the same since gcc 4.9.

What steps will reproduce the problem?
1. Compile attached source file with:
gcc -m32 -Wall -Wextra -Wno-unused-variable -fsanitize=address -ggdb3 -O0 -o 
test test.c

2. gdb it with:
gdb --ex 'b 11' --ex 'r' --ex 'p d' --ex 'q' ./test

What is the expected output? What do you see instead?
If you'll compile it with ASAN, gdb will show that variable 'd' is optimized 
out despite '-O0' in gcc switches:
Breakpoint 1, main () at test.c:11
11              char t[37] = "";
$1 = <optimized out>

remove '-fsanitize=address' from switches and gdb works as it should:
Breakpoint 1, main () at test.c:11
11              char t[37] = "";
$1 = 4

What's funny, if I'll remove zeroing of the 't' array or decrease its size to 
36B, then gdb starts to print 'd' OK. 
Using clang for compilation also produces debugable binary.

In both cases debug info about the 'd' variable seems to be present in the 
binary:
<2><be>: Abbrev Number: 8 (DW_TAG_variable)
<bf> DW_AT_name : d
<c1> DW_AT_decl_file : 1
<c2> DW_AT_decl_line : 11
<c3> DW_AT_type : <0x53>

What version of the product are you using? On what operating system?
Arch Linux.
Linux kk 4.0.4-1-ARCH #1 SMP PREEMPT Mon May 18 06:43:19 CEST 2015 x86_64 
GNU/Linux
gcc version 5.1.0 (GCC)
GNU gdb (GDB) 7.9.1
GNU C Library (GNU libc) stable release version 2.21
GNU ld (GNU Binutils 2.25.0)

Please provide any additional information below.
Downstream bug reports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61071
https://bugs.archlinux.org/task/40223

Original issue reported on code.google.com by athan...@athi.pl on 22 May 2015 at 5:45

Attachments:

GoogleCodeExporter commented 9 years ago
Note that GCC sometimes optimizes variables in frontend regardless of 
optimization level.

Original comment by tetra20...@gmail.com on 22 May 2015 at 6:35

GoogleCodeExporter commented 9 years ago
But why '-fsanitize=address' changes optimizations?

It's possible that it's something with gcc internals, but ever since I'm 
working on pretty big C89 project compiled on gcc-s 2.95.3-5.1 I've *never* 
encountered '<optimized out>' without '-O' switch, especially with a '-g' one…

That variable should not be optimized out since it's passed around and written 
into. Any combination of '-O' and  '-g' switches  doesn't stop it from 
„disappearing”, also making the variable volatile (!). Only disabling ASAN.

Original comment by athan...@athi.pl on 22 May 2015 at 7:07

GoogleCodeExporter commented 9 years ago
Ah, sorry, I thought you meant t. I've check compiler dumps with 
-fdump-tree-all and it looks like d is preserved by ASan:

 $ cat test.c.169t.optimized
 ...
 ;; Function main (main, funcdef_no=3, decl_uid=2584, symbol_order=3)

 main ()
 {
   <bb 2>:
   d = 4;
   t = "";
   fun_wr (&d);

Perhaps GCC has some problem when generating debuginfo? Could you file a bug in 
GCC bugzilla?

Original comment by tetra20...@gmail.com on 22 May 2015 at 7:49

GoogleCodeExporter commented 9 years ago
Already did. Year ago :-(

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61071

I don't think it's a problem with debuginfo, since decreasing size of t by one 
makes printing the d variable work again.

Original comment by athan...@athi.pl on 22 May 2015 at 8:01

GoogleCodeExporter commented 9 years ago
Does this work with fresh clang? 
I afraid that this is gcc-specific and there is little we can do on asan side. 

Original comment by konstant...@gmail.com on 22 May 2015 at 5:44

GoogleCodeExporter commented 9 years ago
> Does this work with fresh clang? 
Yeah, clang produces debugable binary.
clang version 3.6.0 (tags/RELEASE_360/final)

> I afraid that this is gcc-specific and there is little we can do on asan 
side. 
I understand. Thanks for your time, though.

Original comment by athan...@athi.pl on 25 May 2015 at 5:18

GoogleCodeExporter commented 9 years ago
Adding Project:AddressSanitizer as part of GitHub migration.

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:06