It would be useful for you to say what exactly is broken, and on
which platform. At least it seems to have been working for some
people (at IBM).
Sorry the explanation was a bit terse. The testcase assumes it only
requires two "next"s to get through the test function:
set bp1 [gdb_get_line_number "lwarx"]
gdb_breakpoint "$bp1" "Breakpoint $decimal at $hex" \
"Set the breakpoint at the start of the sequence"
gdb_test continue "Continuing.*Breakpoint $decimal.*" \
"Continue until breakpoint"
gdb_test next ".*__asm __volatile.*" \
"Step through the lwarx/stwcx sequence"
gdb_test next ".*return 0.*" \
"Step through the ldarx/stdcx sequence"
If I run this testcase manually on Fedora 16 (gcc 4.6.2), it
actually takes 7 steps to get through it:
Breakpoint 2, main () at ./gdb.arch/ppc64-atomic-inst.c:27
27 __asm __volatile ("1: lwarx %0,0,%2\n" \
(gdb) next
32 : "b" (word_addr), "m" (*word_addr) \
(gdb) next
27 __asm __volatile ("1: lwarx %0,0,%2\n" \
(gdb) next
39 : "=&b" (dword), "=m" (*dword_addr) \
(gdb) next
35 __asm __volatile ("1: ldarx %0,0,%2\n" \
(gdb) next
40 : "b" (dword_addr), "m" (*dword_addr) \
(gdb) next
35 __asm __volatile ("1: ldarx %0,0,%2\n" \
(gdb) next
43 return 0;
(gdb)
I'm not sure what is expected here, is "next" supposed to step all the
way through inline assembly? Perhaps it is, but it seems fragile to
depend on this high level behaviour.