[Bug sanitizer/60142] New: [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[Bug sanitizer/60142] New: [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[burnus at gcc dot gnu.org]

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

            Bug ID: 60142
           Summary: [4.9 Regression][asan] -fsanitize=address breaks
                    debugging - stepping into functions no longer possible
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                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 32100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32100&action=edit
Small C++ testcase

Debugging the following code works (on x86-64-linux) with GCC 4.8.3 20131205 -
or with GCC 4.9.0 20140211 and *without* -fsanitize=address.

Using ASAN, one has the following result. Namely, it is not possible to step
into the function "test()".

$ g++ -fsanitize=address -O0 -g test2.cxx
$ gdb ./a.out
...
(gdb) b main
Breakpoint 1 at 0x401131: file test2.cxx, line 15.

(gdb) run
Starting program: /data/local_users/tobiasb/xpcbool/unittests/a.out
Breakpoint 1, main () at test2.cxx:15
15        test();

(gdb) s
0: 1
1: 2
2: 3
[Inferior 1 (process 6022) exited normally]

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-debug
   Target Milestone|---                         |4.9.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jkratoch at gcc dot gnu.org,
                   |                            |tromey at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Works also with -O1 -fsanitize=address -g or -O0 -fsanitize=address -g --param
asan-use-after-return=0.
My guess is that for -O0 gdb has some code to detect function
prologues/epilogues and get's upset by the conditionals in use-after-return
prologue (or epilogue?) instrumentation.  CCing some GDB folks to find out if
it isn't just a GDB bug, or what exactly would they like to see from GCC in
this case, so that they can handle it.

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Works also with [...] or -O0 -fsanitize=address -g
> --param asan-use-after-return=0.

For what it is worth and with that comment rather unsurprisingly, the commit
causing the problem is r205476 (of 2013-11-28), which implements use after
return sanitization.

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat dot com

--- Comment #4 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
Verified GDB fails with it.
GDB puts breakpoint on second ".loc" (that is not the fist/initial ".loc") in a
function as currently neither GCC nor GCC use DW_LNS_set_prologue_end.

g++ (GCC) 4.9.0 20140212 (experimental)
-S -g -fsanitize=address

        .type   _Z4testv, @function
_Z4testv:
.LASANPC512:
.LFB512:
        .file 2 "asantest.C"
        .loc 2 4 0
        .cfi_startproc
        .cfi_personality 0x3,__gxx_personality_v0
        .cfi_lsda 0x3,.LLSDA512
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        pushq   %r14
        pushq   %r13
        pushq   %r12
        pushq   %rbx
        subq    $112, %rsp
        .cfi_offset 14, -24
        .cfi_offset 13, -32
        .cfi_offset 12, -40
        .cfi_offset 3, -48
        leaq    -128(%rbp), %rbx
        movq    %rbx, %r14
        cmpl    $0, __asan_option_detect_stack_use_after_return(%rip)
        je      .L3
        .loc 2 4 0
<--- here GDB puts the breakpoint
        movq    %rbx, %rsi
        movl    $96, %edi
        call    __asan_stack_malloc_1
        movq    %rax, %rbx
.L3:

GDB already workarounds a similar case of GCC PR debug/48827, this asan
prologue may look standard enough it could be possibly also workarounded in
GDB.

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, the second line change in the function heuristics also fails for say:
#include <stdarg.h>

void bar (va_list ap);

void
foo (int a, ...)
{
  va_list ap;
  va_start (ap, a);
  bar (ap);
  va_end (ap);
}

on x86_64, even in that case we emit the second line change on the start of the
second basic block, rather than treating all the prologue and prologue-like
basic blocks as no change in the locus (well, if they are out of line, as in
the case of the varargs x86_64 function that might need saving xmm registers,
or in the -fsanitize=address case, the code conditionally jumps out of line and
then branches back, supposedly we need line directive on the out of line part
of the code).  So, does GDB have a disassemble matcher for the ... prologue, or
does that fail too?

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jan.kratochvil at redhat dot com]

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

--- Comment #6 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
(In reply to Jakub Jelinek from comment #5)
> as in the case of the varargs x86_64 function that might need
> saving xmm registers,
[...]
> So, does GDB have a
> disassemble matcher for the ... prologue, or does that fail too?

For the XMM registers saving block there is prologue matching workaround of
GCC:
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=df15bd07dfd59a5176e0fa7699ab1179205491d9

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drow at gcc dot gnu.org,
                   |                            |rth at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, so it seems the emitting of forced line note at the end of second basic
block comes from:
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01589.html
If it is really just Daniel's paranoia that is the reason for it, perhaps we
can just force the line note change after both prologue notes, like:

--- gcc/final.c.jj    2014-01-03 11:40:35.000000000 +0100
+++ gcc/final.c    2014-02-18 14:50:36.675445581 +0100
@@ -112,9 +112,8 @@ along with GCC; see the file COPYING3.
 #endif

 /* Bitflags used by final_scan_insn.  */
-#define SEEN_BB        1
-#define SEEN_NOTE    2
-#define SEEN_EMITTED    4
+#define SEEN_NOTE    1
+#define SEEN_EMITTED    2

 /* Last insn processed by final_scan_insn.  */
 static rtx debug_insn;
@@ -2128,9 +2127,7 @@ call_from_call_insn (rtx insn)

    SEEN is used to track the end of the prologue, for emitting
    debug information.  We force the emission of a line note after
-   both NOTE_INSN_PROLOGUE_END and NOTE_INSN_FUNCTION_BEG, or
-   at the beginning of the second basic block, whichever comes
-   first.  */
+   both NOTE_INSN_PROLOGUE_END and NOTE_INSN_FUNCTION_BEG.  */

 rtx
 final_scan_insn (rtx insn, FILE *file, int optimize_p ATTRIBUTE_UNUSED,
@@ -2189,14 +2186,6 @@ final_scan_insn (rtx insn, FILE *file, i
       if (targetm.asm_out.unwind_emit)
         targetm.asm_out.unwind_emit (asm_out_file, insn);

-      if ((*seen & (SEEN_EMITTED | SEEN_BB)) == SEEN_BB)
-        {
-          *seen |= SEEN_EMITTED;
-          force_source_line = true;
-        }
-      else
-        *seen |= SEEN_BB;
-
           discriminator = NOTE_BASIC_BLOCK (insn)->discriminator;

       break;

I can bootstrap/regtest this, Jan, could you check this out with GDB testsuite?

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jan.kratochvil at redhat dot com]

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

--- Comment #8 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
Typo above, the real GDB commit of the XMM registers init workaround was:
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=08711b9a36344df9e29be436d9f959324fff4f42


(In reply to Jakub Jelinek from comment #7)
> I can bootstrap/regtest this, Jan, could you check this out with GDB
> testsuite?

Going to check the patch.

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jan.kratochvil at redhat dot com]

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

--- Comment #9 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
Confirming x86_64-linux testsuite on gdb-7.7.50.20140218-cvs has no
changes/regressions.

(Also confirming it fixes for me the Comment 0 gcc4.9 regression.)

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Feb 18 21:16:21 2014
New Revision: 207853

URL: http://gcc.gnu.org/viewcvs?rev=207853&root=gcc&view=rev
Log:
    PR sanitizer/60142
    * final.c (SEEN_BB): Remove.
    (SEEN_NOTE, SEEN_EMITTED): Renumber.
    (final_scan_insn): Don't force_source_line on second
    NOTE_INSN_BASIC_BLOCK.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/final.c

[Bug sanitizer/60142] [4.9 Regression][asan] -fsanitize=address breaks debugging - stepping into functions no longer possible

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Hopefully fixed.