[Bug gdb/14261] New: Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture.

[Bug gdb/14261] New: Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture.

[karthikthecool at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14261

             Bug #: 14261
           Summary: Break point not set at the 1st executable instruction
                    in case of code compiled with clang on ARM
                    Architecture.
           Product: gdb
           Version: 7.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: karthikthecool@gmail.com
    Classification: Unclassified


Created attachment 6456
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6456
Assembly files with R(0123) which works fine and Assembly generated by clang
which uses R(4-12) as well.

Dear Developers,
We are using clang(LLVM) compiled binary on ARM and debugging the same using
GDB. When a break point is set at a function, it is set at the 1st line instead
of 1st executable instruction.
E.g.
For e.g. In the below function-

int main()          //line 1
{                   //line 2
                    //line 3
  int j =0;         //line 4
  return j;         //line 5
}                   //line 6


When we compile the above code and run gdb with the following commands-

gdb a.out
break main

The break point is set at line 2 instead of line 4.


Upon Debugging we found that in GDB Arm-tdep.c -

static CORE_ADDR
arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc)


      if ((inst & 0xffffc000) == 0xe5cd0000    /* strb r(0123),[sp,#nn] */
      || (inst & 0xffffc0f0) == 0xe1cd00b0    /* strh r(0123),[sp,#nn] */
      || (inst & 0xffffc000) == 0xe58d0000)    /* str  r(0123),[sp,#nn] */
    continue;

We skip the prologue only in case strb uses registers r0,r1,r2 or r3 in
prologue code. 

clang (LLVM) generates strb instruction with r4,r5...etc not just r(0123) in
prologue code.

In clang case the usage of any other register other than r(0123) in
strb/strh/str instruction is resulting in generation of wrong prologue_end
resulting in break point not being set at 1st executable instruction.When we
modified the strb/strh/str instructions to use r(0123) gdb functionality of
break/list/watch functions correctly.

Attached is the assembly and source code of a function compiled using clang in
which r12/ r4 is used in strb/strh/str/ldr etc instructions used during
parameter assignment 
which results in failure of the above check in arm_skip_prologue resulting in
wrong prologue end info.



We would like to know if we are checking against r(0123) for some specific
purpose or because some specification mandates this usage ?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture.

[will.newton at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14261

Will Newton <will.newton at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |will.newton at gmail dot com

--- Comment #1 from Will Newton <will.newton at gmail dot com> ---

The prologue scanner appears to be checking for stores of varargs arguments in
the function prologue which is why this refers to r0-r3. It is not clear from
looking at the disassembly that you attached that these stores are actually
part of the prologue, they look like they are initializations of stack
variables.

Also your example with main does not correspond to the example in the zip.

Can you confirm that this problem is still valid?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture.

[chrbr at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14261

Christian Bruel <chrbr at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrbr at gcc dot gnu.org

--- Comment #2 from Christian Bruel <chrbr at gcc dot gnu.org> ---
Created attachment 7865
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7865&action=edit
tentative patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture.

[chrbr at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14261

--- Comment #3 from Christian Bruel <chrbr at gcc dot gnu.org> ---
oops, wrong bz# attachment... sorry

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture.

[qiyao at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14261

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gdb                         |tdep

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture.

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14261

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  21daaaaffcbda47b724858dd99ee2082043ef2da (commit)
       via  f303bc3e6ca29f0413376e38164dc5cdc0893d4b (commit)
      from  65840e31a7a7cd64c81ac47bcb17319536ce3ba2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=21daaaaffcbda47b724858dd99ee2082043ef2da

commit 21daaaaffcbda47b724858dd99ee2082043ef2da
Author: Yao Qi <yao@codesourcery.com>
Date:   Thu Nov 27 11:37:54 2014 +0800

    Improve arm_skip_prologue by using arm_analyze_prologue

    Hi,
    I see many fails in dw2-dir-file-name.exp on arm target when test
    case is compiled with -marm, however, these fails are disappeared when
    test case is compiled with -mthumb.

    The difference of pass and fail shown below is that "0x000085d4 in" isn't
    printed out, but test case expects to see it.

    -Breakpoint 2, compdir_missing__ldir_missing__file_basename () at
tmp-dw2-dir-file-name.c:999^M
    -(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp:
compdir_missing__ldir_missing__file_basename: continue to breakpoint:
compdir_missing__ldir_missing__file_basename
    +Breakpoint 2, 0x000085d4 in compdir_missing__ldir_missing__file_basename
() at tmp-dw2-dir-file-name.c:999^M
    +(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp:
compdir_missing__ldir_missing__file_basename: continue to breakpoint:
compdir_missing__ldir_missing__file_basename

    This difference is caused by setting breakpoint at the first instruction
    in the function (actually, the first instruction in prologue, at [1]),
    so that frame_show_address returns false, and print_frame doesn't print the
    address.

       0x00008620 <+0>:     push    {r11}           ; (str r11, [sp, #-4]!) 
<--[1]
       0x00008624 <+4>:     add     r11, sp, #0
       0x00008628 <+8>:     ldr     r3, [pc, #24]   ; 0x8648
<compdir_missing__ldir_missing__file_basename+40>
       0x0000862c <+12>:    ldr     r3, [r3]
       0x00008630 <+16>:    add     r3, r3, #1
       0x00008634 <+20>:    ldr     r2, [pc, #12]   ; 0x8648
<compdir_missing__ldir_missing__file_basename+40>

    Then, it must be the arm_skip_prologue's fault that unable to skip
    instructions in prologue.  At the end of arm_skip_prologue, it matches
    several instructions, such as "str  r(0123),[r11,#-nn]" and
    "str  r(0123),[sp,#nn]", but "push {r11}" isn't handled.

    These instruction matching code in arm_skip_prologue, which can be regarded
    as leftover of development for many years, should be merged to
    arm_analyze_prologue and use arm_analyze_prologue in arm_skip_prologue.
    Here is the something like the history of arm_{skip,scan,analyze}_prologue.
    Around 2002, there are arm_skip_prologue and arm_scan_prologue, but code
are
    duplicated to some extent.  When match an instruction, both functions
should
    be modified, for example in Michael Snyder's patch
    https://sourceware.org/ml/gdb-patches/2002-05/msg00205.html and Michael
    expressed the willingness to merge both into one.  Daniel added code call
    thumb_analyze_prologue in arm_skip_prologue in 2006, but didn't handle its
    counterpart arm_analyze_prologue, which is added in 2010
    <https://sourceware.org/ml/gdb-patches/2010-03/msg00820.html>
    however, the instructions matching at the bottom of arm_skip_prologue
wasn't
    cleaned up.  This patch is to merge them into arm_analyze_prologue.

    gdb:

    2014-12-12  Yao Qi  <yao@codesourcery.com>

        PR tdep/14261
        * arm-tdep.c (arm_skip_prologue): Remove unused local variable
        'skip_pc'.  Remove code skipping prologue instructions, use
        arm_analyze_prologue instead.
        (arm_analyze_prologue): Stop the scanning for unrecognized
        instruction when skipping prologue.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f303bc3e6ca29f0413376e38164dc5cdc0893d4b

commit f303bc3e6ca29f0413376e38164dc5cdc0893d4b
Author: Yao Qi <yao@codesourcery.com>
Date:   Fri Nov 28 15:19:12 2014 +0800

    Don't scan prologue past epilogue

    This patch is to stop prologue analysis past epilogue in for arm mode,
    while we've already had done the same to thumb mode (see
    thumb_instruction_restores_sp).  This is useful to parse functions
    with empty body (epilogue follows prologue).

    gdb:

    2014-12-12  Yao Qi  <yao@codesourcery.com>

        * arm-tdep.c (arm_instruction_restores_sp): New function.
        (arm_analyze_prologue): Call arm_instruction_restores_sp.
        (arm_in_function_epilogue_p): Move code to
        arm_instruction_restores_sp.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog  |   16 +++++++
 gdb/arm-tdep.c |  128 +++++++++++++++++++-------------------------------------
 2 files changed, 59 insertions(+), 85 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture.

[qiyao at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14261

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |7.9

--- Comment #6 from Yao Qi <qiyao at gcc dot gnu.org> ---
Close as it is fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.