This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/9310] nexti command does not work when debugging ARMassembly language
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 26 Oct 2012 18:38:19 +0000
- Subject: [Bug gdb/9310] nexti command does not work when debugging ARMassembly language
- Auto-submitted: auto-generated
- References: <bug-9310-4717@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=9310
Pedro Alves <palves at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com
--- Comment #2 from Pedro Alves <palves at redhat dot com> 2012-10-26 18:38:19 UTC ---
ARM or Thumb? A fix went in on 2012-08-22, for Thumb 'bx pc' and 'blx pc'.
Otherwise, it may be simpler if you could debug this. Here's how.
Debug the arm gdb with the host's (x86, I presume) gdb. On the (arm/android)
gdb, and put a breakpoint on that particular bl instruction's address, and run
to it (b *0xADDR; c). Then, on the top (x86) gdb, set a breakpoint on
arm_get_next_pc, and let the android gdb continue. Tell the android GDB to
continue the android program as well. arm_get_next_pc will be hit. This is
the function that computes where the execution will land next, so GDB can put a
breakpoint there, so that the android program executes only one instruction (is
single-stepped). The symptom of the bug usually means that for some reason
this computing the next pc goes wrong. It's usually evident whether the
computed address looks reasonable or not.
--
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.