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.
Pedro Alves [Wed, 26 Feb 2014 16:52:24 +0000 (16:52 +0000)]
Make sure we don't resume the stepped thread by accident.
Say:
<stopped at a breakpoint in thread 2>
(gdb) thread 3
(gdb) step
The above triggers the prepare_to_proceed/deferred_step_ptid process,
which switches back to thread 2, to step over its breakpoint before
getting back to thread 3 and "step" it.
If while stepping over the breakpoint in thread 2, a signal arrives,
and it is set to pass/nostop, we'll set a step-resume breakpoint at
the supposed signal-handler resume address, and call keep_going. The
problem is that we were supposedly stepping thread 3, and that
keep_going delivers a signal to thread 2, and due to scheduler-locking
off, resumes everything else, _including_ thread 3, the thread we want
stepping. This means that we lose control of thread 3 until the next
event, when we stop everything. The end result for the user, is that
GDB lost control of the "step".
Here's the current infrun debug output of the above, with the testcase
in the patch below:
Program received signal SIGUSR1, User defined signal 1.
infrun: signal arrived while stepping over breakpoint
infrun: inserting step-resume breakpoint at 0x40098f
infrun: resume (step=0, signal=30), trap_expected=0, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
infrun: stop_pc = 0x40088b
infrun: switching back to stepped thread
infrun: Switching context from Thread 0x2aaaab6f4700 (LWP 11662) to Thread 0x2aaaab8f5700 (LWP 11663)
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x400938
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40093a
infrun: keep going
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x40093a
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40091e
infrun: stepped to a different line
infrun: stop_stepping
[Switching to Thread 0x2aaaab8f5700 (LWP 11663)]
69 (*myp) ++; /* set breakpoint child_two here */
^^^ we stopped at the wrong line. We still stepped a bit because the
test is running in a loop, and when we got back to stepping thread 3,
it happened to be in the stepping range. (The loop increments a
counter, and the test makes sure it increments exactly once. Without
the fix, the counter increments a bunch, since the user-stepped thread
runs free without GDB noticing.)
The fix is to switch to the stepping thread before continuing for the
step-resume breakpoint.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
PR breakpoints/16292
* infrun.c (handle_signal_stop) <signal arrives while stepping
over a breakpoint>: Switch back to the stepping thread.
gdb/testsuite/
2014-02-26 Pedro Alves <pedro@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR breakpoints/16292
* gdb.threads/signal-while-stepping-over-bp-other-thread.c: New
file.
* gdb.threads/signal-while-stepping-over-bp-other-threadexp: New
file.
Fedora 20 x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so.0.3800.2...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3800.2.debug...done.
done.
(gdb) _
Fedora Rawhide x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3990.0.debug...done.
done.
warning: File "/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py" auto-loading has been declined by your `auto-load safe-path'
set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
add-auto-load-safe-path /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
line to your configuration file "/home/jkratoch/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/jkratoch/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) _
That is it tries to load "forbidden"
/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
but it should load instead
/usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py*
Although that is also not exactly this way, there does not exist any
/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
despite regressed GDB says so.
gdb/
2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* auto-load.c (auto_load_objfile_script_1): Change filename to
debugfile.
gdb/testsuite/
2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* gdb.base/auto-load-script: New file.
* gdb.base/auto-load.c: New file.
* gdb.base/auto-load.exp: New file.
Yao Qi [Thu, 30 Jan 2014 02:09:11 +0000 (10:09 +0800)]
Create inferior for ctf target.
This patch creates inferior when GDB opens a ctf trace data, to be
consistent with tfile target. A test case is added to test for
live target, tfile and ctf target.
gdb:
2014-02-05 Yao Qi <yao@codesourcery.com>
* ctf.c: Include "inferior.h" and "gdbthread.h".
(CTF_PID): A new macro.
(ctf_open): Call inferior_appeared and add_thread_silent.
(ctf_close): Call exit_inferior_silent and set inferior_ptid.
(ctf_thread_alive): New function.
(init_ctf_ops): Install ctf_thread_alive to to_thread_alive.
gdb/testsuite:
2014-02-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/report.exp (use_collected_data): Test the output
of "info threads" and "info inferiors".
Yao Qi [Thu, 30 Jan 2014 00:37:05 +0000 (08:37 +0800)]
Create inferior for tfile target
When a trace file is loaded in Eclipse, it is expected to see thread
and process (=thread-group-started and =thread-created). Create an
inferior and add a thread for this purpose.
This patch just reverts my previous patch.
gdb/testsuite:
2014-02-05 Yao Qi <yao@codesourcery.com>
Revert this patch:
2013-05-24 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.exp: Test inferior and thread.
gdb:
2014-02-05 Yao Qi <yao@codesourcery.com>
Revert this patch:
2013-05-24 Yao Qi <yao@codesourcery.com>
* tracepoint.c (TFILE_PID): Remove.
(tfile_open): Don't add thread and inferior.
(tfile_close): Don't set 'inferior_ptid'. Don't call
exit_inferior_silent.
(tfile_thread_alive): Remove.
(init_tfile_ops): Don't set field 'to_thread_alive' of
tfile_ops.
Ulrich Weigand [Tue, 28 Jan 2014 16:49:13 +0000 (17:49 +0100)]
Fix typo in ppc64_standard_linkage7
The ppc64_standard_linkage7 pattern added by Alan's recent patch:
https://sourceware.org/ml/gdb-patches/2013-11/msg00274.html
contains a typo: the ELFv2 TOC slot offset is 24, not 40.
This was correct in the comment, but not the actual code.
Tom Tromey [Wed, 22 Jan 2014 15:52:15 +0000 (08:52 -0700)]
avoid python exception in FrameDecorator.py
This fixes a bug in FrameDecorator.py.
FrameVars seems to assume that Frame.block can return None if there is
no block. However, it actually throws an exception.
I saw this bug while developing a frame filter, but unfortunately I
don't know how to reproduce it. It seems to me that the SAL tests in
_is_limited_frame should exclude the bad cases; and in my attempts to
write a test they do.
Nevertheless I think the fix is reasonably obvious and ought to go in.
Tom Tromey [Wed, 22 Jan 2014 15:44:41 +0000 (08:44 -0700)]
fix erroneous error-handling in frame filter code
This fixes PR python/16487.
The bug here is that the function-name-handling code in py_print_frame
had a small logic error (really a misplaced closing brace). This
error could lead to a Py_DECREF(NULL), which crashes.
This patch fixes the bug in the obvious way.
Built and regtested on x86-64 Fedora 18. New test case included.
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16487:
* python/py-framefilter.c (py_print_frame): Don't call Py_DECREF
on a NULL pointer. Move "goto error" to correct place.
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16487:
* gdb.python/py-framefilter.exp: Add test using "Error" filter.
* gdb.python/py-framefilter.py (ErrorInName, ErrorFilter): New
classes.
Tom Tromey [Wed, 22 Jan 2014 15:10:01 +0000 (08:10 -0700)]
fix crash in frame filters
apply_frame_filter calls ensure_python_env before computing the
gdbarch to use. This means that python_gdbarch can be NULL while in
Python code, and if a frame filter depends on this somehow (easy to
do), gdb will crash.
The fix is to compute the gdbarch first.
Built and regtested on x86-64 Fedora 18.
New test case included.
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16491:
* python/py-framefilter.c (apply_frame_filter): Call
ensure_python_env after computing gdbarch.
2014-01-23 Tom Tromey <tromey@redhat.com>
PR python/16491:
* gdb.python/py-framefilter.py (Reverse_Function.function): Read a
string from an inferior frame.
* gdb.python/py-framefilter-mi.exp: Update.
Baruch Siach [Wed, 22 Jan 2014 12:18:29 +0000 (12:18 +0000)]
gdb: xtensa: fix linux ptrace includes
Currently, xtensa code using the Linux ptrace interface only include
sys/ptrace.h. This file comes from the C library (glibc and uClibc,
at least), and includes a declaration of the ptrace() functions, along
with some cross architecture constants that are mostly copied from the
file located at include/uapi/linux/ptrace.h in recent Linux kernels.
For xtensa specific constants like PTRACE_GETXTREGS and
PTRACE_SETXTREGS the asm/ptrace.h include from the Linux kernel UAPI
is needed. The code in gdbserver xtensa specific part doesn't call
ptrace() directly, so we can remove the unneeded sys/ptrace.h include.
The gdb xtensa specific code needs both headers, since it calls
ptrace().
gdb/
* xtensa-linux-nat.c: Include asm/ptrace.h.
gdb/gdbserver/
* linux-xtensa-low.c: Include asm/ptrace.h instead of
sys/ptrace.h.
Roland McGrath [Tue, 21 Jan 2014 19:01:04 +0000 (11:01 -0800)]
gdb: Support install-strip target
gdb/
* configure.ac: Call AM_PROG_INSTALL_STRIP.
* configure: Regenerate.
* aclocal.m4: Regenerate.
* Makefile.in (install_sh, INSTALL_STRIP_PROGRAM, STRIP):
New substituted variables.
(install-strip): New target.
(INSTALL_SCRIPT): New substituted variable.
(FLAGS_TO_PASS): Add it.
(install-only): Use $(INSTALL_SCRIPT) rather than
$(INSTALL_PROGRAM) for gcore.
Pedro Alves [Wed, 15 Jan 2014 12:53:04 +0000 (12:53 +0000)]
Fix go32-nat.c build fallout from to_detach constification.
The recent constification of to_detach missed updating the forward
declaration of go32_detach, breaking the build:
../../src/gdb/go32-nat.c:387:1: error: conflicting types for 'go32_detach'
../../src/gdb/go32-nat.c:240:13: note: previous declaration of 'go32_detach' was here
go32_detach is actually defined before it's ever used, making the
forward declaration is unnecessary. So we can just remove it instead
of updating it. While at it, remove all others in the same situation.
Tested by building a djgpp gdb.
Siva Chandra [Fri, 27 Dec 2013 20:20:59 +0000 (12:20 -0800)]
Use bitpos and type to lookup a gdb.Field object when its name is 'None'.
PR python/15464
PR python/16113
* valops.c (value_struct_elt_bitpos): New function
* py-type.c (convert_field): Set 'name' attribute of a gdb.Field
object to 'None' if the field name is an empty string ("").
* python/py-value.c (valpy_getitem): Use 'bitpos' and 'type'
attribute to look for a field when 'name' is 'None'.
(get_field_type): New function
testsuite/
* gdb.python/py-type.c: Enhance test case.
* gdb.python/py-value-cc.cc: Likewise
* gdb.python/py-type.exp: Add new tests.
* gdb.python/py-value-cc.exp: Likewise
Jan Kratochvil [Mon, 13 Jan 2014 20:20:21 +0000 (21:20 +0100)]
Fix set auto-load safe-path false warning regression (PR 16216)
gdb/
2014-01-07 Jan Kratochvil <jan.kratochvil@redhat.com>
PR threads/16216
* linux-thread-db.c (try_thread_db_load): Add parameter
check_auto_load_safe. Move here the file_is_auto_load_safe call.
(try_thread_db_load_from_pdir_1): Move it there from here.
(try_thread_db_load_from_sdir): Update caller.
(try_thread_db_load_from_dir): Move it there from here.
projects / thirdparty / binutils-gdb.git / log
