[Bug sanitizer/61071] New: 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.

[Bug sanitizer/61071] New: 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.

[athantor+gccbugzilla at athi dot pl]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4919 bytes --]

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

            Bug ID: 61071
           Summary: 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.
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: athantor+gccbugzilla at athi dot pl
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Created attachment 32739
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32739&action=edit
testcase

Description:
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 version of Arch.
It was working OK with gcc <4.9.

Additional info:
Linux kk 3.14.2-1-ARCH #1 SMP PREEMPT Sun Apr 27 11:28:44 CEST 2014 x86_64
GNU/Linux
gcc 4.9.0
gdb 7.7
glibc 2.19
binutils 2.24


Steps to reproduce:
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 main' --ex 'r' --ex 'p d' --ex 'q' ./test

If you'll compile with ASAN, gdb will show that variable 'd' is optimized out
despite '-O0' in gcc switches:
Breakpoint 1, main () at test.c:10
10 int d = 4;
$1 = <optimized out>


remove '-fsanitize=address' from switches and gdb works as it should (ignore
uninitialized value):
Breakpoint 1, main () at test.c:10
10 int d = 4;
$1 = 134513883


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.

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>
>From gcc-bugs-return-450627-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 06 06:11:58 2014
Return-Path: <gcc-bugs-return-450627-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7114 invoked by alias); 6 May 2014 06:11:57 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7076 invoked by uid 48); 6 May 2014 06:11:53 -0000
From: "wence at gmx dot li" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61068] -O3 generates bad code (when tree-vectorize or inline-functions is on)
Date: Tue, 06 May 2014 06:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wence at gmx dot li
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created
Message-ID: <bug-61068-4-Kl5o3Y6PaJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61068-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61068-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg00319.txt.bz2
Content-length: 553

http://gcc.gnu.org/bugzilla/show_bug.cgi?ida068

Lawrence Mitchell <wence at gmx dot li> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #32738|0                           |1
        is obsolete|                            |

--- Comment #4 from Lawrence Mitchell <wence at gmx dot li> ---
Created attachment 32740
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2740&actioníit
updated preprocessed source (no double[][] -> (double *))

[Bug sanitizer/61071] Compiling with AddressSanitizer with 4.9 breaks printng some variables in gdb

[athantor+gccbugzilla at athi dot pl]

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

--- Comment #1 from Krzysztof Kundzicz <athantor+gccbugzilla at athi dot pl> ---
Same with gcc 4.9.1 + gdb 7.7.1

[Bug sanitizer/61071] Compiling with AddressSanitizer with 4.9 breaks printng some variables in gdb

[athantor+gccbugzilla at athi dot pl]

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

--- Comment #2 from Krzysztof Kundzicz <athantor+gccbugzilla at athi dot pl> ---
GCC 5.1 - no change.
Compiling with clang generates debugable binary.

Bug report at ASAN project:
https://code.google.com/p/address-sanitizer/issues/detail?id=390

[Bug sanitizer/61071] Compiling with AddressSanitizer with 4.9 breaks printng some variables in gdb

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-22
                 CC|                            |aoliva at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--param asan-use-after-return=0 makes this work, without that in order to
support use after return the variables don't live in stack frame
(unconditionally), so are based on some pointer (which is assigned either a
stack slot address or return value from libasan function), and as -O0 -g
doesn't perform var-tracking, it then really depends on register allocation, if
the pseudo register holding that pointer is assigned some hard register through
the whole function (that is the case with t[36] apparently), or not.
For -O0 to have this working reliably, supposedly we'd have to store that
pointer into the stack and turning it into an artificial var, then add
DECL_VALUE_EXPR for all the other stack vars if they are based on this pointer
(Alex, any other thoughts?).
For -O1+/-Og/-Os, I'm surprised var-tracking doesn't handle this.