Nick Clifton [Wed, 29 Jan 2014 13:46:39 +0000 (13:46 +0000)]
Following up on Tom's suggestion I am checking in a patch to replace the various
bfd_xxx_set macros with static inline functions, so that we can avoid compile time
warnings about comma expressions with unused values.
Eli Zaretskii [Sat, 19 Apr 2014 08:12:19 +0000 (11:12 +0300)]
PR gdb/14018 -- avoid "PC register not available" errors.
gdb/windows-nat.c (thread_rec): Don't display a warning when
SuspendThread fails with ERROR_ACCESS_DENIED. If SuspendThread
fails for any reason, set th->suspended to -1, so that we don't
try to resume such a thread. Also, don't return NULL in these
cases, to avoid completely ruin the session due to "PC register is
not available" error.
(do_windows_fetch_inferior_registers): Check errors in
GetThreadContext call.
(windows_continue): Accept an additional argument KILLED; if not
zero, ignore errors in the SetThreadContext call, since the
inferior was killed and is shutting down.
(windows_resume, get_windows_debug_event)
(windows_create_inferior, windows_mourn_inferior)
(windows_kill_inferior): All callers of windows_continue changed
to adjust to its new calling sequence.
Pierre Langlois [Fri, 21 Mar 2014 19:46:07 +0000 (19:46 +0000)]
Erroneous backtrace on AVR.
PR backtrace/16721
PR backtrace/16832
* avr-tdep.c (struct gdbarch_tdep): Mention avrxmega in the comment.
(avr_gdbarch_init): Add xmega architectures given by bfd_architecture
when setting the size of call_length.
(avr_scan_prologue): Accept push r1 instruction for small stack
allocation.
* MAINTAINERS (Write After Approval): Add "Pierre Langlois".
Pedro Alves [Wed, 12 Mar 2014 10:28:59 +0000 (10:28 +0000)]
AIX 32-bit core loading, high section addresses.
I noticed GDB was failing to enable threading support for 32-bit AIX
cores. I traced it to failure to read variables from libpthreads.a.
The issue is that data for that library is loaded at a high address,
and bfd is sign extending the section addresses:
(gdb) info files
Symbols from "/home/palves/crash".
Local core dump file:
`/home/palves/core', file type aixcoff-rs6000.
0x2ff22000 - 0x2ff23000 is .stack
0x20000000 - 0x200316e0 is .data
0x20000e90 - 0x200016c0 is .data
0xfffffffff0254000 - 0xfffffffff0297920 is .data
0xfffffffff07b46a8 - 0xfffffffff07b47c8 is .data
0xfffffffff0298000 - 0xfffffffff029bfcc is .data
0xfffffffff06dafe0 - 0xfffffffff07b3838 is .data
Local exec file:
`/home/palves/crash', file type aixcoff-rs6000.
Entry point: 0x20001394
0x10000150 - 0x10000e90 is .text
0x20000e90 - 0x2000149c is .data
0x2000149c - 0x200016c0 is .bss
0xd053b124 - 0xd053e15f is .text in /usr/lib/libpthreads.a(shr_comm.o)
0xf0254000 - 0xf0297920 is .data in /usr/lib/libpthreads.a(shr_comm.o)
0xf0254450 - 0xf0297920 is .bss in /usr/lib/libpthreads.a(shr_comm.o)
0xd053a280 - 0xd053aabe is .text in /usr/lib/libcrypt.a(shr.o)
0xf07b46a8 - 0xf07b47c8 is .data in /usr/lib/libcrypt.a(shr.o)
0xf07b47c8 - 0xf07b47c8 is .bss in /usr/lib/libcrypt.a(shr.o)
0xd04fb180 - 0xd053917e is .text in /usr/lib/libpthreads.a(shr_xpg5.o)
0xf0298000 - 0xf029bfcc is .data in /usr/lib/libpthreads.a(shr_xpg5.o)
0xf029bf64 - 0xf029bfcc is .bss in /usr/lib/libpthreads.a(shr_xpg5.o)
0xd0100900 - 0xd04fa39c is .text in /usr/lib/libc.a(shr.o)
0xf06dafe0 - 0xf07b3838 is .data in /usr/lib/libc.a(shr.o)
0xf0751e94 - 0xf07b3838 is .bss in /usr/lib/libc.a(shr.o)
Notice:
...
0xfffffffff0298000 - 0xfffffffff029bfcc is .data
...
Those are the bfd section start/end addresses. It't not visible here:
...
0xf0298000 - 0xf029bfcc is .data in /usr/lib/libpthreads.a(shr_xpg5.o)
...
... just because GDB trims that number to 32-bit when printing.
GDB then fails to find the memory for libpthreads.a variables in the
core, and falls back to reading it directly from the executable (which
yields the values as originally initialized in the code).
E.g.:
(gdb) p &__n_pthreads
$2 = (<data variable, no debug info> *) 0xf074fda8 <__n_pthreads>
(gdb) p __n_pthreads
$1 = -1
That should have returned 2 instead of -1.
bfd/
2014-03-12 Pedro Alves <palves@redhat.com>
PR gdb/16696
* rs6000-core.c (rs6000coff_core_p): Cast pointers to bfd_vma
through ptr_to_uint instead of through long.
Pedro Alves [Wed, 5 Mar 2014 14:18:28 +0000 (14:18 +0000)]
PR gdb/16575: stale breakpoint instructions in the code cache
In non-stop mode, or rather, breakpoints always-inserted mode, the
code cache can easily end up with stale breakpoint instructions:
All it takes is filling a cache line when breakpoints already exist in
that memory region, and then delete the breakpoint.
Vis. (from the new test):
(gdb) set breakpoint always-inserted on
(gdb) b 23
Breakpoint 2 at 0x400540: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 23.
(gdb) b 24
Breakpoint 3 at 0x400547: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 24.
disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
So far so good. Now flush the code cache:
(gdb) set code-cache off
(gdb) set code-cache on
Requesting a disassembly works as expected, breakpoint shadowing is
applied:
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
However, now delete the breakpoints:
(gdb) delete
Delete all breakpoints? (y or n) y
And disassembly shows the old breakpoint instructions:
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: int3
0x0000000000400541 <+5>: rex.RB cld
0x0000000000400543 <+7>: add %eax,(%rax)
0x0000000000400545 <+9>: add %al,(%rax)
0x0000000000400547 <+11>: int3
0x0000000000400548 <+12>: rex.RB cld
0x000000000040054a <+14>: add (%rax),%al
0x000000000040054c <+16>: add %al,(%rax)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
Those breakpoint instructions are no longer installed in target memory
they're stale in the code cache. Easily confirmed by just disabling
the code cache:
(gdb) set code-cache off
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
I stumbled upon this when writing a patch to infrun.c, that made
handle_inferior_event & co fill in the cache before breakpoints were
removed from the target. Recall that wait_for_inferior flushes the
dcache for every event. So in that case, always-inserted mode was not
necessary to trigger this. It's just a convenient way to expose the
issue.
The dcache works at the raw memory level. We need to update it
whenever memory is written, no matter what kind of target memory
object was originally passed down by the caller. The issue is that
the dcache update code isn't reached when a caller explicitly writes
raw memory. Breakpoint insertion/removal is one such case --
mem-break.c uses target_write_read_memory/target_write_raw_memory.
The fix is to move the dcache update code from memory_xfer_partial_1
to raw_memory_xfer_partial so that it's always reachable.
When we do that, we can actually simplify a series of things.
memory_xfer_partial_1 no longer needs to handle writes for any kind of
memory object, and therefore dcache_xfer_memory no longer needs to
handle writes either. So the latter (dcache_xfer_memory) and its
callees can be simplified to only care about reads. While we're
touching dcache_xfer_memory's prototype, might as well rename it to
reflect that fact that it only handles reads.
Currently dcache_xfer_memory handles the case of a write failing. The
whole cache line is invalidated when that happens. However,
dcache_update, the sole mechanism for handling writes that will remain
after the patch, does not presently handle that scenario. That's a
bug. The patch makes it handle that, by passing down the
to_xfer_partial result from the caller, so that it can better decide
what to do itself. While I was changing the function's prototype, I
constified the myaddr parameter, getting rid of the need for the cast
as seen in its existing caller.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2014-03-05 Pedro Alves <palves@redhat.com>
PR gdb/16575
* dcache.c (dcache_poke_byte): Constify ptr parameter. Return
void. Update comment.
(dcache_xfer_memory): Delete.
(dcache_read_memory_partial): New, based on the read bits of
dcache_xfer_memory.
(dcache_update): Add status parameter. Use ULONGEST for len, and
adjust. Discard cache lines if the reason for the update was
error.
* dcache.h (dcache_xfer_memory): Delete declaration.
(dcache_read_memory_partial): New declaration.
(dcache_update): Update prototype.
* target.c (raw_memory_xfer_partial): Update the dcache here.
(memory_xfer_partial_1): Don't handle dcache writes here.
gdb/testsuite/
2014-03-05 Pedro Alves <palves@redhat.com>
PR gdb/16575
* gdb.base/breakpoint-shadow.exp (compare_disassembly): New
procedure.
(top level): Adjust to use it. Add tests that exercise breakpoint
interaction with the code-cache.
projects / thirdparty / binutils-gdb.git / log
