When a VDSO gets large enough that it doesn't entirely fit in one page,
but not so large that the part described by the program header exceeds
one page, then gdb/BFD doesn't read the section headers and symbol
table information. This patch cures that by passing the size of the
vdso to BFD, and fixes a number of other issues in the BFD code.
bfd/
* elfcode.h (bfd_from_remote_memory): Add "size" parameter.
Consolidate code handling possible section headers past end of
segment. Don't use p_align for page size guess, instead use
minpagesize. Take note of ld.so clearing section headers when
p_memsz > p_filesz. Handle file header specifying no section
headers. Handle zero p_align throughout. Default loadbase to
zero. Add comments. Rename contents_size to high_offset, and
make it a bfd_vma. Delete unnecessary bfd_set_error calls.
* bfd-in.h (bfd_elf_bfd_from_remote_memory): Update prototpe.
* elf-bfd.h (struct elf_backend_data <elf_backend_from_remote_memory>):
Likewise.
(_bfd_elf32_bfd_from_remote_memory): Likewise.
(_bfd_elf64_bfd_from_remote_memory): Likewise.
* elf.c (bfd_elf_bfd_from_remote_memory): Adjust.
* bfd-in2.h: Regnerate.
gdb/
* symfile-mem.c (symbol_file_add_from_memory): Add size parameter.
Pass to bfd_elf_bfd_from_remote_memory. Adjust all callers.
(struct symbol_file_add_from_memory_args): Add size field.
(find_vdso_size): New function.
(add_vsyscall_page): Attempt to find vdso size.
it is possible that gdb gets mach exceptions from an unknown inferior. This
happens when an inferior creates a child and that child gets a signal.
So instead of reporting messages with unknown origins, simply reply to these
notifications. The kernel will then post the unix signal.
gdb/
* darwin-nat.c (darwin_encode_reply): Add prototype.
(darwin_decode_exception_message): Reply to unknown inferiors.
(darwin_decode_message): Handle message by id. Ignore message
to unknown inferior.
(darwin_wait): Discard unknown messages, add debug trace.
* NEWS: Mention it.
* solib.c (solib_read_symbols): Only print symbol loading messages
if requested.
(solib_add): If symbol loading is in "brief" mode, notify user
symbols are being loaded.
(reload_shared_libraries_1): Ditto.
* symfile.c (print_symbol_loading_off): New static global.
(print_symbol_loading_brief): New static global.
(print_symbol_loading_full): New static global.
(print_symbol_loading_enums): New static global.
(print_symbol_loading): New static global.
(print_symbol_loading_p): New function.
(symbol_file_add_with_addrs): Only print symbol loading messages
if requested.
(_initialize_symfile): Register "print symbol-loading" set/show
command.
* symfile.h (print_symbol_loading_p): Declare.
doc/
* gdb.texinfo (Symbols): Document set/show print symbol-loading.
testsuite/
* gdb.base/print-symbol-loading-lib.c: New file.
* gdb.base/print-symbol-loading-main.c: New file.
* gdb.base/print-symbol-loading.exp: New file.
Given the following variable...
BT : Bounded := New_Bounded (Low => 1, High => 3);
... where type Bounded is defined as a simple unconstrained array:
type Bounded is array (Integer range <>) of Integer;
Creating a varobj for that variable, and immediately asking for
varobj updates, GDB says that our varobj changed types!
(gdb)
-var-create bt * bt
^done,name="bt",numchild="3",value="[3]",type="<ref> array (1 .. 3) of integer",has_more="0"
(gdb)
-var-update 1 *
^done,changelist=[{name="bt",value="[3]",in_scope="true",type_changed="true",new_type="<ref> array (1 .. 3) of integer",new_num_children="3",has_more="0"}]
The expected output for the -var-update command is, in this case:
(gdb)
-var-update 1 *
^done,changelist=[]
The problem occurs because the ada-varobj module does not handle
references, and while the references gets stripped when the varobj
gets created, it doesn't when computing varobj updates.
More specifically, when creating the varobj, varobj_create creates
a new value which is a reference to a TYPE_CODE_ARRAY. It then calls
install_new_value which calls coerce_ref with the following comment:
/* We are not interested in the address of references, and given
that in C++ a reference is not rebindable, it cannot
meaningfully change. So, get hold of the real value. */
if (value)
value = coerce_ref (value);
This leaves the varobj's type component still a ref, while
the varobj's value is now our array, without the ref. This explains
why the "value" field in the varobj indicates an array with 3 elements
"[3]" while the "type" field shows a ref to an array. Generally
speaking, most users have said that showing the ref was a useful
piece of information, so this patch is not touching this part.
Next, when the user issues the -var-update request, varobj_update
calls value_of_root to compute the varobj's new value as well as
determine whether the value's type has changed or not. What happens
in a nutshell is that it calls value_of_root_1 (which re-evaluates
the expression and returns the corresponding new value), finds that
the new value is not NULL, and thus asks whether it has mutated:
else if (varobj_value_has_mutated (var, value, value_type (value)))
This then indirectly delegates the determination to the language-specific
callback, which fails, because it does not handle references.
This patch fixes the issue by adjusting varobj_value_has_mutated to
expect references, and strip them when seen. This allows the various
language-specific implementations to remain unaware of references.
gdb/ChangeLog:
* varobj.c (varobj_value_has_mutated): If NEW_VALUE is
a reference, strip the reference layer before calling
the lang_ops value_has_mutated callback.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_dyn_arr: New testcase.
Sourcing a GDB script that runs foreground execution commands in
succession fails if the target can async:
Breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.base/source-execution.c:36
36 func1 ();
(gdb) source ../../../src/gdb/testsuite/gdb.base/source-execution.gdb
../../../src/gdb/testsuite/gdb.base/source-execution.gdb:21: Error in sourced command file:
Cannot execute this command while the selected thread is running.
(gdb) FAIL: gdb.base/source-execution.exp: source source-execution.gdb
That is, after a foreground execution command, GDB moves on to the
following command immediately before waiting for the previous command
to complete.
https://sourceware.org/ml/gdb-patches/2011-09/msg00037.html (b4a14fd0)
addressed this for command lists, Python's gdb.execute, etc., but
missed "source". Fixed now in the same way.
gdb/
2014-03-25 Pedro Alves <palves@redhat.com>
* cli/cli-script.c (script_from_file): Force the interpreter to
sync mode.
gdb/testsuite/
2014-03-25 Pedro Alves <palves@redhat.com>
Doug Evans <dje@google.com>
* gdb.base/source-execution.c: New file.
* gdb.base/source-execution.exp: New file.
* gdb.base/source-execution.gdb: New file.
As we move code on reading unavailable memory to target side, GDB core
side doesn't need the "switching momentarily out of tfind mode" dance.
The target remote knows how to read live memory (through remote_ops).
Remove set_traceframe_number and
make_cleanup_restore_traceframe_number, since they are no longer used.
gdb:
2014-03-22 Yao Qi <yao@codesourcery.com>
* remote.c (target_read_live_memory): Remove.
(memory_xfer_live_readonly_partial): Rename it to
remote_xfer_live_readonly_partial. Remove argument 'object'.
All callers updated. Call remote_read_bytes_1
instead of target_read_live_memory.
* tracepoint.c (set_traceframe_number): Remove.
(make_cleanup_restore_traceframe_number): Likewise .
* tracepoint.h (set_traceframe_number): Remove declaration.
(make_cleanup_restore_traceframe_number): Likewise.
This patch moves code in remote_read_bytes on reading from the remote
stub to a new function remote_read_bytes_1.
gdb:
2014-03-22 Yao Qi <yao@codesourcery.com>
* remote.c (remote_read_bytes): Move code on reading from the
remote stub to ...
(remote_read_bytes_1): ... here. New function.
As a follow-up to
[PATCH 7/8] Adjust read_value_memory to use to_xfer_partial
https://sourceware.org/ml/gdb-patches/2014-02/msg00384.html
this patch moves traceframe_available_memory down to the target side.
After this patch, the gdb core code is cleaner, and code on handling
unavailable memory is moved to remote/tfile/ctf targets.
In details, this patch moves traceframe_available_memory code from
memory_xfer_partial_1 to remote target only, so remote target still
uses traceframe_info mechanism to check unavailable memory, and use
remote_ops to read them from read-only sections. We don't use
traceframe_info mechanism for tfile and ctf target, because it is
fast to iterate all traceframes from trace file, so the summary
information got from traceframe_info is not necessary.
This patch also moves two functions to remote.c from target.c,
because they are only used in remote.c. I'll clean them up in another
patch.
gdb:
2014-03-22 Yao Qi <yao@codesourcery.com>
* ctf.c (ctf_xfer_partial): Check the return value of
exec_read_partial_read_only, if it is not TARGET_XFER_OK,
return TARGET_XFER_UNAVAILABLE.
* tracefile-tfile.c (tfile_xfer_partial): Likewise.
* target.c (target_read_live_memory): Move it to remote.c.
(memory_xfer_live_readonly_partial): Likewise.
(memory_xfer_partial_1): Move some code to remote_read_bytes.
* remote.c (target_read_live_memory): Moved from target.c.
(memory_xfer_live_readonly_partial): Likewise.
(remote_read_bytes): New, factored out from
memory_xfer_partial_1.
ps -e | grep a.out
28886 pts/12 00:00:00 a.out
gdb -p 28886
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0000003b0ccbc970 in __nanosleep_nocancel () from /lib64/libc.so.6
../../binutils-gdb/gdb/cleanups.c:265: internal-warning: restore_my_cleanups has found a stale cleanup
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The backtrace of this issue:
(gdb) bt
file=0x8b0c10 "s' failed.", line=265, fmt=0x8b0c38 "nutils-gdb/gdb/cleanups.c",
ap=0x7fff803e3ed8) at ../../binutils-gdb/gdb/utils.c:748
fmt=0x8b0c38 "nutils-gdb/gdb/cleanups.c", ap=0x7fff803e3ed8)
at ../../binutils-gdb/gdb/utils.c:799
string=0x8b0c38 "nutils-gdb/gdb/cleanups.c") at ../../binutils-gdb/gdb/utils.c:809
at ../../binutils-gdb/gdb/cleanups.c:265
at ../../binutils-gdb/gdb/cleanups.c:276
at ../../binutils-gdb/gdb/exceptions.c:142
at ../../binutils-gdb/gdb/exceptions.c:203
command=0x5d5fb8 <attach_command_continuation_free_args+18>, arg=0x7fff803e525b "2914",
from_tty=1, mask=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:549
---Type <return> to continue, or q <return> to quit---
func_args=0x7fff803e4280, errstring=0x8cf2e4 "/local/bin", mask=RETURN_MASK_ALL)
at ../../binutils-gdb/gdb/exceptions.c:522
This is a new issue. It is introduced by commit https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8bc2fe488957946d2cdccda3ce8d4f39e4003ea0
It removed the discard_cleanups (back_to) inside attach_command.
Then restore_my_cleanups will throw a internal_warning.
https://sourceware.org/ml/gdb-patches/2014-03/msg00374.html
2014-03-21 Hui Zhu <hui@codesourcery.com>
Pedro Alves <palves@redhat.com>
* darwin-nat.c (darwin_pid_to_exec_file): Change xmalloc to
static buffer.
* fbsd-nat.c (fbsd_pid_to_exec_file): Ditto.
* linux-nat.c (linux_child_pid_to_exec_file): Ditto.
* nbsd-nat.c (nbsd_pid_to_exec_file): Ditto.
-- Initial message by Tom Tromey:
While testing on AIX, I happened to notice an internal error coming
from parse_probes. This happens because there are no probes defined
on this platform. This patch fixes the problem by changing an assert
into an ordinary error, and then changing the relevant caller to cope.
This fixes a few tests on AIX; also regtested on x86-64 Fedora 18.
-- Followup by Sergio Durigan Junior:
By reading the patch (and the original code), I found it a little bit
obscure, so I took the liberty to try to improve it. Here's the patch.
Could you please take a look and see if it works on AIX (and also if you
like the approach)?
gdb/
2014-03-20 Tom Tromey <tromey@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
* probe.c (parse_probes): Turn assert into an ordinary error.
* break-catch-throw.c (re_set_exception_catchpoint): Ignore
exceptions when parsing probes. Rearrange the code for clarity.
With target async enabled, py-finish-breakpoint.exp triggers an
assertion failure.
The failure occurs because execute_command re-enters the event loop in
some circumstances, and in this case resets the sync_execution flag.
Then later GDB reaches this assertion in normal_stop:
gdb_assert (sync_execution || !target_can_async_p ());
In detail:
#1 - A synchronous execution command is run. sync_execution is set.
#2 - A python breakpoint is hit (TARGET_WAITKIND_STOPPED), and the
corresponding Python breakpoint's stop method is executed. When
and while python commands are executed, interpreter_async is
forced to 0.
#3 - The Python stop method happens to execute a not-execution-related
gdb command. In this case, "where 1".
#4 - Seeing that sync_execution is set, execute_command nests a new
event loop (although that wasn't necessary; this is the problem).
#5 - The linux-nat target's pipe in the event loop happens to be
marked. That's normal, due to this in linux_nat_wait:
/* If we requested any event, and something came out, assume there
may be more. If we requested a specific lwp or process, also
assume there may be more. */
The nested event loop thus immediately wakes up and calls
target_wait. No thread is actually executing in the inferior, so
the target returns TARGET_WAITKIND_NO_RESUMED.
#6 - normal_stop is reached. GDB prints "No unwaited-for children
left.", and resets the sync_execution flag (IOW, there are no
resumed threads left, so the synchronous command is considered
completed.) This is already bogus. We were handling a
breakpoint!
#7 - the nested event loop unwinds/ends. GDB is now back to handling
the python stop method (TARGET_WAITKIND_STOPPED), which decides
the breakpoint should stop. normal_stop is called for this
event. However, normal_stop actually works with the _last_
reported target status:
void
normal_stop (void)
{
struct target_waitstatus last;
ptid_t last_ptid;
struct cleanup *old_chain = make_cleanup (null_cleanup, NULL);
...
get_last_target_status (&last_ptid, &last);
...
if (last.kind == TARGET_WAITKIND_NO_RESUMED)
{
gdb_assert (sync_execution || !target_can_async_p ());
target_terminal_ours_for_output ();
printf_filtered (_("No unwaited-for children left.\n"));
}
And due to the nesting in execute command, the last event is now
TARGET_WAITKIND_NO_RESUMED, not the actual breakpoint event being
handled. This could be seen to be broken in itself, but we can
leave fixing that for another pass. The assertion is reached, and
fails.
execute_command has a comment explaining when it should synchronously
wait for events:
/* If the interpreter is in sync mode (we're running a user
command's list, running command hooks or similars), and we
just ran a synchronous command that started the target, wait
for that command to end. */
However, the code did not follow this comment -- it didn't check to
see if the command actually started the target, just whether the
target was executing a sync command at this point.
This patch fixes the problem by noting whether the target was
executing in sync_execution mode before running the command, and then
augmenting the condition to test this as well.
2014-03-20 Tom Tromey <tromey@redhat.com>
PR gdb/14135
* top.c (execute_command): Only dispatch events if the command
started the target.
When target-async is enabled, dprintf.exp fails:
Running ../../../src/gdb/testsuite/gdb.base/dprintf.exp ...
FAIL: gdb.base/dprintf.exp: 1st dprintf, call
FAIL: gdb.base/dprintf.exp: 2nd dprintf, call
FAIL: gdb.base/dprintf.exp: Set dprintf function
FAIL: gdb.base/dprintf.exp: 1st dprintf, fprintf
FAIL: gdb.base/dprintf.exp: 2nd dprintf, fprintf
Breakpoint 2, main (argc=1, argv=0x7fffffffd3f8) at ../../../src/gdb/testsuite/gdb.base/dprintf.c:33
33 int loc = 1234;
(gdb) continue
Continuing.
kickoff 1234
also to stderr 1234
At foo entry
(gdb) FAIL: gdb.base/dprintf.exp: 1st dprintf, call
The problem is that GDB gave the prompt back to the user too early.
This happens when calling functions while handling an event that
doesn't cause a user visible stop. dprintf with "set dprintf-style
gdb" is one such case. This patch adds a test case that has a
breakpoint with a condition that calls a function that returns false,
so that regression testing isn't dependent on the implementation of
dprintf.
The problem happens because run_inferior_call causes GDB to forget
that it is running in sync_execution mode, so any event that runs an
inferior call causes fetch_inferior_event to display the prompt, even
if the event should not result in a user visible stop (that is, gdb
resumes the inferior and waits for the next event).
This patch fixes the issue by noticing when GDB was in sync_execution
mode in run_inferior_call, and taking care to restore this state
afterward.
gdb/
2014-03-20 Tom Tromey <tromey@redhat.com>
PR cli/15718
* infcall.c: Include event-top.h.
(run_inferior_call): Call async_disable_stdin if needed.
gdb/testsuite/
2014-03-20 Tom Tromey <tromey@redhat.com>
Pedro Alves <palves@redhat.com>
PR cli/15718
* gdb.base/condbreak-call-false.c: New file.
* gdb.base/condbreak-call-false.exp: New file.
This test fails with current mainline.
If the program stopped for a breakpoint in thread 1, and then the user
switches to thread 2, and resumes the program, GDB first switches back
to thread 1 to step it over the breakpoint, in order to make progress.
However, that logic only considers the last reported event, assuming
only one thread needs that stepping over dance.
That's actually not true when we play with scheduler-locking. The
patch adds an example to the testsuite of multiple threads needing a
step-over before the stepping thread can be resumed. With current
mainline, the program re-traps the same breakpoint it had already
trapped before.
E.g.:
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint
info threads
Id Target Id Frame
3 Thread 0x7ffff77c9700 (LWP 4310) "multiple-step-o" 0x00000000004007ca in child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:43
2 Thread 0x7ffff7fca700 (LWP 4309) "multiple-step-o" 0x0000000000400827 in child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:60
* 1 Thread 0x7ffff7fcb740 (LWP 4305) "multiple-step-o" main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: info threads shows all threads
set scheduler-locking on
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: set scheduler-locking on
break 44
Breakpoint 3 at 0x4007d3: file ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 44.
(gdb) break 61
Breakpoint 4 at 0x40082d: file ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 61.
(gdb) thread 3
[Switching to thread 3 (Thread 0x7ffff77c9700 (LWP 4310))]
#0 0x00000000004007ca in child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:43
43 (*myp) ++;
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 3
continue
Continuing.
Breakpoint 3, child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:44
44 callme (); /* set breakpoint thread 3 here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint in thread 3
p *myp = 0
$1 = 0
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: unbreak loop in thread 3
thread 2
[Switching to thread 2 (Thread 0x7ffff7fca700 (LWP 4309))]
#0 0x0000000000400827 in child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:60
60 (*myp) ++;
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 2
continue
Continuing.
Breakpoint 4, child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:61
61 callme (); /* set breakpoint thread 2 here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint in thread 2
p *myp = 0
$2 = 0
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: unbreak loop in thread 2
thread 1
[Switching to thread 1 (Thread 0x7ffff7fcb740 (LWP 4305))]
#0 main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 1
set scheduler-locking off
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: set scheduler-locking off
At this point all thread are stopped for a breakpoint that needs stepping over.
(gdb) step
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) FAIL: gdb.threads/multiple-step-overs.exp: step
But that "step" retriggers the same breakpoint instead of making
progress.
The patch teaches GDB to step over all breakpoints of all threads
before resuming the stepping thread.
Tested on x86_64 Fedora 17, against pristine mainline, and also my
branch that implements software single-stepping on x86.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* infrun.c (prepare_to_proceed): Delete.
(thread_still_needs_step_over): New function.
(find_thread_needs_step_over): New function.
(proceed): If the current thread needs a step-over, set its
steping_over_breakpoint flag. Adjust to use
find_thread_needs_step_over instead of prepare_to_proceed.
(process_event_stop_test): For BPSTAT_WHAT_STOP_NOISY and
BPSTAT_WHAT_STOP_SILENT, assume the thread stopped for a
breakpoint.
(switch_back_to_stepped_thread): Step over breakpoints of all
threads not the stepping thread, before switching back to the
stepping thread.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/multiple-step-overs.c: New file.
* gdb.threads/multiple-step-overs.exp: New file.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Adjust expected infrun debug output.
Even with deferred_step_ptid out of the way, GDB can still lose
watchpoints.
If a watchpoint triggers and the PC points to an address where a
thread-specific breakpoint for another thread is set, the thread-hop
code triggers, and we lose the watchpoint:
if (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP)
{
int thread_hop_needed = 0;
struct address_space *aspace =
get_regcache_aspace (get_thread_regcache (ecs->ptid));
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
^^^^^^^^^^^^^^^^^^^^^
}
And on software single-step targets, even without a thread-specific
breakpoint in the way, here in the thread-hop code:
else if (singlestep_breakpoints_inserted_p)
{
...
if (!ptid_equal (singlestep_ptid, ecs->ptid)
&& in_thread_list (singlestep_ptid))
{
/* If the PC of the thread we were trying to single-step
has changed, discard this event (which we were going
to ignore anyway), and pretend we saw that thread
trap. This prevents us continuously moving the
single-step breakpoint forward, one instruction at a
time. If the PC has changed, then the thread we were
trying to single-step has trapped or been signalled,
but the event has not been reported to GDB yet.
There might be some cases where this loses signal
information, if a signal has arrived at exactly the
same time that the PC changed, but this is the best
we can do with the information available. Perhaps we
should arrange to report all events for all threads
when they stop, or to re-poll the remote looking for
this particular thread (i.e. temporarily enable
schedlock). */
CORE_ADDR new_singlestep_pc
= regcache_read_pc (get_thread_regcache (singlestep_ptid));
if (new_singlestep_pc != singlestep_pc)
{
enum gdb_signal stop_signal;
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog, "infrun: unexpected thread,"
" but expected thread advanced also\n");
/* The current context still belongs to
singlestep_ptid. Don't swap here, since that's
the context we want to use. Just fudge our
state and continue. */
stop_signal = ecs->event_thread->suspend.stop_signal;
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
ecs->ptid = singlestep_ptid;
ecs->event_thread = find_thread_ptid (ecs->ptid);
ecs->event_thread->suspend.stop_signal = stop_signal;
stop_pc = new_singlestep_pc;
}
else
{
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog,
"infrun: unexpected thread\n");
thread_hop_needed = 1;
stepping_past_singlestep_breakpoint = 1;
saved_singlestep_ptid = singlestep_ptid;
}
}
}
we either end up with thread_hop_needed, ignoring the watchpoint
SIGTRAP, or switch to the stepping thread, again ignoring that the
SIGTRAP could be for some other event.
The new test added by this patch exercises both paths.
So the fix is similar to the deferred_step_ptid fix -- defer the
thread hop to _after_ the SIGTRAP had a change of passing through the
regular bpstat handling. If the wrong thread hits a breakpoint, we'll
just end up with BPSTAT_WHAT_SINGLE, and if nothing causes a stop,
keep_going starts a step-over.
Most of the stepping_past_singlestep_breakpoint mechanism is really
not necessary -- setting the thread to step over a breakpoint with
thread->trap_expected is sufficient to keep all other threads locked.
It's best to still keep the flag in some form though, because when we
get to keep_going, the software single-step breakpoint we need to step
over is already gone -- an optimization done by a follow up patch will
check whether a step-over is still be necessary by looking to see
whether the breakpoint is still there, and would find the thread no
longer needs a step-over, while we still want it.
Special care is still needed to handle the case of PC of the thread we
were trying to single-step having changed, like in the old code. We
can't just keep_going and re-step it, as in that case we can over-step
the thread (if it was already done with the step, but hasn't reported
it yet, we'd ask it to step even further). That's now handled in
switch_back_to_stepped_thread. As bonus, we're now using a technique
that doesn't lose signals, unlike the old code -- we now insert a
breakpoint at PC, and resume, which either reports the breakpoint
immediately, or any pending signal.
Tested on x86_64 Fedora 17, against pristine mainline, and against a
branch that implements software single-step on x86.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* breakpoint.c (single_step_breakpoint_inserted_here_p): Make
extern.
* breakpoint.h (single_step_breakpoint_inserted_here_p): Declare.
* infrun.c (saved_singlestep_ptid)
(stepping_past_singlestep_breakpoint): Delete.
(resume): Remove stepping_past_singlestep_breakpoint handling.
(proceed): Store the prev_pc of the stepping thread too.
(init_wait_for_inferior): Adjust. Clear singlestep_ptid and
singlestep_pc.
(enum infwait_states): Delete infwait_thread_hop_state.
(struct execution_control_state) <hit_singlestep_breakpoint>: New
field.
(handle_inferior_event): Adjust.
(handle_signal_stop): Delete stepping_past_singlestep_breakpoint
handling and the thread-hop code. Before removing single-step
breakpoints, check whether the thread hit a single-step breakpoint
of another thread. If it did, the trap is not a random signal.
(switch_back_to_stepped_thread): If the event thread hit a
single-step breakpoint, unblock it before switching to the
stepping thread. Handle the case of the stepped thread having
advanced already.
(keep_going): Handle the case of the current thread moving past a
single-step breakpoint.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-trips-on-watchpoint.c: New file.
* gdb.threads/step-over-trips-on-watchpoint.exp: New file.
Say the program is stopped at a breakpoint, and the user sets a
watchpoint. When the program is next resumed, GDB will first step
over the breakpoint, as explained in the manual:
@value {GDBN} normally ignores breakpoints when it resumes
execution, until at least one instruction has been executed. If it
it did not do this, you would be unable to proceed past a breakpoint
without first disabling the breakpoint. This rule applies whether
or not the breakpoint already existed when your program stopped.
However, GDB currently also removes watchpoints, catchpoints, etc.,
and that means that the first instruction off the breakpoint does not
trigger the watchpoint, catchpoint, etc.
testsuite/gdb.base/watchpoint.exp has a kfail for this.
The PR proposes installing watchpoints only when stepping over a
breakpoint, but that misses catchpoints, etc.
A better fix would instead work from the opposite direction -- remove
only real breakpoints, leaving all other kinds of breakpoints
inserted.
But, going further, it's really a waste to constantly remove/insert
all breakpoints when stepping over a single breakpoint (generating a
pair of RSP z/Z packets for each breakpoint), so the fix goes a step
further and makes GDB remove _only_ the breakpoint being stepped over,
leaving all others installed. This then has the added benefit of
reducing breakpoint-related RSP traffic substancialy when there are
many breakpoints set.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
PR breakpoints/7143
* breakpoint.c (should_be_inserted): Don't insert breakpoints that
are being stepped over.
(breakpoint_address_match): Make extern.
* breakpoint.h (breakpoint_address_match): New declaration.
* inferior.h (stepping_past_instruction_at): New declaration.
* infrun.c (struct step_over_info): New type.
(step_over_info): New global.
(set_step_over_info, clear_step_over_info)
(stepping_past_instruction_at): New functions.
(handle_inferior_event): Clear the step-over info when
trap_expected is cleared.
(resume): Remove now stale comment.
(clear_proceed_status): Clear step-over info.
(proceed): Adjust step-over handling to set or clear the step-over
info instead of removing all breakpoints.
(handle_signal_stop): When setting up a thread-hop, don't remove
breakpoints here.
(stop_stepping): Clear step-over info.
(keep_going): Adjust step-over handling to set or clear step-over
info and then always inserting breakpoints, instead of removing
all breakpoints when stepping over one.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
PR breakpoints/7143
* gdb.base/watchpoint.exp: Mention bugzilla bug number instead of
old gnats gdb/38. Remove kfail. Adjust to use gdb_test instead
of gdb_test_multiple.
* gdb.cp/annota2.exp: Remove kfail for gdb/38.
* gdb.cp/annota3.exp: Remove kfail for gdb/38.
Consider the case of the user doing "step" in thread 2, while thread 1
had previously stopped for a breakpoint. In order to make progress,
GDB makes thread 1 step over its breakpoint first (with all other
threads stopped), and once that is over, thread 2 then starts stepping
(with thread 1 and all others running free, by default). If GDB
didn't do that, thread 1 would just trip on the same breakpoint
immediately again. This is what the prepare_to_proceed /
deferred_step_ptid code is all about.
However, deferred_step_ptid code resumes the target with:
resume (1, GDB_SIGNAL_0);
prepare_to_wait (ecs);
return;
Recall we were just stepping over a breakpoint when we get here. That
means that _nothing_ had installed breakpoints yet! If there's
another breakpoint just after the breakpoint that was just stepped,
we'll miss it. The fix for that would be to use keep_going instead.
However, there are more problems. What if the instruction that was
just single-stepped triggers a watchpoint? Currently, GDB just
happily resumes the thread, losing that too...
Missed watchpoints will need yet further fixes, but we should keep
those in mind.
So the fix must be to let the trap fall through the regular bpstat
handling, and only if no breakpoint, watchpoint, etc. claims the trap,
shall we switch back to the stepped thread.
Now, nowadays, we have code at the tail end of trap handling that does
exactly that -- switch back to the stepped thread
(switch_back_to_the_stepped_thread).
So the deferred_step_ptid code is just standing in the way, and can
simply be eliminated, fixing bugs in the process. Sweet.
The comment about spurious "Switching to ..." made me pause, but is
actually stale nowadays. That isn't needed anymore.
previous_inferior_ptid used to be re-set at each (internal) event, but
now it's only touched in proceed and normal stop.
The two tests added by this patch fail without the fix.
Tested on x86_64 Fedora 17 (also against my software single-stepping
on x86 branch).
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* infrun.c (previous_inferior_ptid): Adjust comment.
(deferred_step_ptid): Delete.
(infrun_thread_ptid_changed, prepare_to_proceed)
(init_wait_for_inferior): Adjust.
(handle_signal_stop): Delete deferred_step_ptid handling.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-lands-on-breakpoint.c: New file.
* gdb.threads/step-over-lands-on-breakpoint.exp: New file.
gdb/
2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/15358
* defs.h (sync_quit_force_run): New declaration.
(QUIT): Check also SYNC_QUIT_FORCE_RUN.
* event-top.c (async_sigterm_handler): New declaration.
(async_sigterm_token): New variable.
(async_init_signals): Create also async_sigterm_token.
(async_sigterm_handler): New function.
(sync_quit_force_run): New variable.
(handle_sigterm): Replace quit_force call by other calls.
* utils.c (quit): Call quit_force if SYNC_QUIT_FORCE_RUN.
gdb/testsuite/
2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/15358
* gdb.base/gdb-sigterm.c: New file.
* gdb.base/gdb-sigterm.exp: New file.
Message-ID: <20140316135334.GA30698@host2.jankratochvil.net>
This change corrects GPR frame offset calculation for the e500v2
processor. On this target, featuring the SPE APU, GPRs are 64-bit and
are held in stack frames whole with the use of `evstdd' and `evldd'
instructions. Their integer 32-bit part occupies the low-order word and
therefore its offset varies between the two endiannesses possible.
* rs6000-tdep.c (rs6000_frame_cache): Correct little-endian GPR
offset into SPE pseudo registers.
Part of PR gdb/13860 is about the mi-solib.exp test's output being
different in sync vs async modes.
sync:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
&"start\n"
~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"}
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17724"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
~"Stopped due to shared library event (no libraries added or removed)\n"
*stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3"
(gdb)
async:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async on" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
start
&"start\n"
~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"}
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17729"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
(gdb)
*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1"
For now, let's focus only on the *stopped event. We see that the
async output is missing frame info. And this causes a test failure in
async mode, as "mi_expect_stop solib-event" wants to see the frame
info.
However, if we compare the event output when a real MI execution
command is used, compared to a CLI command (e.g., run vs -exec-run,
next vs -exec-next, etc.), we see:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
r
&"r\n"
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17751"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
~"Stopped due to shared library event (no libraries added or removed)\n"
*stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3"
(gdb)
-exec-run
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1"
=library-unloaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",thread-group="i1"
=thread-group-started,id="i1",pid="17754"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1"
=thread-selected,id="1"
(gdb)
As seen above, with MI commands, the *stopped event _doesn't_ have
frame info. This is because normal_stop, as commanded by the result
of bpstat_print, skips printing frame info in this case (it's an
"event", not a "breakpoint"), and when the interpreter is MI,
mi_on_normal_stop skips calling print_stack_frame, as the normal_stop
call was already done with the MI uiout. This explains why the async
output is different even with a CLI command. Its because in async
mode, the mi_on_normal_stop path is always taken; it is always reached
with the MI uiout, because the stop is handled from the event loop,
instead of from within `proceed -> wait_for_inferior -> normal_stop'
with the interpreter overridden, as in sync mode.
This patch fixes the issue by making all cases output the same
*stopped event, by factoring out the print code from normal_stop, and
using it from mi_on_normal_stop as well. I chose the *stopped output
without a frame, mainly because that is what you already get if you
use MI execution commands, the commands frontends are supposed to use
(except when implementing a console). This patch makes it simpler to
tweak the MI output differently if desired, as we only have to change
the centralized print_stop_event (taking into account whether the
uiout is MI-like), and all different modes will change accordingly.
Tested on x86_64 Fedora 17, no regressions. The mi-solib.exp test no
longer fails in async mode with this patch, so the patch removes the
kfail.
2014-03-18 Pedro Alves <palves@redhat.com>
PR gdb/13860
* inferior.h (print_stop_event): Declare.
* infrun.c (print_stop_event): New, factored out from ...
(normal_stop): ... this.
* mi/mi-interp.c (mi_on_normal_stop): Use print_stop_event instead
of bpstat_print/print_stack_frame.
2014-03-18 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-solib.exp: Remove gdb/13860 kfail.
* lib/mi-support.exp (mi_expect_stop): Add special handling for
solib-event.
The destructor code in ui-out.c has a latent bug, which is hidden by
the fact that nothing uses this right now. This patch fixes the
problem. The bug is that we don't always clear a pointer in the
ui-out object, leading to a bad free.
2014-03-17 Tom Tromey <tromey@redhat.com>
* ui-out.c (clear_table, ui_out_new): Clear uiout->table.id.
Consider the following declarations:
type Packed_Array is array (Natural range <>) of Boolean;
pragma Pack (Packed_Array);
function Make (H, L : Natural) return Packed_Array is
begin
return (H .. L => False);
end Make;
A1 : Packed_Array := Make (1, 2);
A2 : Packed_Array renames A1;
One possible DWARF translation for A2 is:
<3><1e4>: Abbrev Number: 21 (DW_TAG_variable)
<1e5> DW_AT_name : a2
<1ea> DW_AT_type : <0x1d9>
<3><1d9>: Abbrev Number: 22 (DW_TAG_const_type)
<1da> DW_AT_type : <0x1de>
<3><1de>: Abbrev Number: 23 (DW_TAG_reference_type)
<1e0> DW_AT_type : <0x1a3>
<3><1a3>: Abbrev Number: 17 (DW_TAG_array_type)
<1a4> DW_AT_name : foo__Ta1S___XP1
<1a8> DW_AT_GNAT_descriptive_type: <0x16b>
<3><16b>: Abbrev Number: 6 (DW_TAG_typedef)
<16c> DW_AT_name : foo__Ta1S
<172> DW_AT_type : <0x176>
<3><176>: Abbrev Number: 17 (DW_TAG_array_type)
<177> DW_AT_name : foo__Ta1S
<17b> DW_AT_GNAT_descriptive_type: <0x223>
Here, foo__Ta1S___XP1 is the type used for the code generation while
foo__Ta1S is the source-level type. Both form a valid GNAT encoding for
a packed array type.
Trying to print A2 (1) can make GDB crash. This is because A2 is defined
as a reference to a GNAT encoding for a packed array. When decoding
constrained packed arrays, the ada_coerce_ref subprogram follows
references and returns a fixed type from the target type, peeling
the GNAT encoding for packed arrays. The remaining code assumes that
the resulting type is still such an encoding while we only have
a standard GDB array type, hence the crash:
arr = ada_coerce_ref (arr);
[...]
type = decode_constrained_packed_array_type (value_type (arr));
decode_constrained_packed_array_type assumes that its argument is
such an encoding. From its front comment:
/* The array type encoded by TYPE, where
ada_is_constrained_packed_array_type (TYPE). */
This patch simply replaces the call to ada_coerce_ref with a call
to coerce_ref in order to avoid prematurely transforming
the packed array type as a side-effect. This way, the remaining code
will always work with a GNAT encoding.
gdb/ChangeLog:
* ada-lang.c (decode_constrained_packed_array): Perform a
minimal coercion for reference with coerce_ref instead of
ada_coerce_ref.
This fixes a build failure against Python 2.4 by casting away "const"
on the second argument to PyObject_GetAttrString. Similar casts to
support Python 2.4 were already present in a number of other places.
gdb/
2014-03-16 Ulrich Weigand <uweigand@de.ibm.com>
* python/py-value.c (get_field_flag): Cast flag_name argument to
PyObject_GetAttrString to support Python 2.4.
gdb/
2014-03-14 Jan Kratochvil <jan.kratochvil@redhat.com>
* MAINTAINERS (The Official FSF-appointed GDB Maintainers)
(Global Maintainers): Remove Jan Kratochvil.
Looking at target_terminal_inferior etc. in async mode, I realized
that the naming of the terminal_inferior, terminal_ours,
etc. functions doesn't really give a clue that they're meant for the
native target only. This patch renames them. There's already
child_terminal_info using the child_ prefix, and, they're most
prominently installed by inf-child.c, so I went with the child_
prefix. I dropped "inferior" from a couple to make the name match the
corresponding target method.
Tested on x86_64 Fedora 17, and cross built for mingw. I didn't test
gnu-nat.c, but I think the change is as obvious as it gets. I grepped
the tree looking for other potential spots that would need adjustment
but this is all I found. If something breaks, it should be trivial to
fix.
gdb/
2014-03-14 Pedro Alves <palves@redhat.com>
* inferior.h (terminal_ours_for_output): Rename to ...
(child_terminal_ours_for_output): ... this.
(terminal_save_ours): Rename to ...
(child_terminal_save_ours): ... this.
(terminal_ours): Rename to ...
(child_terminal_ours): ... this.
(terminal_inferior): Rename to ...
(child_terminal_inferior): ... this.
(terminal_init_inferior): Rename to ...
(child_terminal_init_inferior): ... this.
(terminal_init_inferior_with_pgrp): Rename to ...
(child_terminal_init_inferior_with_pgrp): ... this.
* inflow.c (terminal_init_inferior_with_pgrp): Rename to ...
(child_terminal_init_with_pgrp): ... this.
(terminal_save_ours): Rename to ...
(child_terminal_save_ours): ... this.
(terminal_init_inferior): Rename to ...
(child_terminal_init): ... this. Adjust.
(terminal_inferior): Rename to ...
(child_terminal_inferior): ... this.
(terminal_ours_for_output): Rename to ...
(child_terminal_ours_for_output): ... this. Adjust.
(terminal_ours): Rename to ...
(child_terminal_ours): ... this.
(terminal_ours_1): Rename to ...
(child_terminal_ours_1): ... this. Adjust.
* linux-nat.c (linux_nat_terminal_inferior): Adjust.
* windows-nat.c (do_initial_windows_stuff): Adjust.
* gnu-nat.c (gnu_terminal_init_inferior): Rename to ...
(gnu_terminal_init): ... this. Adjust.
(gnu_target): Adjust.
* inf-child.c (inf_child_target): Adjust.
* guile/scm-type.c (tyscm_copy_type_recursive): Move type to its
new eq?-hashtab.
testsuite/
* gdb.guile/scm-value.ep (test_value_after_death): Do a garbage
collect after discarding symbols.
* value.c (record_latest_value): Call release_value_or_incref
instead of release_value.
testsuite/
* gdb.guile/scm-value.exp (test_value_in_inferior): Verify value added
to history survives a gc.
Note that "target procfs" is used by QNX, but the test must be failing
there, as nto-procfs.c overrides to_open with a method that doesn't
throw the error being tested. So I'm just removing the test
completely.
gdb/
2014-03-13 Pedro Alves <palves@redhat.com>
* procfs.c (procfs_target): Don't override to_shortname,
to_longname or to_doc.
gdb/testsuite/
2014-03-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Don't test "target procfs".
I find the mention of "Unix" unnecessary (and really slightly a lie)
on GNU/Linux in a couple of places:
(gdb) maint print target-stack
The current target stack is:
- multi-thread (multi-threaded child process.)
- child (Unix child process)
- exec (Local exec file)
- None (None)
(gdb) help target child
Unix child process (started by the "run" command).
(gdb) target child
Use the "run" command to start a Unix child process.
It's also odd that e.g., the Windows port says "Unix" in reaction to
"target child" (it was already that way before Windows used
inf-child.c):
(gdb) target child
Use the "run" command to start a Unix child process.
(gdb)
So drop "Unix", going in the direction of saying mostly the same on
all native targets:
(gdb) maint print target-stack
The current target stack is:
- multi-thread (multi-threaded child process.)
- - child (Unix child process)
+ - child (Child process)
- exec (Local exec file)
- None (None)
(gdb) help target child
- Unix child process (started by the "run" command).
+ Child process (started by the "run" command).
(gdb) target child
-Use the "run" command to start a Unix child process.
+Use the "run" command to start a child process.
gdb/
2014-03-13 Pedro Alves <palves@redhat.com>
* inf-child.c (inf_child_open, inf_child_target): Don't mention
Unix in user visible strings.
gdb/testsuite/
2014-03-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Update "target child" and "target procfs"
tests to not expect "Unix".
All execution commands currently have this pattern:
/* If we must run in the background, but the target can't do it,
error out. */
if (async_exec && !target_can_async_p ())
error (_("Asynchronous execution not supported on this target."));
/* If we are not asked to run in the bg, then prepare to run in the
foreground, synchronously. */
if (!async_exec && target_can_async_p ())
{
/* Simulate synchronous execution. */
async_disable_stdin ();
}
This patch factors that into a shared function.
attach_command installs a cleanup to re-enable stdin, but that's not
necessary, as per the comment in prepare_execution_command. In any
case, if someday it turns out necessary, we have a single place to
install it now.
Tested on x86_64 Fedora 17, sync and async modes.
gdb/
2014-03-12 Pedro Alves <palves@redhat.com>
* infcmd.c (prepare_execution_command): New function, factored out
from several execution commands.
(run_command_1, continue_command, step_1, jump_command)
(signal_command, until_command, advance_command, finish_command)
(attach_command): Use prepare_execution_command.
This patch updates arm native support for hwbreak-/watchpoints to enable
support for hwbreak-/watchpoints across fork/vfork. This involves changes to
hwbreak-/watchpoint insertion mechanism to the modern way, by marking debug
registers as needing update, but only really updating them on resume, which is
necessary for supporting watchpoints in non-stop mode. This also updates a
previously maintained per thread hwbreak-/watchpoint cache to a per process
cache which allows target specific code to come in sync with gdb-linux calls to
threads create/destroy and process fork/exit hooks.
I noticed 'make check TESTS="..."' works when ran from gdb/testsuite/,
but TESTS is ignored when "make check" is ran from gdb/.
The issue is that TESTS isn't being passed to the testsuite subdir
make invocation.
gdb/
2014-03-12 Pedro Alves <palves@redhat.com>
* Makefile.in (TARGET_FLAGS_TO_PASS): Add TESTS.
A patch in the target cleanup series caused a regression when using
record with target-async. Version 4 of the patch is here:
https://sourceware.org/ml/gdb-patches/2014-03/msg00159.html
The immediate problem is that record supplies to_can_async_p and
to_is_async_p methods, but does not supply a to_async method. So,
when target-async is set, record claims to support async -- but if the
underlying target does not support async, then the to_async method
call will end up in that method's default implementation, namely
tcomplain.
This worked previously because the record target used to provide a
to_async method; one that (erroneously, only at push time) checked the
other members of the target stack, and then simply dropped to_async
calls in the "does not implement async" case.
My first thought was to simply drop tcomplain as the default for
to_async. This works, but Pedro pointed out that the only reason
record has to supply to_can_async_p and to_is_async_p is that these
default to using the find_default_run_target machinery -- and these
defaults are only needed by "run" and "attach".
So, a nicer solution presents itself: change run and attach to
explicitly call into the default run target when needed; and change
to_is_async_p and to_can_async_p to default to "return 0". This makes
the target stack simpler to use and lets us remove the method
implementations from record. This is also in harmony with other plans
for the target stack; namely trying to reduce the impact of
find_default_run_target. This approach makes it clear that
find_default_is_async_p is not needed -- it is asking whether a target
that may not even be pushed is actually async, which seems like a
nonsensical question.
While an improvement, this approach proved to introduce the same bug
when using the core target. Looking a bit deeper, the issue is that
code in "attach" and "run" may need to use either the current target
stack or the default run target -- but different calls into the target
API in those functions could wind up querying different targets.
This new patch makes the target to use more explicit in "run" and
"attach". Then these commands explicitly make the needed calls
against that target. This ensures that a single target is used for
all relevant operations. This lets us remove a couple find_default_*
functions from various targets, including the dummy target. I think
this is a decent understandability improvement.
One issue I see with this patch is that the new calls in "run" and
"attach" are not very much like the rest of the target API. I think
fundamentally this is due to bad factoring in the target API, which
may need to be fixed for multi-target. Tackling that seemed ambitious
for a regression fix.
While working on this I noticed that there don't seem to be any test
cases that involve both target-async and record, so this patch changes
break-precsave.exp to add some. It also changes corefile.exp to add
some target-async tests; these pass with current trunk and with this
patch applied, but fail with the v1 patch.
This patch differs from v4 in that it moves initialization of
to_can_async_p and to_supports_non_stop into inf-child, adds some
assertions to complete_target_initialization, and adds some comments
to target.h.
Built and regtested on x86-64 Fedora 20.
2014-03-12 Tom Tromey <tromey@redhat.com>
* inf-child.c (return_zero): New function.
(inf_child_target): Set to_can_async_p, to_supports_non_stop.
* aix-thread.c (aix_thread_inferior_created): New function.
(aix_thread_attach): Remove.
(init_aix_thread_ops): Don't set to_attach.
(_initialize_aix_thread): Register inferior_created observer.
* corelow.c (init_core_ops): Don't set to_attach or
to_create_inferior.
* exec.c (init_exec_ops): Don't set to_attach or
to_create_inferior.
* infcmd.c (run_command_1): Use find_run_target. Make direct
target calls.
(attach_command): Use find_attach_target. Make direct target
calls.
* record-btrace.c (init_record_btrace_ops): Don't set
to_create_inferior.
* record-full.c (record_full_can_async_p, record_full_is_async_p):
Remove.
(init_record_full_ops, init_record_full_core_ops): Update. Don't
set to_create_inferior.
* target.c (complete_target_initialization): Add assertion.
(target_create_inferior): Remove.
(find_default_attach, find_default_create_inferior): Remove.
(find_attach_target, find_run_target): New functions.
(find_default_is_async_p, find_default_can_async_p)
(target_supports_non_stop, target_attach): Remove.
(init_dummy_target): Don't set to_create_inferior or
to_supports_non_stop.
* target.h (struct target_ops) <to_attach>: Add comment. Remove
TARGET_DEFAULT_FUNC.
<to_create_inferior>: Add comment.
<to_can_async_p, to_is_async_p, to_supports_non_stop>: Use
TARGET_DEFAULT_RETURN.
<to_can_async_p, to_supports_non_stop, to_can_run>: Add comments.
(find_attach_target, find_run_target): Declare.
(target_create_inferior): Remove.
(target_has_execution_1): Update comment.
(target_supports_non_stop): Remove.
* target-delegates.c: Rebuild.
2014-03-12 Tom Tromey <tromey@redhat.com>
* gdb.base/corefile.exp (corefile_test_run, corefile_test_attach):
New procs. Add target-async tests.
* gdb.reverse/break-precsave.exp (precsave_tests): New proc.
Add target-async tests.
Like inf-child.c, this file is no longer used exclusively by Unix
targets anymore.
gdb/
2014-03-12 Pedro Alves <palves@redhat.com>
* inf-child.h: Update comment to not mention Unix.
This file is no longer used exclusively by Unix targets anymore.
gdb/
2014-03-12 Pedro Alves <palves@redhat.com>
* inf-child.c: Update top comment to not mention Unix. Add
generic comment describing how this target is meant to be used.
(inf_child_post_attach, inf_child_post_startup_inferior)
(inf_child_follow_fork, inf_child_pid_to_exec_file): Don't mention
Unix in comment.
So that all native targets inherit a single "superclass".
Target methods that are set to or do the same as inf-child.c's are
removed.
Not tested.
gdb/
2014-03-12 Pedro Alves <palves@redhat.com>
* nto-procfs.c: Include inf-child.h.
(procfs_ops): Delete global.
(procfs_can_run): Delete method.
(procfs_detach, procfs_mourn_inferior): Unpush the passed in
target pointer instead of referencing procfs_ops.
(procfs_prepare_to_store): Delete.
(init_procfs_ops): Delete function.
(procfs_target): New function, based on init_procfs_ops, but
inherit inf_child_target.
(_initialize_procfs): Use procfs_target.
So that all native targets inherit a single "superclass".
Target methods that are set to or do the same as inf-child.c's are
removed.
Tested by cross building on Fedora 17, and then confirming that
./gdb.exe ./gdb.exe -ex "set pagination off" -ex "start"
under Wine still works.
Also, Joel tested this with Adacore's internal testsuite.
gdb/
2014-03-12 Pedro Alves <palves@redhat.com>
* windows-nat.c: Include inf-child.h.
(windows_ops): Delete global.
(windows_open, windows_prepare_to_store, windows_can_run): Delete
methods.
(init_windows_ops): Delete function.
(windows_target): New function, based on init_windows_ops, but
inherit inf_child_target.
(_initialize_windows_nat): Use windows_target. Install x86
specific target methods here.
When evaluating an expression, if it is of a tagged type, GDB reads
the tag in memory and deduces the full view. At parsing time, however,
this operation is done only in the case of OP_VAR_VALUE. ptype does
not go through a full evaluation of expressions so it may return some
odd results:
(gdb) print c.menu_name
$1 = 0x0
(gdb) ptype $
type = system.strings.string_access
(gdb) ptype c.menu_name
type = <void>
This change removes this peculiarity by extending the tag resolution
to UNOP_IND and STRUCTOP_STRUCT. As in the case of OP_VAR_VALUE, this
implies switching from EVAL_AVOID_SIDE_EFFECTS to EVAL_NORMAL when a
tagged type is dereferenced.
gdb/
* ada-lang.c (ada_evaluate_subexp): Resolve tagged types to
full view in the case of UNOP_IND and STRUCTOP_STRUCT.
gdb/testsuite/
* gdb.ada/tagged_access: New testcase.
This function is for simple breakpoint. So I post a patch to remove "hardware".
Thanks,
Hui
2014-03-10 Hui Zhu <hui@codesourcery.com>
* target.h (target_insert_breakpoint): Remove "hardware" from its
comments.
* dwarf2read.c (read_cutu_die_from_dwo): Fix function comment.
Remove unused local comp_dir_attr. Assert exactly one of
stub_comp_unit_die, stub_comp_dir is non-NULL.
Expand a bit the comments to answer some questions I had when looking
at why a target of mine would not have some default methods set.
gdb/ChangeLog:
* target.h (complete_target_initialization, add_target):
Add comment.
So that all native targets inherit a single "superclass".
Target methods that are set to or do the same as inf-child.c's are
removed.
Tested by cross building on Fedora 17.
gdb/
2014-03-07 Pedro Alves <palves@redhat.com>
* go32-nat.c: Include inf-child.h.
(go32_ops): Delete global.
(go32_close, go32_detach, go32_prepare_to_store, go32_can_run):
Delete methods.
(go32_create_inferior): Push the passed in target pointer instead
of referencing go32_ops.
(init_go32_ops): Delete function. Moved parts to _initialize_go32_nat.
(go32_target): New function, based on init_go32_ops, but inherit
inf_child_target.
(_initialize_go32_nat): Use go32_target. Move parts of
init_go32_ops here.
Some updates where needed after the minimal symbol handling got changed
a little. This patch makes those changes.
gdb/ChangeLog:
* sol-thread.c: #include "symtab.h", "minsym.h" and "objfiles.h".
(ps_pglobal_lookup): Use BMSYMBOL_VALUE_ADDRESS instead of
SYMBOL_VALUE_ADDRESS.
(info_cb): MSYMBOL_PRINT_NAME instead of SYMBOL_PRINT_NAME.
This patch is to remove parameter optional_p as it is always true,
in order to simplify get_tracepoint_by_number.
'optional_p' was added by this change,
1999-11-18 Tom Tromey <tromey@cygnus.com>
* tracepoint.h (get_tracepoint_by_number): Updated
declaration.
* tracepoint.c (trace_pass_command): Better error message.
Fixed logic when `all' not specified.
(get_tracepoint_by_number): Added `optional_p' argument. Fixed
all callers.
but after this patch,
FYI: remove `static's from cli-utils.c
https://sourceware.org/ml/gdb-patches/2011-03/msg00636.html
'optional_p' passed to get_tracepoint_by_number become always true.
gdb:
2014-03-06 Yao Qi <yao@codesourcery.com>
* breakpoint.c (get_tracepoint_by_number): Remove argument
optional_p. All callers updated. Adjust comments. Update
output message.
* breakpoint.h (get_tracepoint_by_number): Update declaration.
In GDB mainline, the error message for goto-bookmark
isn't perfect.
(gdb) goto-bookmark 1.1
goto-bookmark: no bookmark found for ''.
This patch tweaks the error message by checking the return value of
get_number. With patch applied, it becomes:
(gdb) goto-bookmark 1.1
goto-bookmark: invalid bookmark number '1.1'.
gdb:
2014-03-06 Yao Qi <yao@codesourcery.com>
* reverse.c (goto_bookmark_command): Add local 'p'. Emit error
early if get_number returns zero. Use 'p' instead of 'args'.
Hi,
GDB prints two warnings in one single line, as below:
(gdb) p 1.2
$1 = 1.2
(gdb) enable $1.2
History value must have integer type.Bad breakpoint number '$1'
This patch adds '\n' at the end of message.
gdb:
2014-03-06 Yao Qi <yao@codesourcery.com>
* cli/cli-utils.c (get_number_trailer): Add '\n' at the end of
message.
This patch fixes PR16508, which is about MI "-trace-find frame-number 0"
behaves differently from CLI "tfind 0". In CLI, we check both
status->running and status->filename, but in MI, we only check
status->running, which looks wrong to me. This patch moves the code
of checking to a new function check_trace_running, and use it in
both CLI and MI.
This patch also adds a test case pr16508.exp, which fails without this
fix, and passes with the fix applied.
FAIL: gdb.trace/pr16508.exp: interpreter-exec mi "-trace-find frame-number 0"
gdb:
2014-03-06 Yao Qi <yao@codesourcery.com>
PR breakpoints/16508
* tracepoint.c (check_trace_running): New function.
(trace_find_command): Move code to check_trace_running and
call check_trace_running.
(trace_find_pc_command): Likewise.
(trace_find_tracepoint_command): Likewise.
(trace_find_line_command): Likewise.
(trace_find_range_command): Likewise.
* tracepoint.h (check_trace_running): Likewise.
* mi/mi-main.c (mi_cmd_trace_find): Call check_trace_running.
gdb/testsuite:
2014-03-06 Yao Qi <yao@codesourcery.com>
* gdb.trace/pr16508.exp: New file.
This patch is to change the default implementation of to_traceframe_info
from 'return NULL' to tcomplain, which is intended. If new target
supports tracepoint, this method should be implemented, otherwise,
an error is thrown.
gdb:
2014-03-06 Yao Qi <yao@codesourcery.com>
* target.h (struct target_ops) <to_traceframe_info>: Use
TARGET_DEFAULT_NORETURN (tcomplain ()).
* target-delegates.c: Regenerated.
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, and make it follow the
new target_xfer_status/xfered_len style. This made me notice that
dcache_xfer_memory loses the real error status if a memory read fails:
we could have failed to read due to TARGET_XFER_E_UNAVAILABLE, for
instance, but we always return TARGET_XFER_E_IO, hence the FIXME note.
I felt that fixing that fell out of the scope of this patch.
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
target_xfer_status status 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.
This patch moves the probe data from the objfile to the per-BFD
object. This lets the probes be shared between different inferiors
(and different objfiles when dlmopen is in use, should gdb ever handle
that).
2014-03-03 Tom Tromey <tromey@redhat.com>
* elfread.c (probe_key): Change to bfd_data.
(elf_get_probes, probe_key_free, _initialize_elfread): Probes are
now per-BFD, not per-objfile.
* stap-probe.c (stap_probe_destroy): Update comment.
(handle_stap_probe): Allocate on the per-BFD obstack.
This changes the probes to be independent of the program space.
After this, when a probe's address is needed, it is determined by
applying offsets at the point of use.
This introduces a bound_probe object, similar to bound minimal
symbols. Objects of this type are used when it's necessary to pass a
probe and its corresponding objfile.
This removes the backlink from probe to objfile, which was primarily
used to fetch the architecture to use.
This adds a get_probe_address function which calls a probe method to
compute the probe's relocated address. Similarly, it adds an objfile
parameter to the semaphore methods so they can do the relocation
properly as well.
2014-03-03 Tom Tromey <tromey@redhat.com>
* break-catch-throw.c (fetch_probe_arguments): Use bound probes.
* breakpoint.c (create_longjmp_master_breakpoint): Use
get_probe_address.
(add_location_to_breakpoint, bkpt_probe_insert_location)
(bkpt_probe_remove_location): Update.
* breakpoint.h (struct bp_location) <probe>: Now a bound_probe.
* elfread.c (elf_symfile_relocate_probe): Remove.
(elf_probe_fns): Update.
(insert_exception_resume_breakpoint): Change type of "probe"
parameter to bound_probe.
(check_exception_resume): Update.
* objfiles.c (objfile_relocate1): Don't relocate probes.
* probe.c (bound_probe_s): New typedef.
(parse_probes): Use get_probe_address. Set sal's objfile.
(find_probe_by_pc): Return a bound_probe.
(collect_probes): Return a VEC(bound_probe_s).
(compare_probes): Update.
(gen_ui_out_table_header_info): Change type of "probes"
parameter. Update.
(info_probes_for_ops): Update.
(get_probe_address): New function.
(probe_safe_evaluate_at_pc): Update.
* probe.h (struct probe_ops) <get_probe_address>: New field.
<set_semaphore, clear_semaphore>: Add objfile parameter.
(struct probe) <objfile>: Remove field.
<arch>: New field.
<address>: Update comment.
(struct bound_probe): New.
(find_probe_by_pc): Return a bound_probe.
(get_probe_address): Declare.
* solib-svr4.c (struct probe_and_action) <address>: New field.
(hash_probe_and_action, equal_probe_and_action): Update.
(register_solib_event_probe): Add address parameter.
(solib_event_probe_at): Update.
(svr4_create_probe_breakpoints): Add objfile parameter. Use
get_probe_address.
* stap-probe.c (struct stap_probe) <sem_addr>: Update comment.
(stap_get_probe_address): New function.
(stap_can_evaluate_probe_arguments, compute_probe_arg)
(compile_probe_arg): Update.
(stap_set_semaphore, stap_clear_semaphore): Compute semaphore's
address.
(handle_stap_probe): Don't relocate the probe.
(stap_relocate): Remove.
(stap_gen_info_probes_table_values): Update.
(stap_probe_ops): Remove stap_relocate.
* symfile-debug.c (debug_sym_relocate_probe): Remove.
(debug_sym_probe_fns): Update.
* symfile.h (struct sym_probe_fns) <sym_relocate_probe>: Remove.
* symtab.c (init_sal): Use memset.
* symtab.h (struct symtab_and_line) <objfile>: New field.
* tracepoint.c (start_tracing, stop_tracing): Update.
This fixes up a few mildly erroneous comments in probe.h.
2014-03-03 Tom Tromey <tromey@redhat.com>
* probe.h (parse_probes, find_probe_by_pc)
(find_probes_in_objfile): Fix comments.
OpenBSD 5.2 and later have a proper threads implementation based on
kernel threads. Debugging support is provided through additional
ptrace(2) requests, so this diff extends the generic code in
inf-ptrace.c with OpenBSD-specific code to discover additional threads.
gdb/ChangeLog:
* obsd-nat.h: New file.
* obsd-nat.c: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add obsd-nat.h.
(ALLDEPFILES): Add obsd-nat.c.
This patch constifies ui_out_impl in struct ui_out, and various
instances of ui_out_impl.
This removes a couple of FIXME comments (near cli_ui_out_impl and
mi_ui_out_impl) that did not make sense to me.
Tested by rebuilding.
2014-02-28 Tom Tromey <tromey@redhat.com>
* cli-out.c (cli_ui_out_impl): Now const. Remove comment.
* cli-out.h (cli_ui_out_impl): Now const.
* mi/mi-out.c (mi_ui_out_impl): Now const. Remove comment.
* ui-out.c (struct ui_out) <impl>: Now const.
(default_ui_out_impl): Now const.
(ui_out_new): Make 'impl' parameter const.
* ui-out.h (ui_out_new): Update.
GCC 4.2.1 complains about first_l_name may be used uninitialized, and my brain
agrees.
gdb/ChangeLog:
* solib-svr4.c (svr4_read_so_list): Initialize first_l_name to 0.
runtest gdb.base/corefile.exp
==23174== ERROR: AddressSanitizer: heap-use-after-free on address 0x604400008c88 at pc 0x68f0be bp 0x7fffae9d7490 sp
0x7fffae9d7480
READ of size 8 at 0x604400008c88 thread T0
#0 0x68f0bd in svr4_read_so_list (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x68f0bd)
#1 0x68f64e in svr4_current_sos_direct (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x68f64e)
#2 0x68f757 in svr4_current_sos (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x68f757)
#3 0xcebbff in update_solib_list (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xcebbff)
0x604400008c88 is located 8 bytes inside of 1104-byte region [0x604400008c80,0x6044000090d0)
freed by thread T0 here:
#0 0x7f52677500f9 (/lib64/libasan.so.0+0x160f9)
#1 0xd2c68a in xfree (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xd2c68a)
#2 0xceb364 in free_so (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xceb364)
#3 0xca59f8 in do_free_so (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0xca59f8)
#4 0x93432a in do_my_cleanups (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x93432a)
#5 0x934406 in do_cleanups (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x934406)
#6 0x68efa9 in svr4_read_so_list (/home/jkratoch/redhat/gdb-clean/gdb/gdb+0x68efa9)
I did not notice it during my review in:
Re: [PATCH v2] Skip vDSO when reading SO list (PR 8882)
https://sourceware.org/ml/gdb-patches/2013-09/msg00888.html
gdb/
2014-02-27 Jan Kratochvil <jan.kratochvil@redhat.com>
Additional PR 8882 fix.
* solib-svr4.c (svr4_read_so_list): Change first to first_l_name.
Message-ID: <20140226220918.GA10431@host2.jankratochvil.net>
Just a small optimization. No need to block/unblock signals if we're
not going to call sigsuspend.
gdb/
2014-02-27 Pedro Alves <palves@redhat.com>
* nat/linux-waitpid.c (my_waitpid): Only block signals if WNOHANG
isn't set.
So that gdbserver's Linux backend can use it too.
gdb/
2014-02-27 Pedro Alves <palves@redhat.com>
PR 12702
* linux-nat.c (status_to_str): Moved to nat/linux-waitpid.c.
* nat/linux-waitpid.c: Include string.h.
(status_to_str): Moved here and made extern.
* nat/linux-waitpid.h (status_to_str): New declaration.
Necessary to fix parsing auxv entries from core files on systems that use
the layout specified by ELF instead of the incompatible variant used by Linux.
gdb/Changelog:
* gdbarch.sh (auxv_parse): New.
* gdbarch.h: Regenerated.
* gdbarch.c: Regenerated.
* auxv.c (target_auxv_parse): Call gdbarch_parse_auxv if provided.
Starting with DWARF version 4, the description of the DW_AT_high_pc
attribute was amended to say:
if it is of class constant, the value is an unsigned integer offset
which when added to the low PC gives the address of the first
location past the last instruction associated with the entity.
A change was made in Apr 27th, 2012 to reflect that change:
| commit 91da14142c
| Author: Mark Wielaard <mjw@redhat.com>
| Date: Fri Apr 27 18:55:19 2012 +0000
|
| * dwarf2read.c (dwarf2_get_pc_bounds): Check DW_AT_high_pc form to
| see whether it is an address or a constant offset from DW_AT_low_pc.
| (dwarf2_record_block_ranges): Likewise.
| (read_partial_die): Likewise.
Unfortunately, this new interpretation is now used regardless of
the CU's DWARF version. It turns out that one of WindRiver's compilers
(FTR: Diabdata 4.4) is generating DWARF version 2 info with
DW_AT_high_pc attributes improperly using the data4 form. Because of
that, we miscompute all high PCs incorrectly. This leads to a lot of
symtabs having overlapping ranges, which in turn causes havoc in
pc-to-symtab-and-line translations.
One visible effect is when inserting a breakpoint on a given function:
(gdb) b world
Breakpoint 1 at 0x4005c4
The source location of the breakpoint is missing. The output should be:
(gdb) b world
Breakpoint 1 at 0x4005c8: file dw2-rel-hi-pc-world.c, line 24.
What happens in this case is that the pc-to-SAL translation first
starts be trying to find the symtab associated to our PC using
each symtab's ranges. Because of the high_pc miscomputation,
many symtabs end up matching, and the heuristic trying to select
the most probable one unfortunately returns one that is unrelated
(it really had no change in this case to do any better). Once we
have the wrong symtab, the start searching the associated linetable,
where the addresses are correct, thus finding no match, and therefore
no SAL.
This patch is an attempt at handling the situation as gracefully
as we can, without guarantees. It introduces a new function
"attr_value_as_address" which uses the correct accessor for getting
the value of a given attribute. It then adjust the code throughout
this unit to use this function instead of assuming that addresses always
have the DW_FORM_addr format.
It also fixes the original issue of miscomputing the high_pc
by limiting the new interpretation of constant form DW_AT_high_pc
attributes to units using DWARF version 4 or later.
gdb/ChangeLog:
* dwarf2read.c (attr_value_as_address): New function.
(dwarf2_find_base_address, read_call_site_scope): Use
attr_value_as_address in place of DW_ADDR.
(dwarf2_get_pc_bounds): Use attr_value_as_address to get
the low and high addresses. Slight rework of the handling
of the high pc being a constant form, and limit it to
DWARF verson 4 or higher.
(dwarf2_record_block_ranges): Likewise.
(read_partial_die): Likewise.
(new_symbol_full): Use attr_value_as_address in place of DW_ADDR.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-abs-hi-pc-hello-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-hello.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.exp: New file.
Tested on x86_64-linux.
Right now the "file" command will discard the exec_bfd and then
possibly open a new one.
If this ends up reopening the same file, it can cause needless work by
gdb -- destroying all the per-BFD data just to re-read it again.
This patch changes the code to hold a reference to the old exec_bfd
while opening the new one.
The possible downside of this is a higher peak memory use.
2014-02-26 Tom Tromey <tromey@redhat.com>
* exec.c (exec_file_attach): Hold a reference to exec_bfd.
If minimal symbols have already been read into a per-BFD object, then
a symbol reader can skip re-reading them. This changes the ELF reader
to do so.
We only skip the work if the file is ELF+DWARF. If it has stabs or
mdebug sections, then I think extra information is computed during the
minsym creation pass; and so we must still repeat it. Eventually even
this will go away, once all symbol types have switched to being
progspace-independent. In the meantime this has no negative effect --
it is just a missing optimization for a small set of users.
This change also required a somewhat non-obvious change to the OBJSTAT
accounting code. If a symbol reader skips re-reading minimal symbols,
then the corresponding OBJSTAT will not be updated. This leads to a
test failure in gdb.base/maint.exp.
To fix this, I've moved the needed stat field out of objfile and into
the per-BFD object.
2014-02-26 Tom Tromey <tromey@redhat.com>
* elfread.c (elf_read_minimal_symbols): Return early if
minimal symbols have already been read. Add "ei" parameter.
(elf_symfile_read): Call elf_read_minimal_symbols earlier.
* minsyms.c (prim_record_minimal_symbol_full): Update.
* objfiles.h (struct objstats) <n_minsyms>: Move...
(struct objfile_per_bfd_storage) <n_minsyms>: ... here.
* symmisc.c (print_objfile_statistics): Update.
This is just a simple refactoring in elfread.c to split out the
minsym-reading code into its own function.
2014-02-26 Tom Tromey <tromey@redhat.com>
* elfread.c (elf_read_minimal_symbols): New function, from
elf_symfile_read.
(elf_symfile_read): Call it.
Now that minimal symbols are independent of the program space, we can
move them to the per-BFD object. This lets us save memory in the
multi-inferior case; and, once the symbol readers are updated, time.
The other prerequisite for this move is that all the objects referred
to by the minimal symbols have a lifetime at least as long as the
per-BFD object. I think this is satisfied partially by this patch
(moving the copied names there) and partially by earlier patches
moving the demangled name hash.
This patch contains a bit of logic to avoid creating new minimal
symbols if they have already been read for a given BFD. This allows
us to avoid trying to update all the symbol readers for this
condition. At first glance this may seem like a hack, but some symbol
readers mix psym and minsym reading, and would require logic just like
this regardless -- and it is simpler and less error-prone to just do
the work in a central spot.
2014-02-26 Tom Tromey <tromey@redhat.com>
* minsyms.c (lookup_minimal_symbol, iterate_over_minimal_symbols)
(lookup_minimal_symbol_text, lookup_minimal_symbol_by_pc_name)
(lookup_minimal_symbol_solib_trampoline)
(lookup_minimal_symbol_by_pc_section_1)
(lookup_minimal_symbol_and_objfile): Update.
(prim_record_minimal_symbol_full): Use the per-BFD obstack.
Don't allocate a minimal symbol if minsyms have already been read.
(build_minimal_symbol_hash_tables): Update.
(install_minimal_symbols): Do nothing if minsyms already read.
Use the per-BFD obstack.
(terminate_minimal_symbol_table): Use the per-BFD obstack.
* objfiles.c (allocate_objfile): Call
terminate_minimal_symbol_table later.
(have_minimal_symbols): Update.
* objfiles.h (struct objfile_per_bfd_storage) <msymbols,
minimal_symbol_count, msymbol_hash, msymbol_demangled_hash>:
Move from struct objfile.
<minsyms_read>: New field.
(struct objfile) <msymbols, minimal_symbol_count,
msymbol_hash, msymbol_demangled_hash>: Move.
(ALL_OBJFILE_MSYMBOLS): Update.
* symfile.c (read_symbols): Set minsyms_read.
(reread_symbols): Update.
* symmisc.c (dump_objfile, dump_msymbols): Update.
This removes the runtime offsets from minsyms. Instead, these offsets
will now be applied whenever the minsym's address is computed.
This patch redefines MSYMBOL_VALUE_ADDRESS to actually use the offsets
from the given objfile. Then, it updates all the symbol readers,
changing them so that they do not add in the section offset when
creating the symbol.
This change also lets us remove relocation of minsyms from
objfile_relocate1 and also msymbols_sort.
2014-02-26 Tom Tromey <tromey@redhat.com>
* minsyms.c (msymbols_sort): Remove.
* minsyms.h (msymbols_sort): Remove.
* objfiles.c (objfile_relocate1): Don't relocate minsyms.
* symtab.h (MSYMBOL_VALUE_ADDRESS): Use objfile offsets.
* elfread.c (elf_symtab_read): Don't add section offsets.
* xcoffread.c (record_minimal_symbol): Don't add section offset
to minimal symbol address.
* somread.c (text_offset, data_offset): Remove.
(som_symtab_read): Don't add section offsets to minimal symbol
addresses.
* coff-pe-read.c (add_pe_forwarded_sym, read_pe_exported_syms):
Don't add section offsets to minimal symbols.
* coffread.c (coff_symtab_read): Don't add section offsets
to minimal symbol addresses.
* machoread.c (macho_symtab_add_minsym): Don't add section offset
to minimal symbol addresses.
* mipsread.c (read_alphacoff_dynamic_symtab): Don't add
section offset to minimal symbol addresses.
* mdebugread.c (parse_partial_symbols): Don't add section
offset to minimal symbol addresses.
* dbxread.c (read_dbx_dynamic_symtab): Don't add section
offset to minimal symbol addresses.
This changes MSYMBOL_VALUE_ADDRESS to be an rvalue. In a later patch
we change this macro to compute its value; this patch introduces a
setter to make the break a bit cleaner.
2014-02-26 Tom Tromey <tromey@redhat.com>
* minsyms.c (prim_record_minimal_symbol_full): Use
SET_MSYMBOL_VALUE_ADDRESS.
* objfiles.c (objfile_relocate1): Use SET_MSYMBOL_VALUE_ADDRESS.
* sh64-tdep.c (sh64_elf_make_msymbol_special): Use
SET_MSYMBOL_VALUE_ADDRESS.
* symtab.h (MSYMBOL_VALUE_ADDRESS): Expand to an rvalue.
(SET_MSYMBOL_VALUE_ADDRESS): New macro.
This introduces minimal_symbol_upper_bound and changes various bits of
code to use it. Since this function is intimately tied to the
implementation of minimal symbol tables, I believe it belongs in
minsyms.c.
The new function is extracted from find_pc_partial_function_gnu_ifunc.
This isn't a "clean" move because the old function interleaved the
caching and the computation; but this doesn't make sense for the new
code.
2014-02-26 Tom Tromey <tromey@redhat.com>
* blockframe.c (find_pc_partial_function_gnu_ifunc): Use
bound minimal symbols. Move code that knows about minsym
table layout...
* minsyms.c (minimal_symbol_upper_bound): ... here. New
function.
* minsyms.h (minimal_symbol_upper_bound): Declare.
* objc-lang.c (find_objc_msgsend): Use bound minimal symbols,
minimal_symbol_upper_bound.
Consider the following type for which we would like to provide
a pretty-printer and manage it via RegexpCollectionPrettyPrinter:
typedef long time_t;
Currently, this does not work because this framework only considers
the type's tag name:
typename = gdb.types.get_basic_type(val.type).tag
if not typename:
return None
This patch extends it to use the type's name if the basic type
does not have a tag name, thus allowing the framework to also
work with typedefs like the above.
gdb/ChangeLog:
* python/lib/gdb/printing.py (RegexpCollectionPrettyPrinter):
Use the type's name if its basic type does not have a tag.
gdb/testsuite/ChangeLog:
* testsuite/gdb.python/py-pp-re-notag.c: New file.
* testsuite/gdb.python/py-pp-re-notag.ex: New file.
* testsuite/gdb.python/py-pp-re-notag.p: New file.
This comment explains why we sometimes sign-extend the range type
bounds when we normally shouldn't have to.
gdb/ChangeLog:
* dwarf2read.c (read_subrange_type): Add comment.
Consider the following Ada code:
-- An array whose index is an enumeration type with 128 enumerators.
type Enum_T is (Enum_000, Enum_001, [...], Enum_128);
type Table is array (Enum_T) of Boolean;
When the compiler is configured to generate pure DWARF debugging info,
trying to print type Table's description yields:
ptype pck.table
type = array (enum_000 .. -128) of boolean
The expected output was:
ptype pck.table
type = array (enum_000 .. enum_128) of boolean
The DWARF debugging info for our array looks like this:
<1><44>: Abbrev Number: 5 (DW_TAG_array_type)
<45> DW_AT_name : pck__table
<50> DW_AT_type : <0x28>
<2><54>: Abbrev Number: 6 (DW_TAG_subrange_type)
<55> DW_AT_type : <0x5c>
<59> DW_AT_lower_bound : 0
<5a> DW_AT_upper_bound : 128
The array index type is, by construction with the DWARF standard,
a subrange of our enumeration type, defined as follow:
<2><5b>: Abbrev Number: 0
<1><5c>: Abbrev Number: 7 (DW_TAG_enumeration_type)
<5d> DW_AT_name : pck__enum_t
<69> DW_AT_byte_size : 1
<2><6b>: Abbrev Number: 8 (DW_TAG_enumerator)
<6c> DW_AT_name : pck__enum_000
<7a> DW_AT_const_value : 0
[etc]
Therefore, while processing these DIEs, the array index type ends
up being a TYPE_CODE_RANGE whose target type is our enumeration type.
But the problem is that we read the upper bound as a negative value
(-128), which is then used as is by the type printer to print the
array upper bound. This negative value explains the "-128" in the
output.
To understand why the range type's upper bound is read as a negative
value, one needs to look at how it is determined, in read_subrange_type:
orig_base_type = die_type (die, cu);
base_type = check_typedef (orig_base_type);
[... high is first correctly read as 128, but then ...]
if (!TYPE_UNSIGNED (base_type) && (high & negative_mask))
high |= negative_mask;
The negative_mask is applied, here, because BASE_TYPE->FLAG_UNSIGNED
is not set. And the reason for that is because the base_type was only
partially constructed during the call to die_type. While the enum
is constructed on the fly by read_enumeration_type, its flag_unsigned
flag is only set later on, while creating the symbols corresponding to
the enum type's enumerators (see process_enumeration_scope), after
we've already finished creating our range type - and therefore too
late.
My first naive attempt at fixing this problem consisted in extracting
the part in process_enumeration_scope which processes all enumerators,
to generate the associated symbols, but more importantly set the type's
various flags when necessary. However, this does not always work well,
because we're still in the subrange_type's scope, and it might be
different from the scope where the enumeration type is defined.
So, instead, what this patch does to fix the issue is to extract
from process_enumeration_scope the part that determines whether
the enumeration type should have the flag_unsigned and/or the
flag_flag_enum flags set. It turns out that, aside from the code
implementing the loop, this part is fairly independent of the symbol
creation. With that part extracted, we can then use it at the end
of our enumeration type creation, to produce a type which should now
no longer need any adjustment.
Once the enumeration type produced is correctly marked as unsigned,
the subrange type's upper bound is then correctly read as an unsigned
value, therefore giving us an upper bound of 128 instead of -128.
gdb/ChangeLog:
* dwarf2read.c (update_enumeration_type_from_children): New
function, mostly extracted from process_structure_scope.
(read_enumeration_type): Call update_enumeration_type_from_children.
(process_enumeration_scope): Do not set THIS_TYPE's flag_unsigned
and flag_flag_enum fields.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/arr-subrange.c, gdb.dwarf2/arr-subrange.exp: New files.
Whatever the comment about deprecated_xfer_memory referred to,
deprecated_xfer_memory is gone now. There's no need to install a
target method that just delegates, as that's what the default
delegator does already.
Tested by building an --enable-targets=all gdb on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* bsd-uthread.c (bsd_uthread_xfer_partial): Delete function.
(bsd_uthread_target): Don't install bsd_uthread_xfer_partial as
to_xfer_partial method.
As no target uses it anymore, it can finally go away.
After removing the deprecated_xfer_memory handling from
default_xfer_partial, we can delete the latter, because the only thing
it does is delegate to the target beneath unconditionally, which is
what the delegator installed by target-delegates.c will do for us if
no to_xfer_partial method is installed.
This was the last user of de_fault, so that goes away too.
Tested on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* target.c (complete_target_initialization): Don't install
default_xfer_partial as to_xfer_partial hook.
(nomemory): Delete.
(update_current_target): Don't INHERIT nor de_fault
deprecated_xfer_memory. Delete de_fault macro.
(default_xfer_partial, deprecated_debug_xfer_memory): Delete.
(setup_target_debug): Don't install a deprecated_xfer_memory hook.
* target.h (struct target_ops) <deprecated_xfer_memory>: Delete
field.
This removes yet another instance of a deprecated_xfer_memory user.
Unfortunately djgpp's write_child function takes a non-const buffer
pointer, while GDB's xfer_partial api passes a const pointer. To be
const-correct, we need to copy that buffer to a non-const buffer, and
pass the copy to write_child. This is actually what
target.c:default_xfer_partial itself does, when calling into the
ops->deprecated_xfer_memory hook.
Tested by cross-building djgpp gdb, on x86-64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* go32-nat.c (my_write_child): New function.
(go32_xfer_memory): Rewrite as to_xfer_partial helper.
(go32_xfer_partial): New function.
(init_go32_ops): Don't install a deprecated_xfer_memory hook.
Instead install a to_xfer_partial hook.
This removes yet another instance of a deprecated_xfer_memory user.
Completely untested.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* nto-procfs.c (procfs_xfer_memory): Adjust interface as a
to_xfer_partial helper. Rewrite.
(procfs_xfer_partial): New function.
(init_procfs_ops): Don't install a deprecated_xfer_memory hook.
Install a to_xfer_partial hook.
This removes yet another instance of a deprecated_xfer_memory user.
Tested by building a --enable-targets=all gdb, on x86-64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* remote-m32r-sdi.c (send_data): Constify 'buf' parameter.
(m32r_xfer_memory): Adjust as a to_xfer_partial helper.
(m32r_xfer_partial): New function.
(init_m32r_ops): Don't install a deprecated_xfer_memory hook.
Install a to_xfer_partial hook.
This removes another yet instance of a deprecated_xfer_memory user.
Tested by building a --enable-targets=all gdb, on x86-64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* remote-mips.c (mips_xfer_memory): Adjust as to_xfer_partial
helper.
(mips_xfer_partial): New function.
(_initialize_remote_mips): Don't install a deprecated_xfer_memory
hook. Install a to_xfer_partial hook.
Consider the following declarations in Ada...
type Item is range -32 .. 31;
for Item'Size use 6;
type Table is array (Natural range 0 .. 4) of Item;
pragma Pack (Table);
... which declare a packed array whose elements are 6 bits long.
The debugger currently does not notice that the array is packed,
and thus prints values of this type incorrectly. This can be seen
in the "ptype" output:
(gdb) ptype table
type = array (0 .. 4) of foo.item
Normally, the debugger should print:
(gdb) ptype table
type = array (0 .. 4) of foo.item <packed: 6-bit elements>
The debugging information for this array looks like this:
.uleb128 0xf # (DIE (0x15c) DW_TAG_array_type)
.long .LASF9 # DW_AT_name: "pck__table"
.byte 0x6 # DW_AT_bit_stride
.long 0x1a9 # DW_AT_type
.uleb128 0x10 # (DIE (0x16a) DW_TAG_subrange_type)
.long 0x3b # DW_AT_type
.byte 0 # DW_AT_lower_bound
.byte 0x4 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x15c
The interesting part is the DW_AT_bit_stride attribute, which tells
the size of the array elements is 6 bits, rather than the normal
element type's size.
This patch adds support for this attribute by first creating
gdbtypes.c::create_array_type_with_stride, which is an enhanced
version of create_array_type taking an extra parameter as the stride.
The old create_array_type can then be re-implemented very simply
by calling the new create_array_type_with_stride.
We can then use this new function from dwarf2read, to create
arrays with or without stride.
gdb/ChangeLog:
* gdbtypes.h (create_array_type_with_stride): Add declaration.
* gdbtypes.c (create_array_type_with_stride): New function,
renaming create_array_type, but with an added parameter
called "bit_stride".
(create_array_type): Re-implement using
create_array_type_with_stride.
* dwarf2read.c (read_array_type): Add support for DW_AT_byte_stride
and DW_AT_bit_stride attributes.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/arr-stride.c: New file.
* gdb.dwarf2/arr-stride.exp: New file.
The test, relying purely on generating an assembly file, only
verifies the type description of our array. But I was also
able to verify manually that the debugger print values of these
types correctly as well (which was not the case prior to this
patch).
With the test changed as in the patch, against current mainline, we get:
(gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
break break_me task 1
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
break break_me task 3
Note: breakpoint 2 also set at pc 0x4030b0.
Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7dc7700 (LWP 27133)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 3 main_task
2 63bd80 1 48 Accept or Select Term task_list(1)
* 3 63f510 1 48 Accepting RV with 1 task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint
The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.
The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check. This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
}
IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly. Put another task-specific or
non-task-specific breakpoint there, and things break.
A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint. IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:
break break_me task 3
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7fcb700 (LWP 17122)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 2 main_task
* 2 63bd80 1 48 Accepting RV with 1 task_list(1)
3 63f510 1 48 Accept or Select Term task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
It was after seeing this that I thought of how to expose the bug with
current mainline.
Tested on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
task-specific breakpoints.
gdb/testsuite/
2014-02-26 Pedro Alves <palves@redhat.com>
* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
that won't ever trigger. Make sure that GDB reports the correct
breakpoint that caused the stop.
[description of this patch and ChangeLog entry by Joel Brobecker]
The recent implementation was questionable, and if it worked, it was
only by chance because the requested length is large enough that only
one read was sufficient. Note that the implementation before that
also made that assumption, in the form of only handling
TARGET_OBJECT_UNWIND_TABLE xfer requests when offset was zero.
gdb/ChangeLog:
* ia64-linux-nat.c (ia64_linux_xfer_partial): Reimplement
handling of object == TARGET_OBJECT_UNWIND_TABLE.
This removes target_ignore, which isn't used any more.
2014-02-25 Tom Tromey <tromey@redhat.com>
* target.h (target_ignore): Don't declare.
* target.c (target_ignore): Remove.
Fix auto-load 7.7 regression,
the regression affects any loading from /usr/share/gdb/auto-load .
5b2bf9471f is the first bad commit
commit 5b2bf9471f
Author: Doug Evans <xdje42@gmail.com>
Date: Fri Nov 29 21:29:26 2013 -0800
Move .debug_gdb_script processing to auto-load.c.
Simplify handling of auto-loaded objfile scripts.
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.
Message-ID: <20140223212400.GA8831@host2.jankratochvil.net>
ia64-linux-nat.c no longer compiles because ia64_linux_xfer_partial
no longer matches the to_xfer_partial prototype. This patch fixes
the problem by adjusting it accordingly.
gdb/ChangeLog:
* ia64-linux-nat.c (ia64_linux_xfer_partial): Add function
documentation. Adjust prototype to match the target_ops
to_xfer_partial method. Adjust implementation accordingly.
This patch changes rl78-tdep.c so that a 16-bit type is used for
register pairs instead of a pointer type as was previously the case.
This will cause these register pairs to be displayed as integers
instead of as a data address with a 0xf0000 ORed in.
E.g. registers ax, bc, de, and hl might now be displayed like this:
(gdb) info registers ax bc de hl
ax 0x6 6
bc 0x0 0
de 0x10c3 4291
hl 0x108d 423
Whereas, before, they were displayed as follows:
(gdb) info registers ax bc de hl
ax 0xf0006 0xf0006
bc 0xf0000 0xf0000
de 0xf10c3 0xf10c3
hl 0xf108d 0xf108d
These pairs are 16 bit quantities and should be displayed as such.
This change also affects the way that the banked register pairs are
displayed. Within GDB, the banked register pairs are named bank0_rp0,
bank0_rp1, .., bank3_rp2, bank3_rp3.
However, these register pairs need to be used as addresses in DWARF
expressions. I have added 16 pseudo registers corresponding to banked
register pairs. These new pseudo registers are all hidden from the
user and have a pointer type. Values from these registers are
intended to be used in DWARF expressions. Therefore,
rl78_dwarf_reg_to_regnum() has been adjusted to return these new
pseudo register numbers.
I had a much simpler patch which only changed the types, but it showed
a number of regressions due to integer values from the banked register
pairs being used as part of an address expression. This current patch
shows no regressions and now displays values of register pairs
correctly.
* rl78-tdep.c ( RL78_BANK0_RP0_PTR_REGNUM, RL78_BANK0_RP1_PTR_REGNUM)
(RL78_BANK0_RP2_PTR_REGNUM, RL78_BANK0_RP3_PTR_REGNUM)
(RL78_BANK1_RP0_PTR_REGNUM, RL78_BANK1_RP1_PTR_REGNUM)
(RL78_BANK1_RP2_PTR_REGNUM, RL78_BANK1_RP3_PTR_REGNUM)
(RL78_BANK2_RP0_PTR_REGNUM, RL78_BANK2_RP1_PTR_REGNUM)
(RL78_BANK2_RP2_PTR_REGNUM, RL78_BANK2_RP3_PTR_REGNUM)
(RL78_BANK3_RP0_PTR_REGNUM, RL78_BANK3_RP1_PTR_REGNUM)
(RL78_BANK3_RP2_PTR_REGNUM, RL78_BANK3_RP3_PTR_REGNUM):
New constants.
(rl78_register_type): Use a data pointer type for SP and
new pseudo registers mentioned above. Use a 16 bit integer
type for all other register pairs.
(rl78_register_name, rl78_g10_register_name): Update for
new pseudo registers.
(rl78_pseudo_register_read): Likewise.
(rl78_pseudo_register_write): Likewise.
(rl78_dwarf_reg_to_regnum): Return register numbers representing
to the newly added pseudo registers.
This removes yet another instance of a deprecated_xfer_memory user,
and fixes a nasty regression as a side-effect:
(gdb) start
Temporary breakpoint 1 at 0x19070: file simple_main.adb, line 4.
Starting program: /[...]/simple_main
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x19070
Cannot insert breakpoint -3.
Temporarily disabling shared library breakpoints:
breakpoint #-3
The regression was introduced by the to_xfer_partial transition
to return a status enum. procfs_xfer_partial was updated but
not the case where object is TARGET_OBJECT_MEMORY. As result,
procfs_xfer_partial was returning the length xfered rather than
the status, and the xfered buffer was left uninitialized.
gdb/
2014-02-19 Pedro Alves <palves@redhat.com>
* procfs.c (procfs_target): Don't install procfs_xfer_memory as
deprecated_xfer_memory hook.
(procfs_xfer_partial): Call procfs_xfer_memory instead
of the deprecated_xfer_memory target hook.
(procfs_xfer_memory): Adjust interface as a to_xfer_partial
helper.
A GDB internal error is found on native mingw32 target.
(gdb) run
../../binutils-gdb/gdb/target.c:1483: internal-error:
target_xfer_partial: Assertion `*xfered_len > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This error was introduced by the following snippet in commit
9b409511d0
> @@ -2536,27 +2538,30 @@ windows_xfer_shared_libraries (struct target_ops *ops,
> }
>
> obstack_free (&obstack, NULL);
> - return len;
> + *xfered_len = (ULONGEST) len;
> + return TARGET_XFER_OK;
> }
In the original code, len is returned, which could be 0, but after that
commit, only TARGET_XFER_OK is returned, which is wrong. If len is 0,
TARGET_XFER_EOF should be returned. (it is 0 in enum
target_xfer_status declaration).
gdb:
2014-02-24 Yuanhui Zhang <asmwarrior@gmail.com>
* windows-nat.c (windows_xfer_shared_libraries): Return
TARGET_XFER_EOF if LEN is zero to fix an assert failure when
requested object is TARGET_OBJECT_LIBRARIES.
Nowadays, TARGET_XFER_E_UNAVAILABLE isn't regarded as an error in
to_xfer_partial interface, so _E_ looks odd. This patch is to
replace TARGET_XFER_E_UNAVAILABLE with TARGET_XFER_UNAVAILABLE,
and change its value from -2 to 2. Since there is no comparison
on the value of 'enum target_xfer_status', so it should be safe.
gdb:
2014-02-24 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_status)
<TARGET_XFER_E_UNAVAILABLE>: Rename it to ...
<TARGET_XFER_UNAVAILABLE>: ... it with setting value 2
explicitly. New.
* corefile.c (memory_error_message): User updated.
* exec.c (section_table_read_available_memory): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* target.c (target_xfer_status_to_string): Likewise.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1, target_xfer_partial): Likewise.
* valops.c (read_value_memory): Likewise.
* exec.h: Update comments.
This patch tweaks target_xfer_status_to_string on comments and argument
name.
gdb:
2014-02-24 Yao Qi <yao@codesourcery.com>
* target.c (target_xfer_status_to_string): Rename argument err
to status.
* target.h (target_xfer_status_to_string): Update declaration.
Replace target_xfer_error_to_string with
target_xfer_status_to_string in comment.
When I build mips native gdb today, I get the follow error,
../../../git/gdb/mips-linux-nat.c: In function '_initialize_mips_linux_nat':
../../../git/gdb/mips-linux-nat.c:792:15: error: assignment from incompatible pointer type [-Werror]
cc1: all warnings being treated as errors
It looks an oversight of recent target_ops delegation patches. This
patch is to fix the build error.
gdb:
2014-02-24 Yao Qi <yao@codesourcery.com>
* mips-linux-nat.c (super_close): Update its type.
(mips_linux_close): Pass 'self' to super_close.
This patch removes macro TARGET_XFER_STATUS_ERROR_P, as Pedro pointed
out during patches review that TARGET_XFER_STATUS_ERROR_P tends to
be unnecessary.
gdb:
2014-02-24 Yao Qi <yao@codesourcery.com>
* target.h (TARGET_XFER_STATUS_ERROR_P): Remove.
* corefile.c (read_memory): Adjusted.
* target.c (target_write_with_progress): Adjusted.
As we migrate to the new to_xfer_partial interface, some of previous
tweaks become unnecessary, we don't have to check traceframe is
selected in each target implementation, so this patch below is
reverted.
[PATCH] Send qXfer:traceframe-info:read when traceframe is selected.
https://sourceware.org/ml/gdb-patches/2013-10/msg00752.html
Third, to_traceframe_info is only called when traceframe is selected,
that means it is only called when target is remote, tfile or ctf, so
this patch can be partially reverted,
https://sourceware.org/ml/gdb-patches/2013-04/msg00000.html
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
Revert two patches:
2013-10-25 Yao Qi <yao@codesourcery.com>
* remote.c (remote_traceframe_info): Return early if
traceframe is not selected.
2013-07-19 Yao Qi <yao@codesourcery.com>
* target.c (update_current_target): Change the default action
of 'to_traceframe_info' from tcomplain to return_zero.
* target.h (struct target_ops) <to_traceframe_info>: Add more
comments.
As the new to_xfer_partial implementations are done in ctf and tfile
targets, read_value_memory can be simplified a lot. Call
target_xfer_partial in a loop, check return value, and set bytes
unavailable when necessary.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* valops.c (read_value_memory): Rewrite it. Call
target_xfer_partial in a loop.
* exec.h (section_table_available_memory): Remove declaration.
Move comments to ...
* exec.c (section_table_available_memory): ... here. Make it static.
This patch adjust both ctf and tfile target implementation of to_xfer_partial,
to return TARGET_XFER_E_UNAVAILABLE and set *XFERED_LEN if data is
unavailable. Note that some code on xfer in exec.c can be shared, but
we can do it in a separate pass later.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* exec.c (section_table_read_available_memory): New function.
* exec.h (section_table_read_available_memory): Declare.
* ctf.c (ctf_xfer_partial): Call
section_table_read_available_memory.
* tracefile-tfile.c (tfile_xfer_partial): Likewise.
In the to_xfer_partial implementations of ctf and tfile, the code on
reading from read-only sections is duplicated. This patch moves it to
a separate function exec_read_partial_read_only.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* ctf.c (ctf_xfer_partial): Move code to ...
* exec.c (exec_read_partial_read_only): ... it. New function.
* tracefile-tfile.c (tfile_xfer_partial): Likewise.
* tracefile.c: Include "exec.h".
* exec.h (exec_read_partial_read_only): Declare.
At present, tfile target thinks it has memory but ctf doesn't.
This is an oversight when I added ctf target support. This patch
moves the implementations of to_has_all_memory and to_has_memory to
upper layer. After this change, both tfile and ctf target think
they have memory.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* tracefile-tfile.c (tfile_has_all_memory): Remove.
(tfile_has_memory): Remove.
(init_tfile_ops): Don't set fields to_has_all_memory and
to_has_memory of tfile_ops.
* tracefile.c (tracefile_has_all_memory): New function.
(tracefile_has_memory): New function.
(init_tracefile_ops): Initialize fields to_has_all_memory and
to_has_memory of 'ops'.
This patch move the duplicated code between tfile and ctf
targets into file tracefile.c. The common part of target_ops
fields are set in init_tracefile_ops.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* ctf.c (ctf_has_stack, ctf_has_registers): Remove.
(ctf_thread_alive, ctf_get_trace_status): Remove.
(init_ctf_ops): Don't set some fields of ctf_ops. Call
init_tracefile_ops.
* tracefile-tfile.c (tfile_get_trace_status): Remove.
(tfile_has_stack, tfile_has_registers): Remove.
(tfile_thread_alive): Remove.
(init_tfile_ops): Don't set some fields of tfile_ops. Call
init_tracefile_ops.
* tracefile.c (tracefile_has_stack): New function.
(tracefile_has_registers): New function.
(tracefile_thread_alive): New function.
(tracefile_get_trace_status): New function.
(init_tracefile_ops): New function.
* tracefile.h (init_tracefile_ops): Declare.
This patch is a refactor which moves trace file writer related code
out of tracepoint.c, which has 6k LOC. It moves general trace file
writer to a new file tracefile.c and moves tfile specific writer to
tracefile-tfile.c.
gdb:
2014-02-23 Yao Qi <yao@codesourcery.com>
* Makefile.in (REMOTE_OBS): Append tracefile.o and
tracefile-tfile.o.
(HFILES_NO_SRCDIR): Add tracefile.h.
* ctf.c: Include "tracefile.h".
* tracefile.h: New file.
* tracefile.c: New file
* tracefile-tfile.c: New file.
* tracepoint.c: Include "tracefile.h".
(free_uploaded_tps, free_uploaded_tsvs): Remove declarations.
(stop_reason_names): Add const.
(trace_file_writer_xfree): Move it to tracefile.c.
(trace_save, trace_save_command, trace_save_tfile): Likewise.
(trace_save_ctf): Likewise.
(struct tfile_trace_file_writer): Move it to tracefile-tfile.c.
(tfile_target_save, tfile_dtor, tfile_start): Likewise.
(tfile_write_header, tfile_write_regblock_type): Likewise.
(tfile_write_status, tfile_write_uploaded_tsv): Likewise.
(tfile_write_uploaded_tp, tfile_write_definition_end): Likewise.
(tfile_write_raw_data, tfile_end): Likewise.
(tfile_trace_file_writer_new): Likewise.
(free_uploaded_tp): Make it extern.
(free_uploaded_tsv): Make it extern.
(_initialize_tracepoint): Move code to register command 'tsave'
to tracefile.c.
* tracepoint.h (stop_reason_names): Declare.
(struct trace_frame_write_ops): Move it to tracefile.h.
(struct trace_file_write_ops): Likewise.
(struct trace_file_writer): Likewise.
(free_uploaded_tsvs, free_uploaded_tps): Declare.
info os processes -fsanitize=address error
https://sourceware.org/bugzilla/show_bug.cgi?id=16594
info os processes
=================================================================
==5795== ERROR: AddressSanitizer: heap-use-after-free on address
0x600600214974 at pc 0x757a92 bp 0x7fff95dd9f00 sp 0x7fff95dd9ef0
READ of size 4 at 0x600600214974 thread T0
#0 0x757a91 in get_cores_used_by_process (.../gdb/gdb+0x757a91)
At least Fedora 20 has process(es):
6678 ? Ss 0:00 /usr/lib/systemd/systemd --user
6680 ? S 0:00 \_ (sd-pam)
and GDB "info os processes" crashes on it as /proc/6680/stat contains:
6680 ((sd-pam)) S 6678 6678 6678 0 -1 1077961024 33 0 0 0 0 0 0 0 20 0 1 0 18568 73768960 120 18446744073709551615 1 1
0 0 0 0 0 4096 0 18446744073709551615 0 0 17 6 0 0 0 0 0 0 0 0 0 0 0 0 0
and GDB fails to find the proper end of the process name "((sd-pam))".
Therefore it reads core number off-by-one (it reads 17 instead of 6) and
overruns the array.
(1) Make the process name parsing more foolproof.
(2) Do not trust the parsed number from /proc/PID/stat and verify it against
the array size.
I noticed that 'ps' gets this right, so I've peeked at its
sources, and it just looks for the first ')' starting at
the end.
dc072aced7:proc/readproc.c
Look for stat2proc.
Given ps does that, I believe the kernel won't ever be changed
in a way that would break it. So it sounds like could do strrchr
from the end of stat just as well without worry, which is simpler.
gdb/
2014-02-21 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16594
* common/linux-osdata.c (linux_common_core_of_thread): Find the end of
process name.
(get_cores_used_by_process): New parameter num_cores, use it.
(linux_xfer_osdata_processes): Pass num_cores to it.
* linux-tdep.c (linux_info_proc, linux_fill_prpsinfo): Find the end of
process name.
Message-ID: <20140217212826.GA15080@host2.jankratochvil.net>
The patch "return target_xfer_status in to_xfer_partial" caused a
regression in various s390(x) test cases, because memory_xfer_partial
filled only the first byte of the read buffer from a breakpoint shadow:
https://sourceware.org/ml/gdb-patches/2014-01/msg01071.html
This patch fixes the regression.
This is the continuation of what Joel proposed on:
<https://sourceware.org/ml/gdb-patches/2013-12/msg00977.html>
Now that I have already submitted and pushed the patch to split
i386_stap_parse_special_token into two smaller functions, it is indeed
simpler to understand this patch.
It occurs because, on x86, triplet displacement operands are allowed
(like "-4+8-20(%rbp)"), and the current parser for this expression is
buggy. It does not correctly extract the register name from the
expression, which leads to incorrect evaluation. The parser was also
being very "generous" with the expression, so I included a few more
checks to ensure that we're indeed dealing with a triplet displacement
operand.
This patch also includes testcases for the two different kind of
expressions that can be encountered on x86: the triplet displacement
(explained above) and the three-argument displacement (as in
"(%rbx,%ebx,-8)"). The tests are obviously arch-dependent and are
placed under gdb.arch/.
Message-ID: <m3mwj1j12v.fsf@redhat.com>
URL: <https://sourceware.org/ml/gdb-patches/2014-01/msg00310.html>
gdb/
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* i386-tdep.c (i386_stap_parse_special_token_triplet): Check if a
number comes after the + or - signs. Adjust length of register
name to be extracted.
gdb/testsuite/
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* gdb.arch/amd64-stap-special-operands.exp: New file.
* gdb.arch/amd64-stap-three-arg-disp.S: Likewise.
* gdb.arch/amd64-stap-three-arg-disp.c: Likewise.
* gdb.arch/amd64-stap-triplet.S: Likewise.
* gdb.arch/amd64-stap-triplet.c: Likewise.
The AIX linker pointed out that gdb had multiple definitions of the
various *_varobj_ops objects. This patch fixes the problem by marking
the declarations as "extern" in varobj.h. Tested by rebuilding on
x86-64 Fedora 18 and on AIX.
2014-02-20 Tom Tromey <tromey@redhat.com>
* varobj.h (c_varobj_ops, cplus_varobj_ops, java_varobj_ops)
(ada_varobj_ops): Mark "extern".
I happened to notice that last_o_file_start is write-only in
read_dbx_symtab. This patch removes it. Tested by rebuilding.
2014-02-20 Tom Tromey <tromey@redhat.com>
* dbxread.c (read_dbx_symtab): Remove last_o_file_start.
* dwarf2read.c (struct die_info): New member in_process.
(reset_die_in_process): New function.
(process_die): Set it at the start, reset when returning.
(inherit_abstract_dies): Only call process_die if origin_child_die
not already being processed.
testsuite/
* gdb.dwarf2/dw2-icycle.S: New file.
* gdb.dwarf2/dw2-icycle.c: New file.
* gdb.dwarf2/dw2-icycle.exp: New file.
This patch brings back a comment that got stripped down a bit too much
during a recent change.
gdb/ChangeLog:
* windows-nat.c (handle_unload_dll): Add function documentation.
(do_initial_windows_stuff): Add comment explaining why we wait
until after inferior initialization has finished before
processing all DLLs.
Now that get_module_name is no longer called for handling DLL events,
we can simplify it a bit, knowing that the only use is to get the
executable's filename.
While doing so, we adjusted the implementation a bit to avoid
references to DLLs, renamed it to make its more-targeted usage
more explicit, moved it right before the only function that uses it.
We also remove the use of hard-coded length for the buffers being
used.
gdb/ChangeLog:
* windows-nat.c (get_module_name): Delete.
(windows_get_exec_module_filename): New function, mostly
inspired from get_module_name.
(windows_pid_to_exec_file): Replace call to get_module_name
by call to windows_get_exec_module_filename.
When a DLL gets loaded an the debugger gets a debug event about it,
the currently implementation in handle_load_dll currently tries to
fetch the DLL's name by first iterating over all DLLs known to
the system. It should be sufficient to rely on the name provided
with the event, however, especially in the situation we are now,
where we now know that we're past the statup phase for our inferior.
This patch therefore simplifies windows-nat.c::handle_load_dll to
only rely on the event's lpImageName.
It also updates the function's comment to document the assumption
regarding not being during the inferior's startup phase. And while
at it, it fixes the function documentation, which was probably
unintentionally inherited from another function (perhaps windows_wait).
gdb/ChangeLog:
* windows-nat.c (handle_load_dll): Rewrite this function's
introductory comment. Remove code using get_module_name
to get the DLL's name.
This patch aims at simplifying DLL handling during the inferior
initialization (process creation during the "run", or during an
"attach"). Instead of processing each DLL load event, which is
sometimes incomplete, we ignore these events until the inferior
has completed its startup phase, and then just iterate over all
DLLs via EnumProcessModules.
gdb/ChangeLog:
* windows-nat.c (get_windows_debug_event): Ignore
LOAD_DLL_DEBUG_EVENT and UNLOAD_DLL_DEBUG_EVENT
if windows_initialization_done == 0.
(windows_add_all_dlls): Renames windows_ensure_ntdll_loaded.
Adjust implementation to always load all DLLs.
(do_initial_windows_stuff): Replace call to
windows_ensure_ntdll_loaded by call to windows_add_all_dlls.
The "dll-symbols" command, specific to native Windows platforms,
gives the impression that the symbols were not loaded, first
because it completes silently, and second because the "info shared"
output does not get updated after the command completes:
(gdb) dll-symbols C:\WINDOWS\syswow64\rpcrt4.dll
(gdb) info shared
From To Syms Read Shared Object Library
[...]
0x77e51000 0x77ee2554 No C:\WINDOWS\system32\rpcrt4.dll
(we exected the "Syms Read" column to read "Yes").
As far as I can tell, the symbols actually do get loaded, but completely
independently from the solib framework, which explains the silent
loading and the fact that the "Syms Read" column does not get updated.
See windows-nat.c::safe_symbol_file_add_stub, which calls symbol_file_add
instead of calling solib_add.
But, aside from the fact that the "Syms Read" status does not get
updated, I also noticed that it does not take into account the DLL's
actual load address when loading its symbols. As a result, I believe
that we get it wrong if the DLL does not get loaded at the prefered
address.
Rather than trying to fix this command, there does not seem to be
a reason other than historical for having Windows-specific commands
which essentially re-implements the "sharedlibrary" command. The
command interface is slightly different (the latter takes a regexp
rather than a plain filename), but it should be just as easy to use
the "sharedlibrary" command, or its "share" alias, as usisng the
"dll-symbols" command. For instance:
(gdb) share rpcrt4.dll
Reading symbols from C:\WINDOWS\system32\rpcrt4.dll...(no debugging symbols found)...done.
Loaded symbols for C:\WINDOWS\system32\rpcrt4.dll
(gdb) info shared
From To Syms Read Shared Object Library
[...]
0x77e51000 0x77ee2554 Yes (*) C:\WINDOWS\system32\rpcrt4.dll
This patch therefore deprecates the "dll-symbols" command, as well
as its two aliases "add-shared-symbol-files" and "assf", with a view
of deleting them as soon as the 7.8 branch gets cut.
gdb/ChangeLog:
* windows-nat.c (_initialize_windows_nat): Deprecate the
"dll-symbols" command. Turn the "add-shared-symbol-files"
and "assf" aliases into commands, and deprecate them as well.
* NEWS: Add entry explaining that "dll-symbols" and its two
aliases are now deprecated.
gdb/doc/ChangeLog:
* gdb.texinfo (Files): Document "add-shared-symbol-files"
and "assf" as being deprecated.
(Cygwin Native): Likewise for "dll-symbols".
(Non-debug DLL Symbols): Remove reference to "dll-symbols"
as a way to force the loading of symbols from a DLL.
This patch fixes the following ARI warning:
gdb/dec-thread.c:695: regression: multi-line string: Multi-line string
must have the newline escaped
I think the new-line was unintentional, so I simply removed it,
and then reformatted the string to fit within our 70-80 max characters-
per-line rule.
gdb/ChangeLog:
* dec-thread.c (dec_thread_get_ada_task_ptid): Avoid unescaped
new-line in debug string. Remove trailing spaces.
* NEWS: Add entry for the new feature
* python/py-value.c (valpy_binop): Call value_x_binop for struct
and class values.
testsuite/
* gdb.python/py-value-cc.cc: Improve test case to enable testing
operations on gdb.Value objects.
* gdb.python/py-value-cc.exp: Add new test to test operations on
gdb.Value objects.
doc/
* python.texi (Values From Inferior): Add description about the
new feature.
It's best that we standardize on process_stratum targets using the
ptid.lwp field to store thread ids. The idea being leave the ptid.tid
field free for any thread_stratum target that might want to sit on
top. This patch adds a comment in that direction to struct ptid's
definition.
gdb/
2014-02-19 Pedro Alves <palves@redhat.com>
* common/ptid.h (struct ptid): Mention that process_stratum
targets should prefer ptid.lwp.
From GDB's perspective, independently of how the target really
implements threads, gdb/remote sees all threads as if kernel/system
threads. A rationale along theses lines led to gdbserver storing
thread ids in ptid.lwp in all ports.
Because remote.c is currently using ptid.tid, we can't make gdbserver
and gdb share bits of remote-specific code that manipulates ptids
(e.g., write_ptid/read_ptid).
This patch thus makes remote.c use ptid.lwp instead of ptid.tid.
I believe that on the GDB side too, it's best that we standardize on
process_stratum targets using the ptid.lwp field to store thread ids
anyway. The idea being leave the ptid.tid field free for any
thread_stratum target that might want to sit on top.
Tested on x86_64 Fedora 17, w/ local gdbserver.
gdb/
2014-02-19 Pedro Alves <palves@redhat.com>
* remote.c (remote_thread_alive, write_ptid, read_ptid)
(read_ptid, remote_newthread_step, remote_threads_extra_info)
(remote_get_ada_task_ptid, append_resumption, remote_stop_ns)
(threadalive_test, remote_pid_to_str): Use the ptid.lwp field to
store remote thread ids rather than ptid.tid.
(_initialize_remote): Adjust.
This converts to_get_unwinder and to_get_tailcall_unwinder to methods
and arranges for them to use the new delegation scheme.
This just lets us avoid having a differing style (neither new-style
nor INHERIT) of delegation in the tree.
2014-02-19 Tom Tromey <tromey@redhat.com>
* target.c (target_get_unwinder): Rewrite.
(target_get_tailcall_unwinder): Rewrite.
* record-btrace.c (record_btrace_to_get_unwinder): New function.
(record_btrace_to_get_tailcall_unwinder): New function.
(init_record_btrace_ops): Update.
* target.h (struct target_ops) <to_get_unwinder,
to_get_tailcall_unwinder>: Now function pointers. Use
TARGET_DEFAULT_RETURN.
I happened to notice that nto-procfs.c defines
procfs_remove_hw_breakpoint but never uses it. This caused it not to
be updated by my target-method-updating script. This patch fixes the
function and installs it properly. I have no way to test this,
however.
2014-02-19 Tom Tromey <tromey@redhat.com>
* nto-procfs.c (procfs_remove_hw_breakpoint): Add 'self'
argument.
(init_procfs_ops): Correctly set to_remove_hw_breakpoint.
This converts to_decr_pc_after_break to the new style of delegation,
removing forward_target_decr_pc_after_break.
2014-02-19 Tom Tromey <tromey@redhat.com>
* record-btrace.c (record_btrace_decr_pc_after_break): Delegate
directly.
* target-delegates.c: Rebuild.
* target.h (struct target_ops) <to_decr_pc_after_break>: Use
TARGET_DEFAULT_FUNC.
* target.c (default_target_decr_pc_after_break): Rename from
forward_target_decr_pc_after_break. Simplify.
(target_decr_pc_after_break): Rely on delegation.
This removes a few unnecessary calls to INHERIT and de_fault:
* to_doc is only used when a target is registered
* to_magic is only used when a target is pushed and not useful for
current_target.
* to_open and to_close are only ever called using a specific
target_ops object; there is no need to de_fault them.
2014-02-19 Tom Tromey <tromey@redhat.com>
* target.c (update_current_target): Do not INHERIT to_doc or
to_magic. Do not de_fault to_open or to_close.
exec_set_find_memory_regions is used to modify the exec target.
However, it only has a single caller, and so it is much clearer to
simply set the appropriate field directly. It's also better for the
coming multi-target world to avoid this kind of global state change
anyway.
2014-02-19 Tom Tromey <tromey@redhat.com>
* gcore.h (objfile_find_memory_regions): Declare.
* gcore.c (objfile_find_memory_regions): No longer static. Add
"self" argument.
(_initialize_gcore): Don't call exec_set_find_memory_regions.
* exec.c: Include gcore.h.
(exec_set_find_memory_regions): Remove.
(exec_find_memory_regions): Remove.
(exec_do_find_memory_regions): Remove.
(init_exec_ops): Update.
* defs.h (exec_set_find_memory_regions): Remove.
This changes instances of TARGET_DEFAULT_RETURN(0) to
TARGET_DEFAULT_RETURN(NULL) when appropriate. The use of "0" was a
relic from an earlier implementation of make-target-delegates; and I
didn't want to go back through the long patch series, fixing up
conflicts, just to change this small detail.
2014-02-19 Tom Tromey <tromey@redhat.com>
* target-delegates.c: Rebuild.
* target.h (struct target_ops) <to_extra_thread_info,
to_thread_name, to_pid_to_exec_file, to_get_section_table,
to_memory_map, to_read_description, to_traceframe_info>: Use NULL,
not 0, in TARGET_DEFAULT_RETURN.
This cleans up target.c to avoid function casts.
2014-02-19 Tom Tromey <tromey@redhat.com>
* target.c (complete_target_initialization): Remove casts. Use
return_zero_has_execution.
(return_zero): Add "ignore" argument.
(return_zero_has_execution): New function.
(init_dummy_target): Remove casts. Use
return_zero_has_execution.
During the conversion I kept all the "do not inherit" comments in
update_current_target. However, now they are not needed. This patch
updates the comments for INHERIT and de_fault, and removes the
somewhat odd INHERIT of to_stratum.
2014-02-19 Tom Tromey <tromey@redhat.com>
* target.c (update_current_target): Update comments. Do not
INHERIT to_stratum.
This switches to_read_description to the "new normal" delegation
scheme. This one was a bit trickier than the other changes due to the
way that target_read_description handled delegation. I examined all
the target implementations of to_read_description and changed the ones
returning NULL to instead delegate.
2014-02-19 Tom Tromey <tromey@redhat.com>
* arm-linux-nat.c (arm_linux_read_description): Delegate when
needed.
* corelow.c (core_read_description): Delegate when needed.
* remote.c (remote_read_description): Delegate when needed.
* target-delegates.c: Rebuild.
* target.c (target_read_description): Rewrite.
* target.h (struct target_ops) <to_read_description>: Update
comment. Use TARGET_DEFAULT_RETURN.
