public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
* [Bug gdb/14261] New: Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture. @ 2012-06-18 12:12 karthikthecool at gmail dot com 2013-10-30 23:18 ` [Bug gdb/14261] " will.newton at gmail dot com ` (5 more replies) 0 siblings, 6 replies; 7+ messages in thread From: karthikthecool at gmail dot com @ 2012-06-18 12:12 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture. 2012-06-18 12:12 [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 @ 2013-10-30 23:18 ` will.newton at gmail dot com 2014-10-30 14:53 ` chrbr at gcc dot gnu.org ` (4 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: will.newton at gmail dot com @ 2013-10-30 23:18 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture. 2012-06-18 12:12 [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 2013-10-30 23:18 ` [Bug gdb/14261] " will.newton at gmail dot com @ 2014-10-30 14:53 ` chrbr at gcc dot gnu.org 2014-10-30 14:56 ` chrbr at gcc dot gnu.org ` (3 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: chrbr at gcc dot gnu.org @ 2014-10-30 14:53 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug gdb/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture. 2012-06-18 12:12 [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 2013-10-30 23:18 ` [Bug gdb/14261] " will.newton at gmail dot com 2014-10-30 14:53 ` chrbr at gcc dot gnu.org @ 2014-10-30 14:56 ` chrbr at gcc dot gnu.org 2014-12-12 0:42 ` [Bug tdep/14261] " qiyao at gcc dot gnu.org ` (2 subsequent siblings) 5 siblings, 0 replies; 7+ messages in thread From: chrbr at gcc dot gnu.org @ 2014-10-30 14:56 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tdep/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture. 2012-06-18 12:12 [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 ` (2 preceding siblings ...) 2014-10-30 14:56 ` chrbr at gcc dot gnu.org @ 2014-12-12 0:42 ` qiyao at gcc dot gnu.org 2014-12-12 0:52 ` cvs-commit at gcc dot gnu.org 2014-12-12 2:14 ` qiyao at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: qiyao at gcc dot gnu.org @ 2014-12-12 0:42 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tdep/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture. 2012-06-18 12:12 [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 ` (3 preceding siblings ...) 2014-12-12 0:42 ` [Bug tdep/14261] " qiyao at gcc dot gnu.org @ 2014-12-12 0:52 ` cvs-commit at gcc dot gnu.org 2014-12-12 2:14 ` qiyao at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2014-12-12 0:52 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug tdep/14261] Break point not set at the 1st executable instruction in case of code compiled with clang on ARM Architecture. 2012-06-18 12:12 [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 ` (4 preceding siblings ...) 2014-12-12 0:52 ` cvs-commit at gcc dot gnu.org @ 2014-12-12 2:14 ` qiyao at gcc dot gnu.org 5 siblings, 0 replies; 7+ messages in thread From: qiyao at gcc dot gnu.org @ 2014-12-12 2:14 UTC (permalink / raw) To: gdb-prs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-12-12 2:14 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-18 12:12 [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 2013-10-30 23:18 ` [Bug gdb/14261] " will.newton at gmail dot com 2014-10-30 14:53 ` chrbr at gcc dot gnu.org 2014-10-30 14:56 ` chrbr at gcc dot gnu.org 2014-12-12 0:42 ` [Bug tdep/14261] " qiyao at gcc dot gnu.org 2014-12-12 0:52 ` cvs-commit at gcc dot gnu.org 2014-12-12 2:14 ` qiyao at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).