A live target is required for `-info-os' to work in non-native
configurations.
(gdb)
Expecting: ^(-info-os[
]+)?(.*\^done,OSDataTable=.*[
]+[(]gdb[)]
[ ]*)
-info-os
^error,msg="Don't know how to get OS data. Try \"help target\"."
(gdb)
FAIL: gdb.mi/mi-info-os.exp: -info-os
If GDB does have a native configuration included, but we're testing
remote, it'll be worse, as if we're not connected yet, -info-os will
run against the default run target, and pass, falsely giving the
impression the remote bits were exercised.
gdb/testsuite/
2014-01-09 Maciej W. Rozycki <macro@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.mi/mi-info-os.exp: Connect to the target with
mi_gdb_target_load.
Currently, when GDB connects in all-stop mode, GDBserver always
responds to the status packet with a GDB_SIGNAL_TRAP, even if the
program is actually stopped for some other signal.
(gdb) tar rem ...
...
(gdb) c
Program received signal SIGUSR1, User defined signal 1.
(gdb) disconnect
(gdb) tar rem ...
(gdb) c
(Or a GDB crash instead of an explicit disconnect.)
This results in the program losing that signal on that last continue,
because gdb will tell the target to resume with no signal (to suppress
the GDB_SIGNAL_TRAP, due to 'handle SISGTRAP nopass'), and that will
actually suppress the real signal the program had stopped for
(SIGUSR1). To fix that, I think we should make GDBserver report the
real signal the thread had stopped for in response to the status
packet:
@item ?
@cindex @samp{?} packet
Indicate the reason the target halted. The reply is the same as for
step and continue.
But, that raises the question -- which thread are we reporting the
status for? Due to how the RSP in all-stop works, we can only report
one status. The status packet's response is a stop reply packet, so
it includes the thread identifier, so it's not a problem packet-wise.
However, GDBserver is currently always reporting the status for first
thread in the thread list, even though that may well not be the thread
that got the signal that caused the program to stop. So the next
logical step would be to report the status for the
last_ptid/last_status thread (the last event reported to gdb), if it's
still around; and if not, fallback to some other thread.
There's an issue on the GDB side with that, though...
GDB currently always adds the thread reported in response to the
status query as the first thread in its list. That means that if we
start with e.g.,
(gdb) info threads
3 Thread 1003 ...
* 2 Thread 1002 ...
1 Thread 1001 ...
And reconnect:
(gdb) disconnect
(gdb) tar rem ...
We end up with:
(gdb) info threads
3 Thread 1003 ...
2 Thread 1001 ...
* 1 Thread 1002 ...
Not a real big issue, but it's reasonably fixable, by having GDB
fetch/sync the thread list before fetching the status/'?', and then
using the status to select the right thread as current on the GDB
side. Holes in the thread numbers are squashed before/after
reconnection (e.g., 2,3,5 becomes 1,2,3), but the order is preserved,
which I think is both good, and good enough.
However (yes, there's more...), the previous GDB that was connected
might have had gdbserver running in non-stop mode, or could have left
gdbserver doing disconnected tracing (which also forces non-stop), and
if the new gdb/connection is in all-stop mode, we can end up with more
than one thread with a signal to report back to gdb. As we can only
report one thread/status (in the all-stop RSP variant; the non-stop
variant doesn't have this issue), we get to do what we do at every
other place we have this situation -- leave events we can't report
right now as pending, so that the next resume picks them up.
Note all this ammounts to a QoI change, within the existing framework.
There's really no RSP change here.
The only user visible change (other than that the signal is program is
stopped at isn't lost / is passed to the program), is in "info
program", that now can show the signal the program stopped for. Of
course, the next resume will respect the pass/nopass setting for the
signal in question. It'd be reasonable to have the initial connection
tell the user the program was stopped with a signal, similar to when
we load a core to debug, but I'm leaving that out for a future change.
I think we'll need to either change how handle_inferior_event & co
handle stop_soon, or maybe bypass them completely (like
fork-child.c:startup_inferior) for that.
Tested on x86_64 Fedora 17.
gdb/gdbserver/
2014-01-08 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct thread_info) <status_pending_p>: New field.
* server.c (visit_actioned_threads, handle_pending_status): New
function.
(handle_v_cont): Factor out parts to ...
(resume): ... this new function. If in all-stop, and a thread
being resumed has a pending status, report it without actually
resuming.
(myresume): Adjust to use the new 'resume' function.
(clear_pending_status_callback, set_pending_status_callback)
(find_status_pending_thread_callback): New functions.
(handle_status): Handle the case of multiple threads having
interesting statuses to report. Report threads' real last signal
instead of always reporting GDB_SIGNAL_TRAP. Look for a thread
with an interesting thread to report the status for, instead of
always reporting the status of the first thread.
gdb/
2014-01-08 Pedro Alves <palves@redhat.com>
* remote.c (remote_add_thread): Add threads silently if starting
up.
(remote_notice_new_inferior): If in all-stop, and starting up,
don't call notice_new_inferior.
(get_current_thread): New function, factored out from ...
(add_current_inferior_and_thread): ... this. Adjust.
(remote_start_remote) <all-stop>: Fetch the thread list. If we
found any thread, then select the remote's current thread as GDB's
current thread too.
gdb/testsuite/
2014-01-08 Pedro Alves <palves@redhat.com>
* gdb.threads/reconnect-signal.c: New file.
* gdb.threads/reconnect-signal.exp: New file.
gdb/ChangeLog:
2014-01-07 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* source.c (add_path): Fix check for duplicated paths in the previously
included paths.
gdb/testsuite/ChangeLog:
2014-01-07 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/source-dir.exp: New file.
Consider the following code:
type Element is abstract tagged null record;
type GADataType is interface;
type Data_Type is new Element and GADataType with record
I : Integer := 42;
end record;
Result1 : Data_Type;
GGG1 : GADataType'Class := GADataType'Class (Result1);
When trying to create a varobj for variable ggg1, GDB currently
returns an object which has no child:
-var-create ggg1 * ggg1
^done,name="ggg1",numchild="0",[...]
This is incorrect, it should return an object which has one child
(field "i"). This is because tagged-type objects are dynamic, and
we need to apply a small transformation in order to get their actual
type. This is already done on the GDB/CLI side in ada-valprint,
and it needs to be done on the ada-varobj side as well.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_adjust_for_child_access): Convert
tagged type objects to their actual type.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_interface: New testcase.
Consider the following types:
type Time_T is record
Secs : Integer;
end record;
Before : Time_T := (Secs => 1384395743);
In this example, we assume that type Time_T is the number of seconds
since Epoch, and so added a Python pretty-printer, to print this
type in a more human-friendly way. For instance:
(gdb) print before
$1 = Thu Nov 14 02:22:23 2013 (1384395743)
However, we've noticed that things stop working when this type is
embedded inside another record, and we try to print that record.
For instance, with the following declarations:
type Composite is record
Id : Integer;
T : Time_T;
end record;
Afternoon : Composite := (Id => 1, T => (Secs => 1384395865));
(gdb) print afternoon
$2 = (id => 1, t => (secs => 1384395865))
We expected instead:
(gdb) print afternoon
$2 = (id => 1, t => Thu Nov 14 02:24:25 2013 (1384395865))
This patch fixes the problem by making sure that we try to print
each field via a call to val_print, rather than calling ada_val_print
directly. We need to go through val_print, as the val_print
handles all language-independent features such as calling the
pretty-printer, knowing that ada_val_print will get called eventually
if actual Ada-specific printing is required (which should be the
most common scenario).
And because val_print takes the language as parameter, we enhanced
the print_field_values and print_variant_part to also take a language.
As a bonus, this allows us to remove a couple of references to
current_language.
gdb/ChangeLog:
* ada-valprint.c (print_field_values): Add "language" parameter.
Update calls to print_field_values and print_variant_part.
Pass new parameter "language" in call to val_print instead
of "current_language". Replace call to ada_val_print by call
to val_print.
(print_variant_part): Add "language" parameter.
(ada_val_print_struct_union): Update call to print_field_values.
gdb/testsuite/ChangeLog:
* gdb.ada/pp-rec-component.exp, gdb.ada/pp-rec-component.py,
gdb.ada/pp-rec-component/foo.adb, gdb.ada/pp-rec-component/pck.adb,
gdb.ada/pp-rec-component/pck.ads: New files.
Consider the following declarations:
typedef long our_time_t;
our_time_t current_time = 1384395743;
The purpose of this patch is to allow the use of a pretty-printer
for variables of type our_time_t. Normally, pretty-printing sniffers
use the tag name in order to determine which, if any, pretty-printer
should be used. But in the case above, the tag name is not set, since
it does not apply to integral types.
This patch extends the gdb.Type list of attributes to also include
the name of the type, thus allowing the sniffer to match against
that name. With that change, I was able to write a pretty-printer
which displays our variable as follow:
(gdb) print current_time
$1 = Thu Nov 14 02:22:23 2013 (1384395743)
gdb/ChangeLog:
* python/py-type.c (typy_get_name): New function.
(type_object_getset): Add entry for attribute "name".
* NEWS: Add entry mentioning this new attribute.
gdb/doc/ChangeLog:
* gdb.texinfo (Types In Python): Document new attribute Types.name.
gdb/testsuite:
* gdb.python/py-pp-integral.c: New file.
* gdb.python/py-pp-integral.py: New file.
* gdb.python/py-pp-integral.exp: New file.
Tested on x86_64-linux.
Code rationale
==============
by: Gabriel Krisman Bertazi
This is a fix for bug 16297. The problem occurs when the user attempts
to catch any syscall 0 (such as syscall read on Linux/x86_64). GDB was
not able to catch the syscall and was missing the breakpoint.
Now, breakpoint_hit_catch_syscall returns immediately when it finds the
correct syscall number, avoiding a following check for the end of the
search vector, that returns a no hit if the syscall number was zero.
Testcase rationale
==================
by: Sergio Durigan Junior
This testcase is a little difficult to write. By doing a quick
inspection at the Linux source, one can see that, in many targets, the
syscall number 0 is restart_syscall, which is forbidden to be called
from userspace. Therefore, on many targets, there's just no way to test
this safely.
My decision was to take the simpler route and just adds the "read"
syscall on the default test. Its number on x86_64 is zero, which is
"good enough" since many people here do their tests on x86_64 anyway and
it is a popular architecture.
However, there was another little gotcha. When using "read" passing 0
as the third parameter (i.e., asking it to read 0 bytes), current libc
implementations could choose not to effectively call the syscall.
Therefore, the best solution was to create a temporary pipe, write 1
byte into it, and then read this byte from it.
gdb/ChangeLog
2013-12-19 Gabriel Krisman Bertazi <gabriel@krisman.be>
PR breakpoints/16297
* breakpoint.c (breakpoint_hit_catch_syscall): Return immediately
when expected syscall is hit.
gdb/testsuite/ChangeLog
2013-12-19 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/16297
* gdb.base/catch-syscall.c (read_syscall, pipe_syscall)
(write_syscall): New variables.
(main): Create a pipe, write 1 byte in it, and read 1 byte from
it.
* gdb.base/catch-syscall.exp (all_syscalls): Include "pipe,
"write" and "read" syscalls.
(fill_all_syscalls_numbers): Improve the way to obtain syscalls
numbers.
Added new domain MODULE_DOMAIN for fortran modules to avoid
issues with sharing namespaces (e.g. when a variable currently
in scope has the same name as a module).
(gdb) ptype modname
old> No symbol "modname" in current context.
new> type = module modname
This fixes PR 15209 and also addresses the issue
with sharing namespaces:
https://sourceware.org/ml/gdb-patches/2013-02/msg00643.html
2013-11-19 Keven Boell <keven.boell@intel.com>
Sanimir Agovic <sanimir.agovic@intel.com>
* cp-namespace.c (cp_lookup_nested_symbol): Enable
nested lookups for fortran modules.
* dwarf2read.c (read_module): Add fortran module to
the symbol table.
(add_partial_symbol, add_partial_module): Add fortran
module to the partial symbol table.
(new_symbol_full): Create full symbol for fortran module.
* f-exp.y (yylex): Add new module domain to be parsed.
* symtab.h: New domain for fortran modules.
testsuite/
* gdb.fortran/module.exp: Completion matches fortran module
names as well. ptype/whatis on modules return a proper type.
Add new check for having the correct scope.
(gdb) ptype type
old> No symbol "type" in current context.
new> type = Type type
integer(kind=4) :: t_i
End Type type
2013-11-19 Sanimir Agovic <sanimir.agovic@intel.com>
Keven Boell <keven.boell@intel.com>
* f-exp.y (yylex): Add domain array to enable lookup
in multiple domains. Loop over lookup domains and try
to find requested symbol. Add STRUCT_DOMAIN to lookup
domains to be able to query for user defined types.
testsuite/
* gdb.fortran/type.f90: New file.
* gdb.fortran/whatis_type.f90: New file.
While fixing another bug, I found that the current
gdb.base/catch-syscall.exp is kind of messy, could use some
improvements, and is not correctly testing some things.
I've made the following patch to address all the issues I found. On the
organization side, it does a cleanup and removes unecessary imports of
gdb_prompt, uses prepare_for_testing and clean_restart where needed, and
fixes some comments. The testcase was also not correctly testing
catching syscalls using only numbers, or catching many syscalls at
once. I fixed that.
The patch also uses a new method for obtaining the syscalls numbers: it
relies on the C source file to get them, via <sys/syscall.h> and SYS_*
macros. This makes the .exp file simpler because there is no need to
include target conditionals there.
I tested this on x86_64 Fedora 18.
gdb/testsuite/ChangeLog:
2013-12-18 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/catch-syscall.c: Include <sys/syscall.h>.
(close_syscall, chroot_syscall, exit_group_syscall): New
variables.
* gdb.base/catch-syscall.exp: Replace gdb_compile by
prepare_for_testing. Call fill_all_syscalls_numbers before
starting. Replace gdb_exit, gdb_start, gdb_reinitialize_dir and
gdb_load by clean_restart.
(check_info_bp_any_syscall, check_info_bp_specific_syscall)
(check_info_bp_many_syscalls): Remove global gdb_prompt.
(check_call_to_syscall): Likewise. Add global decimal. Improve
testing regex.
(check_return_from_syscall): Likewise.
(check_continue, insert_catch_syscall_with_arg): Remove global
gdb_prompt.
(insert_catch_syscall_with_many_args): Likewise. Add global
decimal. Fix $filter_str. Improve testing regex.
(check_for_program_end): Remove global gdb_prompt.
(test_catch_syscall_without_args): Likewise. Add global decimal.
Improve testing regex.
(test_catch_syscall_with_args, test_catch_syscall_with_many_args)
(test_catch_syscall_with_wrong_args)
(test_catch_syscall_restarting_inferior)
(test_catch_syscall_fail_nodatadir): Remove global gdb_prompt.
(do_syscall_tests): Likewise. Remove global srcdir.
(test_catch_syscall_without_args_noxml): Remove global gdb_prompt.
Add global last_syscall_number. Test for the exact syscall number
to be caught.
(test_catch_syscall_with_args_noxml): Remove global gdb_prompt.
Add global all_syscalls_numbers. Test each syscall number to be
caught, instead of only testing "close".
(test_catch_syscall_with_wrong_args_noxml): Remove global gdb_prompt.
(do_syscall_tests_without_xml): Likewise. Remove global srcdir.
Remove stale comment.
(fill_all_syscalls_numbers): Add global last_syscall_number. Fill
the correct syscall numbers using information from the inferior.
Like when stepping, the current stack frame location is expected to be
printed as result of tfind command, if that results in moving to a
different function. In tfind_1 we see:
if (from_tty
&& (has_stack_frames () || traceframe_number >= 0))
{
enum print_what print_what;
/* NOTE: in imitation of the step command, try to determine
whether we have made a transition from one function to
another. If so, we'll print the "stack frame" (ie. the new
function and it's arguments) -- otherwise we'll just show the
new source line. */
if (frame_id_eq (old_frame_id,
get_frame_id (get_current_frame ())))
print_what = SRC_LINE;
else
print_what = SRC_AND_LOC;
print_stack_frame (get_selected_frame (NULL), 1, print_what, 1);
do_displays ();
}
However, when we haven't collected any registers in the tracepoint
(collect $regs), that doesn't actually work:
(gdb) tstart
(gdb) info tracepoints
Num Type Disp Enb Address What
1 tracepoint keep y 0x080483b7 in func0
at ../.././../git/gdb/testsuite/gdb.trace/circ.c:28
collect testload
installed on target
2 tracepoint keep y 0x080483bc in func1
at ../.././../git/gdb/testsuite/gdb.trace/circ.c:32
collect testload
installed on target
(gdb) c
Continuing.
Breakpoint 3, end () at ../.././../git/gdb/testsuite/gdb.trace/circ.c:72
72 }
(gdb) tstop
(gdb) tfind start
Found trace frame 0, tracepoint 1
#0 func0 () at ../.././../git/gdb/testsuite/gdb.trace/circ.c:28
28 }
(gdb) tfind
Found trace frame 1, tracepoint 2
32 }
(gdb)
When we don't have info about the stack available
(UNWIND_UNAVAILABLE), frames end up with outer_frame_id as frame ID.
And in the scenario above, the issue is that both frames before and
after the second tfind (the frames for func0 an func1) have the same
id (outer_frame_id), so the frame_id_eq check returns false, even
though the frames were of different functions. GDB knows that,
because the PC is inferred from the tracepoint's address, even if no
registers were collected.
To fix this, this patch adds support for frame ids with a valid code
address, but <unavailable> stack address, and then makes the unwinders
use that instead of the catch-all outer_frame_id for such frames. The
frame_id_eq check in tfind_1 then automatically does the right thing
as expected.
I tested with --directory=gdb.trace/ , before/after the patch, and
compared the resulting gdb.logs, then adjusted the tests to expect the
extra output that came out. Turns out that was only circ.exp, the
original test that actually brought this issue to light.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2013-12-17 Pedro Alves <palves@redhat.com>
* frame.h (enum frame_id_stack_status): New enum.
(struct frame_id) <stack_addr>: Adjust comment.
<stack_addr_p>: Delete field, replaced with ...
<stack_status>: ... this new field.
(frame_id_build_unavailable_stack): Declare.
* frame.c (frame_addr_hash, fprint_field, outer_frame_id)
(frame_id_build_special): Adjust.
(frame_id_build_unavailable_stack): New function.
(frame_id_build, frame_id_build_wild): Adjust.
(frame_id_p, frame_id_eq, frame_id_inner): Adjust to take into
account frames with unavailable stack.
* amd64-tdep.c (amd64_frame_this_id)
(amd64_sigtramp_frame_this_id, amd64_epilogue_frame_this_id): Use
frame_id_build_unavailable_stack.
* dwarf2-frame.c (dwarf2_frame_this_id): Likewise.
* i386-tdep.c (i386_frame_this_id, i386_epilogue_frame_this_id)
(i386_sigtramp_frame_this_id): Likewise.
gdb/testsuite/
2013-12-17 Pedro Alves <palves@redhat.com>
* gdb.trace/circ.exp: Expect frame info to be printed when
switching between frames with unavailable stack, but different
functions.
https://sourceware.org/ml/gdb-patches/2013-12/msg00144.html
The vector of unavailable parts of a value is currently byte based. Given
that we can model a value down to the bit level, we can potentially loose
information with the current implementation. After this patch we model the
unavailable information in bits.
gdb/ChangeLog
* dwarf2loc.c (read_pieced_value): Mark bits, not bytes
unavailable, use correct bit length.
* value.c (struct value): Extend comment on unavailable to
indicate that it is bit based.
(value_bits_available): New function.
(value_bytes_available): Call value_bits_available.
(value_entirely_available): Check against the bit length, not byte
length.
(mark_value_bits_unavailable): New function.
(mark_value_bytes_unavailable): Move contents to
mark_value_bits_unavailable, call to same.
(memcmp_with_bit_offsets): New function.
(value_available_contents_bits_eq): New function, takes the
functionality from value_available_contents_eq but uses
memcmp_with_bit_offsets now, and is bit not byte based.
(value_available_contents_eq): Move implementation into
value_available_contents_bits_eq, call to same.
(value_contents_copy_raw): Work on bits, not bytes.
(unpack_value_bits_as_long_1): Check availability in bits, not
bytes.
* value.h (value_bits_available): Declare new function.
(mark_value_bits_unavailable): Declare new function.
gdb/testsuite/ChangeLog
* gdb.trace/unavailable-dwarf-piece.c: New file.
* gdb.trace/unavailable-dwarf-piece.exp: New file.
This patch add a perf test case on skip-prologue by inserting
breakpoints on two functions many times, in order to exercise
skip-prologue.
gdb/testsuite:
2013-12-15 Yao Qi <yao@codesourcery.com>
* gdb.perf/skip-prologue.c: New.
* gdb.perf/skip-prologue.exp: New.
* gdb.perf/skip-prologue.py: New.
This function has the following code:
elt_type = type;
for (i = n; i > 1; i--)
elt_type = TYPE_TARGET_TYPE (type);
For multi-dimension arrays, the code above tries to find the array
type corresponding to the dimension we're trying to inspect.
The problem is that, past the second dimension, the loop does
nothing other than repeat the first iteration. There is a little
thinko where it got the TYPE_TARGET_TYPE of TYPE instead of ELT_TYPE!
To my surprise, I was unable to produce an Ada exemple that demonstrated
the problem. That's because the examples I created all trigger a parallel
___XA type which we then use in place of the ELT_TYPE in order to
determine the bounds - see the code that immediately follows our
loop above:
index_type_desc = ada_find_parallel_type (type, "___XA");
ada_fixup_array_indexes_type (index_type_desc);
if (index_type_desc != NULL)
[...]
So, in order to avoid depending on an Ada example where the compiler
can potentially decide one way or the other, I decided to use an
artificial example, written in C. With ...
int multi[1][2][3];
... forcing the language to Ada, and trying to print the 'last,
we get:
(gdb) p multi'last(1)
$1 = 0
(gdb) p multi'last(2)
$2 = 1
(gdb) p multi'last(3)
$3 = 1 <<<--- This should be 2!
Additionally, I noticed that a couple of check_typedef's were missing.
This patch adds them. And since the variable in question only gets
used within an "else" block, I moved the variable declaration and
use inside that block - making it clear what the scope of the variable
is.
gdb/ChangeLog:
* ada-lang.c (ada_array_bound_from_type): Move the declaration
and assignment of variable "elt_type" inside the else block
where it is used. Add two missing check_typedef calls.
Fix bug where we got TYPE's TYPE_TARGET_TYPE, where in fact
we really wanted to get ELT_TYPE's TYPE_TARGET_TYPE.
gdb/testsuite/ChangeLog:
* gdb.ada/arraydim: New testcase.
PR python/16113
* NEWS (Python Scripting): Add entry for the new feature and the
new attribute of gdb.Field objects.
* python/py-type.c (gdbpy_is_field): New function
(convert_field): Add 'parent_type' attribute to gdb.Field
objects.
* python/py-value.c (valpy_getitem): Allow subscript value to be
a gdb.Field object.
(value_has_field): New function
(get_field_flag): New function
* python/python-internal.h (gdbpy_is_field): Add declaration.
testsuite/
* gdb.python/py-value-cc.cc: Improve test case.
* gdb.python/py-value-cc.exp: Add new tests to test usage of
gdb.Field objects as subscripts on gdb.Value objects.
doc/
* gdb.texinfo (Values From Inferior): Add a note about using
gdb.Field objects as subscripts on gdb.Value objects.
(Types In Python): Add description about the new attribute
"parent_type" of gdb.Field objects.
* c-lang.c (c_get_string): Ignore the declared size of the object
if a specific length is requested.
testsuite/
* gdb.python/py-value.c: #include stdlib.h, string.h.
(str): New struct.
(main): New local xstr.
* gdb.python/py-value.exp (test_value_in_inferior): Add test to
fetch a value as a string with a length beyond the declared length
of the array.
This helps with the following issue: Given an Ada program defining
a global variable:
package Pck is
Watch : Integer := 1974;
end Pck;
When printing the address of this variable, GDB also tries to print
the associated symbol name:
(gdb) p watch'address
$1 = (access integer) 0x6139d8 <pck__watch>
^^
||
The problem is that GDB prints the variable's linkage name, instead
of its natural name. This is because the language of the associated
minimal symbol never really gets set.
This patch adds handling for Ada symbols in symbol_find_demangled_name.
After this patch, we now get:
(gdb) p watch'address
$1 = (access integer) 0x6139d8 <pck.watch>
^
|
gdb/ChangeLog:
* symtab.c (symbol_find_demangled_name): Add handling of
Ada symbols.
gdb/testsuite/ChangeLog:
* gdb.ada/int_deref.exp: Add test verifying that we print
the decoded symbol name when printing the address of Ada
symbols.
This adds "exec-run-start-option" in the output of the -list-features
commands, allowing front-ends to easily determine whether -exec-run
supports the --start option.
gdb/ChangeLog:
* mi/mi-main.c (mi_cmd_list_features): add "exec-run-start-option".
* NEWS: Expand the entry documenting the new -exec-run --start
option to mention the corresponding new entry in the output of
"-list-features".
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Miscellaneous Commands): Document the new
"exec-run-start-option" entry in the output of the "-list-features"
command.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-start.exp: Add test verifying that -list-features
contains "exec-run-start-option".
We added a new proc gdb_produce_source recently, and it can be used
more widely in lib/gdb.exp to generate source file.
gdb/testsuite:
2013-12-08 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (support_complex_tests): Use gdb_produce_source.
(is_elf_target, is_ilp32_target, is_ilp64_target): Likewise.
(is_64_target, is_amd64_regs_target): Likewise.
(skip_altivec_tests, skip_vsx_tests, skip_btrace_tests): Likewise.
These files are source files and have no business being +x. We couldn't
easily fix it in CVS (you need login+write access to the raw rcs files),
but we can fix this w/git.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
These scripts use /bin/ksh, but they're dirt simple and can be used with
/bin/sh, so just change the shebang.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Doing "info frame" in the outermost frame, when that was indicated by
the next frame saying the unwound PC is undefined/not saved, results
in error and incomplete output:
(gdb) bt
#0 thread_function0 (arg=0x0) at threads.c:63
#1 0x00000034cf407d14 in start_thread (arg=0x7ffff7fcb700) at pthread_create.c:309
#2 0x000000323d4f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) frame 2
#2 0x000000323d4f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
115 call *%rax
(gdb) info frame
Stack level 2, frame at 0x0:
rip = 0x323d4f168d in clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:115); saved rip Register 16 was not saved
(gdb)
Not saved register values are treated as optimized out values
internally throughout. stack.c:frame_info is handing unvailable
values, but not optimized out ones. The patch deletes the
frame_unwind_caller_pc_if_available wrapper function and instead lets
errors propagate to frame_info (it's only user).
As frame_unwind_pc now needs to be able to handle and cache two
different error scenarios, the prev_pc.p variable is replaced with an
enumeration.
(FWIW, I looked into making gdbarch_unwind_pc or a variant return
struct value's instead, but it results in lots of boxing and unboxing
for no real gain -- e.g., the mips and arm implementations need to do
computation on the unboxed PC value. Might as well throw an error on
first attempt to get at invalid contents.)
After the patch, we get:
(gdb) info frame
Stack level 2, frame at 0x0:
rip = 0x323d4f168d in clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:115); saved rip = <not saved>
Outermost frame: outermost
caller of frame at 0x7ffff7fcafc0
source language asm.
Arglist at 0x7ffff7fcafb8, args:
Locals at 0x7ffff7fcafb8, Previous frame's sp is 0x7ffff7fcafc8
(gdb)
A new test is added. It's based off dw2-reg-undefined.exp, and tweaked to
mark the return address (rip) of "stop_frame" as undefined.
Tested on x86_64 Fedora 17.
gdb/
2013-12-06 Pedro Alves <palves@redhat.com>
* frame.c (enum cached_copy_status): New enum.
(struct frame_info) <prev_pc.p>: Change type to enum
cached_copy_status.
(fprint_frame): Handle not saved and unavailable prev_pc values.
(frame_unwind_pc_if_available): Delete and merge contents into ...
(frame_unwind_pc): ... here. Handle OPTIMIZED_OUT_ERROR. Adjust
to use enum cached_copy_status.
(frame_unwind_caller_pc_if_available): Delete.
(create_new_frame): Adjust.
* frame.h (frame_unwind_caller_pc_if_available): Delete
declaration.
* stack.c (frame_info): Use frame_unwind_caller_pc instead of
frame_unwind_caller_pc_if_available, and handle
NOT_AVAILABLE_ERROR and OPTIMIZED_OUT_ERROR errors.
* valprint.c (val_print_optimized_out): Use val_print_not_saved.
(val_print_not_saved): New function.
* valprint.h (val_print_not_saved): Declare.
gdb/testsuite/
2013-12-06 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-undefined-ret-addr.S: New file.
* gdb.dwarf2/dw2-undefined-ret-addr.c: New file.
* gdb.dwarf2/dw2-undefined-ret-addr.exp: New file.
In some languages, e.g. fortran, arrays start with index 1
instead 0. This patch changes the MI library to support testing
varobj children of fortran arrays.
2013-11-21 Keven Boell <keven.boell@intel.com>
testsuite/
* lib/mi-support.exp (mi_list_varobj_children_range): Add
call to mi_list_array_varobj_children_with_index.
(mi_list_array_varobj_children_with_index): New function.
Add parameter to specify array start.
2013-10-03 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.base/sigall.exp (test_one_sig): gdb identifies SIGLOST as a
SIGPWR in sparc64.
* gdb.base/sigall.c (main): In some targets SIGLOST and SIGPWR
have the same signal number. Handle this situation.
Consider the following code:
type Ptr is access all Integer;
IP : Ptr := new Integer'(123);
IP is the Ada exception of a pointer to an integer. To dereference
the pointer and get its value, the user uses the reserved word "all"
as follow:
(gdb) p ip.all
$1 = 123
Ada being a case-insensitive language, the casing should not matter.
Unfortunately, for the reserved word "all", things don't work. For
instance:
(gdb) p ip.ALL
Type integer is not a structure or union type
This patch fixes the problem.
gdb/ChangeLog:
* ada-lex.l (find_dot_all): Use strncasecmp instead of strncmp.
gdb/testsuite/ChangeLog:
* gdb.ada/dot_all: New testcase.
... when trying to execute an undefined GDB/MI command. When trying
to execute a GDB/MI command which does not exist, the current error
result record looks like this:
-unsupported
^error,msg="Undefined MI command: unsupported"
The only indication that the command does not exist is the error
message. It would be a little fragile for a consumer to rely solely
on the contents of the error message in order to determine whether
a command exists or not.
This patch improves the situation by adding concept of error
code, starting with one well-defined error code ("undefined-command")
identifying errors due to a non-existant command. Here is the new
output:
-unsupported
^error,msg="Undefined MI command: unsupported",code="undefined-command"
This error code is only displayed when the corresponding error
condition is met. Otherwise, the error record remains unchanged.
For instance:
-symbol-list-lines foo.adb
^error,msg="-symbol-list-lines: Unknown source file name."
For frontends to be able to know whether they can rely on this
variable, a new entry "undefined-command-error-code" has been
added to the "-list-features" command. Another option would be
to always generate an error="..." variable (for the default case,
we could decide for instance that the error code is the empty string).
But it seems more efficient to provide that info in "-list-features"
and then only add the error code when meaningful.
gdb/ChangeLog:
(from Pedro Alves <palves@redhat.com>)
(from Joel Brobecker <brobecker@adacore.com>)
* exceptions.h (enum_errors) <UNDEFINED_COMMAND_ERROR>: New enum.
* mi/mi-parse.c (mi_parse): Throw UNDEFINED_COMMAND_ERROR instead
of a regular error when the GDB/MI command does not exist.
* mi/mi-main.c (mi_cmd_list_features): Add
"undefined-command-error-code".
(mi_print_exception): Print an "undefined-command"
error code if EXCEPTION.ERROR is UNDEFINED_COMMAND_ERROR.
* NEWS: Add entry documenting the new "code" variable in
"^error" result records.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Result Records): Fix the syntax of the
"^error" result record concerning the error message. Document
the error code that may also be part of that result record.
(GDB/MI Miscellaneous Commands): Document the
"undefined-command-error-code" element in the output of
the "-list-features" GDB/MI command.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-undefined-cmd.exp: New testcase.
This patch adds a new GDB/MI command meant for graphical frontends
trying to determine whether a given GDB/MI command exists or not.
Examples:
-info-gdb-mi-command unsupported-command
^done,command={exists="false"}
(gdb)
-info-gdb-mi-command symbol-list-lines
^done,command={exists="true"}
(gdb)
At the moment, this is the only piece of information that this
command returns.
Eventually, and if needed, we can extend it to provide
command-specific pieces of information, such as updates to
the command's syntax since inception. This could become,
for instance:
-info-gdb-mi-command symbol-list-lines
^done,command={exists="true",features=[]}
(gdb)
-info-gdb-mi-command catch-assert
^done,command={exists="true",features=["conditions"]}
In the first case, it would mean that no extra features,
while in the second, it announces that the -catch-assert
command in this version of the debugger supports a feature
called "condition" - exact semantics to be documented with
combined with the rest of the queried command's documentation.
But for now, we start small, and only worry about existance.
And to bootstrap the process, I have added an entry in the
output of the -list-features command as well ("info-gdb-mi-command"),
allowing the graphical frontends to go through the following process:
1. Send -list-features, collect info from there as before;
2. Check if the output contains "info-gdb-mi-command".
If it does, then support for various commands can be
queried though -info-gdb-mi-command. Newer commands
will be expected to always be checked via this new
-info-gdb-mi-command.
gdb/ChangeLog:
* mi/mi-cmds.h (mi_cmd_info_gdb_mi_command): Declare.
* mi/mi-cmd-info.c (mi_cmd_info_gdb_mi_command): New function.
* mi/mi-cmds.c (mi_cmds): Add -info-gdb-mi-command command.
* mi/mi-main.c (mi_cmd_list_features): Add "info-gdb-mi-command"
field to output of "-list-features".
* NEWS: Add entry for new -info-gdb-mi-command.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Miscellaneous Commands): Document
the new -info-gdb-mi-command GDB/MI command. Document
the meaning of "-info-gdb-mi-command" in the output of
-list-features.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-i-cmd.exp: New file.
gdb/
2013-12-02 Doug Evans <dje@google.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
* objfiles.c (allocate_objfile): Save original_name as an absolute
path.
* objfiles.h (struct objfile): Expand comment on original_name.
* source.c (openp): Call gdb_abspath.
* utils.c (gdb_abspath): New function.
* utils.h (gdb_abspath): Declare.
gdb/testsuite/
2013-12-02 Doug Evans <dje@google.com>
* gdb.dwarf/dwp-symlink.c: Fake out gdb to not load debug info
at start.
* gdb.dwarf/dwp-symlink.exp: Test trying to load dwp when the binary
has been specified with a relative path and we have chdir'd before
accessing the debug info.
When printing an entirely optimized out structure/class/union, we
print a single <optimized out> instead of printing <optimized out> for
each field.
This patch makes an entirely unavailable structure/class/union be
likewise displayed with a single "<unavailable>" rather than the whole
object with all fields <unavailable>.
This seems good because this way the user can quickly tell whether the
whole value is unavailable, rather than having to skim all fields.
Consistency with optimized out values also seems to be a good thing to
have.
A few updates to gdb.trace/unavailable.exp where required.
Tested on x86_64 Fedora 17, native gdbserver.
gdb/
2013-11-28 Andrew Burgess <aburgess@broadcom.com>
Pedro Alves <palves@redhat.com>
* valprint.c (value_check_printable): If the value is entirely
unavailable, print a single "<unavailable>" instead of printing
all subfields.
gdb/testsuite/
2013-11-28 Andrew Burgess <aburgess@broadcom.com>
* gdb.trace/unavailable.exp (gdb_collect_args_test): Update
expected results.
(gdb_collect_locals_test): Likewise.
(gdb_collect_globals_test): Likewise.
This patch adds a test case to test the performance of GDB doing
disassembly.
gdb/testsuite/
2013-11-28 Yao Qi <yao@codesourcery.com>
* lib/gdb.exp (with_gdb_prompt): New proc.
* gdb.perf/disassemble.exp: New.
* gdb.perf/disassemble.py: New.
This reverts da2b2fdf57 and some
follow-up patches. They were incorrect.
2013-11-26 Tom Tromey <tromey@redhat.com>
* dwarf2-frame.c (dwarf2_frame_cache): Revert patch from
2013-11-22.
2013-11-26 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-unspecified-ret-addr.S: Remove.
* gdb.dwarf2/dw2-unspecified-ret-addr.c: Remove.
* gdb.dwarf2/dw2-unspecified-ret-addr.exp: Remove.
* gdb.python/py-value.exp (test_lazy_strings): Tweak test names.
(test_subscript_regression): Ditto.
(top level): Run test_subscript_regression for c++ with "c++" prefix.
Pedro asked me to add a comment to dw2-bad-cfi.S explaining the nature
of the badness.
I'm checking this in.
2013-11-22 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-bad-cfi.S: Update comment.
Debugging PR 16155 further, I found that the DWARF unwinder found the
function in question, but thought it had no registers saved
(fs->regs.num_regs == 0).
It seems to me that if a frame does not specify the return address
column, or if the return address column is explicitly marked as
DWARF2_FRAME_REG_UNSPECIFIED, then we should set the
"undefined_retaddr" flag and let the DWARF unwinder gracefully stop.
This patch implements that idea.
With this patch the backtrace works properly:
(gdb) bt
#0 0x0000007fb7ed485c in nanosleep () from /lib64/libc.so.6
#1 0x0000007fb7ed4508 in sleep () from /lib64/libc.so.6
#2 0x00000000004008bc in thread_function (arg=0x4) at threadapply.c:73
#3 0x0000007fb7fad950 in start_thread () from /lib64/libpthread.so.0
#4 0x0000007fb7f0956c in clone () from /lib64/libc.so.6
2013-11-22 Tom Tromey <tromey@redhat.com>
PR backtrace/16155:
* dwarf2-frame.c (dwarf2_frame_cache): Set undefined_retaddr if
the return address column is unspecified.
2013-11-22 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-bad-cfi.c: New file.
* gdb.dwarf2/dw2-bad-cfi.exp: New file.
* gdb.dwarf2/dw2-bad-cfi.S: New file.
The UNWIND_SAME_ID check is done between THIS_FRAME and the next frame
when we go try to unwind the previous frame. But at this point, it's
already too late -- we ended up with two frames with the same ID in
the frame chain. Each frame having its own ID is an invariant assumed
throughout GDB. This patch applies the UNWIND_SAME_ID detection
earlier, right after the previous frame is unwound, discarding the dup
frame if a cycle is detected.
The patch includes a new test that fails before the change. Before
the patch, the test causes an infinite loop in GDB, after the patch,
the UNWIND_SAME_ID logic kicks in and makes the backtrace stop with:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The test uses dwarf CFI to emulate a corrupted stack with a cycle. It
has a function with registers marked DW_CFA_same_value (most
importantly RSP/RIP), so that GDB computes the same ID for that frame
and its caller. IOW, something like this:
#0 - frame_id_1
#1 - frame_id_2
#2 - frame_id_3
#3 - frame_id_4
#4 - frame_id_4 <<<< outermost (UNWIND_SAME_ID).
(The test's code is just a copy of dw2-reg-undefined.S /
dw2-reg-undefined.c, adjusted to use DW_CFA_same_value instead of
DW_CFA_undefined, and to mark a different set of registers.)
The infinite loop is here, in value_fetch_lazy:
while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val))
{
frame = frame_find_by_id (VALUE_FRAME_ID (new_val));
...
new_val = get_frame_register_value (frame, regnum);
}
get_frame_register_value can return a lazy register value pointing to
the next frame. This means that the register wasn't clobbered by
FRAME; the debugger should therefore retrieve its value from the next
frame.
To be clear, get_frame_register_value unwinds the value in question
from the next frame:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
^^^^^^^^^^^
}
In other words, if we get a lazy lval_register, it should have the
frame ID of the _next_ frame, never of FRAME.
At this point in value_fetch_lazy, the whole relevant chunk of the
stack up to frame #4 has already been unwound. The loop always
"unlazies" lval_registers in the "next/innermost" direction, not in
the "prev/unwind further/outermost" direction.
So say we're looking at frame #4. get_frame_register_value in frame
#4 can return a lazy register value of frame #3. So the next
iteration, frame_find_by_id tries to read the register from frame #3.
But, since frame #4 happens to have same id as frame #3,
frame_find_by_id returns frame #4 instead. Rinse, repeat, and we have
an infinite loop.
This is an old latent problem, exposed by the recent addition of the
frame stash. Before we had a stash, frame_find_by_id(frame_id_4)
would walk over all frames starting at the current frame, and would
always find #3 first. The stash happens to return #4 instead:
struct frame_info *
frame_find_by_id (struct frame_id id)
{
struct frame_info *frame, *prev_frame;
...
/* Try using the frame stash first. Finding it there removes the need
to perform the search by looping over all frames, which can be very
CPU-intensive if the number of frames is very high (the loop is O(n)
and get_prev_frame performs a series of checks that are relatively
expensive). This optimization is particularly useful when this function
is called from another function (such as value_fetch_lazy, case
VALUE_LVAL (val) == lval_register) which already loops over all frames,
making the overall behavior O(n^2). */
frame = frame_stash_find (id);
if (frame)
return frame;
for (frame = get_current_frame (); ; frame = prev_frame)
{
gdb/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* frame.c (get_prev_frame_1): Do the UNWIND_SAME_ID check between
this frame and the new previous frame, not between this frame and
the next frame.
gdb/testsuite/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* gdb.dwarf2/dw2-dup-frame.S: New file.
* gdb.dwarf2/dw2-dup-frame.c: New file.
* gdb.dwarf2/dw2-dup-frame.exp: New file.
The UNWIND_SAME_ID check is done between THIS_FRAME and the next frame
when we go try to unwind the previous frame. But at this point, it's
already too late -- we ended up with two frames with the same ID in
the frame chain. Each frame having its own ID is an invariant assumed
throughout GDB. This patch applies the UNWIND_SAME_ID detection
earlier, right after the previous frame is unwound, discarding the dup
frame if a cycle is detected.
The patch includes a new test that fails before the change. Before
the patch, the test causes an infinite loop in GDB, after the patch,
the UNWIND_SAME_ID logic kicks in and makes the backtrace stop with:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The test uses dwarf CFI to emulate a corrupted stack with a cycle. It
has a function with registers marked DW_CFA_same_value (most
importantly RSP/RIP), so that GDB computes the same ID for that frame
and its caller. IOW, something like this:
#0 - frame_id_1
#1 - frame_id_2
#2 - frame_id_3
#3 - frame_id_4
#4 - frame_id_4 <<<< outermost (UNWIND_SAME_ID).
(The test's code is just a copy of dw2-reg-undefined.S /
dw2-reg-undefined.c, adjusted to use DW_CFA_same_value instead of
DW_CFA_undefined, and to mark a different set of registers.)
The infinite loop is here, in value_fetch_lazy:
while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val))
{
frame = frame_find_by_id (VALUE_FRAME_ID (new_val));
...
new_val = get_frame_register_value (frame, regnum);
}
get_frame_register_value can return a lazy register value pointing to
the next frame. This means that the register wasn't clobbered by
FRAME; the debugger should therefore retrieve its value from the next
frame.
To be clear, get_frame_register_value unwinds the value in question
from the next frame:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
^^^^^^^^^^^
}
In other words, if we get a lazy lval_register, it should have the
frame ID of the _next_ frame, never of FRAME.
At this point in value_fetch_lazy, the whole relevant chunk of the
stack up to frame #4 has already been unwound. The loop always
"unlazies" lval_registers in the "next/innermost" direction, not in
the "prev/unwind further/outermost" direction.
So say we're looking at frame #4. get_frame_register_value in frame
#4 can return a lazy register value of frame #3. So the next
iteration, frame_find_by_id tries to read the register from frame #3.
But, since frame #4 happens to have same id as frame #3,
frame_find_by_id returns frame #4 instead. Rinse, repeat, and we have
an infinite loop.
This is an old latent problem, exposed by the recent addition of the
frame stash. Before we had a stash, frame_find_by_id(frame_id_4)
would walk over all frames starting at the current frame, and would
always find #3 first. The stash happens to return #4 instead:
struct frame_info *
frame_find_by_id (struct frame_id id)
{
struct frame_info *frame, *prev_frame;
...
/* Try using the frame stash first. Finding it there removes the need
to perform the search by looping over all frames, which can be very
CPU-intensive if the number of frames is very high (the loop is O(n)
and get_prev_frame performs a series of checks that are relatively
expensive). This optimization is particularly useful when this function
is called from another function (such as value_fetch_lazy, case
VALUE_LVAL (val) == lval_register) which already loops over all frames,
making the overall behavior O(n^2). */
frame = frame_stash_find (id);
if (frame)
return frame;
for (frame = get_current_frame (); ; frame = prev_frame)
{
gdb/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* frame.c (get_prev_frame_1): Do the UNWIND_SAME_ID check between
this frame and the new previous frame, not between this frame and
the next frame.
gdb/testsuite/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* gdb.dwarf2/dw2-dup-frame.S: New file.
* gdb.dwarf2/dw2-dup-frame.c: New file.
* gdb.dwarf2/dw2-dup-frame.exp: New file.
Hi,
I find "has_more" is not checked when a dynamic varobj is created in
proc mi_create_dynamic_varobj. This patch adds the check to
"has_more".
gdb/testsuite:
2013-11-22 Yao Qi <yao@codesourcery.com>
* lib/mi-support.exp (mi_create_dynamic_varobj): Update
comment and add one more argument "has_more".
* gdb.python/py-mi.exp: Callers update.
In gdb.python/py-mi.exp, two varobjs container and nscont are created
when pretty-printing is still not enabled, so they are not dynamic
varobj, IIUC. In this patch, we use mi_create_floating_varobj instead
of mi_create_dynamic_varobj.
gdb/testsuite:
2013-11-22 Yao Qi <yao@codesourcery.com>
* gdb.python/py-mi.exp: Use mi_create_floating_varobj instead
of mi_create_dynamic_varobj.
2013-11-20 Pedro Alves <palves@redhat.com>
* gdb.base/maint.exp (maint print objfiles): Consume one line at a
time, and run it through all three milestone regexes.
I was "lucky" enough that an unrelated patch changed how many symtabs
GDB expands in a plain run to main, and that triggered a latent issue
in this test:
PASS: gdb.base/maint.exp: maint print objfiles: header
PASS: gdb.base/maint.exp: maint print objfiles: psymtabs
FAIL: gdb.base/maint.exp: maint print objfiles: symtabs
The problem is in my case, expect is managing to alway put in the
buffer chunks like this:
Psymtabs:
../../../src/gdb/testsuite/gdb.base/break1.c at 0x1ed2280, ../../../src/gdb/testsuite/gdb.base/break.c at 0x1ed21d0,
Symtabs:
../../../src/gdb/testsuite/gdb.base/break.c at 0x1f044f0, /usr/include/stdio.h at 0x1ed25a0, /usr/include/libio.h at 0x1ed2510, /usr/include/bits/types.h at 0x1ed2480, /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h at 0x1ed23f0,
Object file /usr/lib/debug/lib64/ld-2.15.so.debug: Objfile at 0x1f4bff0, bfd at 0x1f2d940, 0 minsyms
Psymtabs:
bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
0x1f65290, ...
Note: Psymtabs:/Symtabs:/Psymtabs:.
So, the loop matches the first Psymtabs in the buffer. Then we're
left with
../../../src/gdb/testsuite/gdb.base/break1.c at 0x1ed2280, ../../../src/gdb/testsuite/gdb.base/break.c at 0x1ed21d0,
Symtabs:
../../../src/gdb/testsuite/gdb.base/break.c at 0x1f044f0, /usr/include/stdio.h at 0x1ed25a0, /usr/include/libio.h at 0x1ed2510, /usr/include/bits/types.h at 0x1ed2480, /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h at 0x1ed23f0,
Object file /usr/lib/debug/lib64/ld-2.15.so.debug: Objfile at 0x1f4bff0, bfd at 0x1f2d940, 0 minsyms
Psymtabs:
bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
0x1f65290, ...
In the next iteration, because the psymtabs regex comes first, we
match with the Psymtabs: line, then of course, end up with just
bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at
0x1f65290, ...
in the buffer. The "Symtabs:" line is lost. expect then reads more
gdb output, and manages to again retrieve the same pattern. Rinse,
repeat, and the test never matches any "Symtab:" line.
We don't know the order the matches lines will appear, so the fix is
to consume one line at a time, and run it through all three milestone
regexes.
gdb/testsuite/
2013-11-20 Pedro Alves <palves@redhat.com>
* gdb.base/maint.exp (maint print objfiles): Consume one line at a
time, and run it through all three milestone regexes.
Ensure that certain commands (e.g. whatis/ptype) and sizeof intrinsic
have no side effects (variables cannot be altered).
2013-11-20 Sanimir Agovic <sanimir.agovic@intel.com>
testsuite/
* gdb.base/eval-avoid-side-effects.exp: New test.
Boundary length is simpler implemented by means of a pretty
printer. This simplifies users life when examining a bound register.
Changelog:
2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com>
* python/lib/gdb/command/bound_register.py: New file.
* gdb/data-directory/Makefile.in: copy bond_register.py to the right path to
be initialized at gdb startup.
testsuite/
* gdb.python/py-pp-maint.exp: Consider new pretty-print added for registers.
Change-Id: Id4f39845e5ece56c370a1fd4343648909f08b731
Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com>
Conflicts:
gdb/ChangeLog
Bitfields are represented by intervals [start, begin]. It means that for an
interval comprised by only one bit start and end will be equal.
The present condition does not always hold. On the other hand in target-description.c
(tdesc_gdb_type) bitfield is created when "f->type" is null. The routine
maint_print_maint_print_c_tdesc_cmd is modified to follow the same strategy.
2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com>
* target-descriptions.c (maint_print_maint_print_c_tdesc_cmd):
Modified logic of creating a bitfield to be in sync with
tdesc_gdb_type.
testsuite/
* gdb.xml/maint_print_struct.xml (bitfield): Added bitfield having
start and end equal 0.
Change-Id: I8c62db049995f0c0c30606d9696b86afe237cbb9
Hi,
In proc mi_child_regexp, \(,thread-id=\"\[0-9\]+\") is appended to
children_exp, while the first '\' is not necessary. This patch
is to remove it. With this patch applied, Emacs can find the right
left paren.
gdb/testsuite:
2013-11-19 Yao Qi <yao@codesourcery.com>
* lib/mi-support.exp (mi_child_regexp): Remove unnecessary '\'.
There are some format issues in lib/mi-support.exp, such as using
spaces instead of tab and trailing spaces. This patch is to fix them.
gdb/testsuite:
2013-11-19 Yao Qi <yao@codesourcery.com>
* lib/mi-support.exp: Fix format.
Variable 'whatever' is not used at all. This patch is to remove it.
gdb/testsuite:
2013-11-19 Yao Qi <yao@codesourcery.com>
* lib/mi-support.exp (mi_child_regexp): Remove 'whatever'.
(mi_list_varobj_children_range): Likewise.
Consider the following variable:
type Small is range -128 .. 127;
SR : Small := 48;
Trying to get its value as an integer within Python code yields:
(gdb) python sr = gdb.parse_and_eval('sr')
(gdb) python print int(sr)
Traceback (most recent call last):
File "<string>", line 1, in <module>
gdb.error: Cannot convert value to int.
Error while executing Python code.
This is happening because our variable is a range type, and
py-value's is_intlike does not handle TYPE_CODE_RANGE. This
patch fixes this.
gdb/ChangeLog:
* python/py-value.c (is_intlike): Add TYPE_CODE_RANGE handling.
gdb/testsuite/ChangeLog:
* gdb.ada/py_range: New testcase.
In the case where the GNAT runtime was built with full debugging info,
several of the exceptions defined there might have a name contain
the word "global". To make this less likely, this patch renames
the exception name, replacing "Global" by "Global_GDB". It still
keeps the exeption name relatively short, while it is unlikely that
the GNAT runtime has an exception whose name explicitly mentions GDB,
and even less likely that it contains "Global_GDB".
gdb/testsuite/ChangeLog:
* info_exc/const.ads (Aint_Global_GDB_E): Renames Aint_Global_E.
* info_exc/foo.adb: Adjust to new exception name.
* info_exc.exp: Adjust after exception renaming in const.ads.
Update "info exception global" test to test "info exceptions
global_gdb" instead.
* mi_exc_info/const.ads (Aint_Global_GDB_E): Renames Aint_Global_E.
* mi_exc_info/foo.adb (Adjust to new exception name.
* mi_exc_info.exp: Adjust after exception renaming in const.ads.
Update "-info-ada-exceptions global" test to test
"-info-ada-exceptions global_gdb" instead.
of inferior output for remote and native sessions.
* gdb.mi/mi-console.exp: Remove obsolete comment.
Check for semihosted inferior output pattern.
(semihosted_string): New function.
If the runtime has full debug info, then the non-standard exceptions
declared in the GNAT runtime will appear in the list of exceptions
printed by GDB ("info exceptions" or "-info-ada-exceptions").
This is valid output, so this patch allows for it.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc.exp: Allow other global exceptions to be
listed in the output of "info exceptions".
* gdb.ada/mi_exc_info.exp: Allow other global exceptions to be
listed in the output of "-info-ada-exceptions".
This patch fixes some spurious failures when the inferior is linked
against the shared version of libgnat by default, as appears to be
the case on many GNU/Linux distributions. When that happens, we have
to start the program in order to ensure that the GNAT runtime is
mapped to memory, in order for us to find the standard exceptions
(defined within the runtime). Otherwise, they will not be shown,
as expected, by the debugger.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc.exp: Start inferior before starting
the "info exceptions" tests.
* gdb.ada/mi_exc_info.exp: Start inferior before starting
the "-info-ada-exceptions" tests.
This patch fixes PR c++/16117.
gdb has an extension so that users can use expressions like FILE::NAME
to choose a variable of the given name from the given file. The bug
is that this extension takes precedence over ordinary C++ expressions
of the same form. You might think this is merely hypothetical, but
now that C++ headers commonly do not use an extension, it is more
common.
This patch fixes the bug by making two related changes. First, it
changes gdb to prefer the ordinary C++ meaning of a symbol over the
extended meaning. Second, it arranges for single-quoting of the
symbol to indicate a preference for the extension.
Built and regtested on x86-64 Fedora 18.
New test case included.
2013-11-15 Tom Tromey <tromey@redhat.com>
PR c++/16117:
* c-exp.y (lex_one_token): Add "is_quoted_name" argument.
(classify_name): Likewise. Prefer a field of "this" over a
filename.
(classify_inner_name, yylex): Update.
2013-11-15 Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Variables): Note gdb rules for ambiguous cases.
Add example.
2013-11-15 Tom Tromey <tromey@redhat.com>
* gdb.cp/includefile: New file.
* gdb.cp/filename.exp: New file.
* gdb.cp/filename.cc: New file.
Consider the following code, compiled at -O2 on ppc-linux:
procedure Increment (Val : in out Float; Msg : String);
The implementation does not really matter in this case). In our example,
this function is being called from a function with Param_1 set to 99.0.
Trying to break inside that function, and running until reaching that
breakpoint yields:
(gdb) b increment
Breakpoint 1 at 0x100014b4: file callee.adb, line 6.
(gdb) run
Starting program: /[...]/foo
Breakpoint 1, callee.increment (val=99.0, val@entry=0.0, msg=...)
at callee.adb:6
6 if Val > 200.0 then
The @entry value for parameter "val" is incorrect, it should be 99.0.
The associated call-site parameter DIE looks like this:
.uleb128 0xc # (DIE (0x115) DW_TAG_GNU_call_site_parameter)
.byte 0x2 # DW_AT_location
.byte 0x90 # DW_OP_regx
.uleb128 0x21
.byte 0x3 # DW_AT_GNU_call_site_value
.byte 0xf5 # DW_OP_GNU_regval_type
.uleb128 0x3f
.uleb128 0x25
The DW_AT_GNU_call_site_value uses a DW_OP_GNU_regval_type
operation, referencing register 0x3f=63, which is $f31,
an 8-byte floating register. In that register, the value is
stored using the usual 8-byte float format:
(gdb) info float
f31 99.0 (raw 0x4058c00000000000)
The current code evaluating DW_OP_GNU_regval_type operations
currently is (dwarf2expr.c:execute_stack_op):
result = (ctx->funcs->read_reg) (ctx->baton, reg);
result_val = value_from_ulongest (address_type, result);
result_val = value_from_contents (type,
value_contents_all (result_val));
What the ctx->funcs->read_reg function does is read the contents
of the register as if it contained an address. The rest of the code
continues that assumption, thinking it's OK to then use that to
create an address/ulongest struct value, which we then re-type
to the type specified by DW_OP_GNU_regval_type.
We're getting 0.0 above because the read_reg implementations
end up treating the contents of the FP register as an integral,
reading only 4 out of the 8 bytes. Being a big-endian target,
we read the high-order ones, which gives us zero.
This patch fixes the problem by introducing a new callback to
read the contents of a register as a given type, and then adjust
the handling of DW_OP_GNU_regval_type to use that new callback.
gdb/ChangeLog:
* dwarf2expr.h (struct dwarf_expr_context_funcs) <read_reg>:
Extend the documentation a bit.
<get_reg_value>: New field.
* dwarf2loc.c (dwarf_expr_get_reg_value)
(needs_frame_get_reg_value): New functions.
(dwarf_expr_ctx_funcs, needs_frame_ctx_funcs): Add "get_reg_value"
callback.
* dwarf2-frame.c (get_reg_value): New function.
(dwarf2_frame_ctx_funcs): Add "get_reg_value" callback.
* dwarf2expr.c (execute_stack_op) <DW_OP_GNU_regval_type>:
Use new callback to compute result_val.
gdb/testsuite/ChangeLog:
* gdb.ada/O2_float_param: New testcase.
Pedro pointed out that it is handy for "make check" to print a summary
of the results. This happens in the check-single case and also if you
invoke runtest by hand.
This patch implements the same thing for check-parallel.
2013-11-14 Tom Tromey <tromey@redhat.com>
* Makefile.in (check-parallel): Print summary from gdb.sum.
dw2-case-insensitive.exp: p fuNC_lang fails on arm. The problem occurs
when thumb mode code is generated. On ARM last bit of function pointer
value indicates whether the target function is an ARM (if 0) or Thumb
(if 1) routine. The PC address should refer to actual address in
either case. This patch adds new compile unit and function labels to
code which act as address ranges of compile unit and functions in
debug information. Therefore address ranges will have correct
addresses and not the ones with an incremented least significant bit.
This patch has been tested on x86_64 and arm machines.
gdb/testsuite/ChangeLog:
2013-11-14 Omair Javaid <Omair.Javaid@linaro.org>
* gdb.dwarf2/dw2-case-insensitive-debug.S: Updated compile unit
and function label names.
* gdb.dwarf2/dw2-case-insensitive.c: Created function and
compile unit labels.
Frontend sometimes need to evaluate expressions that are
language-specific. For instance, Eclipse uses the following
expression to determine the size of an address on the target:
-data-evaluate-expression "sizeof (void*)"
Unfortunately, if the main of the program being debugged is not C,
this may not work. For instance, if the main is in Ada, you get...
-data-evaluate-expression "sizeof (void*)"
^error,msg="No definition of \"sizeof\" in current context."
... and apparently decides to stop the debugging session as a result.
The recommendation sent was to specifically set the language to C
before trying to evaluate the expression. Something such as:
1. save current language
2. set language c
3. -data-evaluate-expression "sizeof (void*)"
4. Restore language
This has the same disadvantages as the ones outlined in the "Context
Management" section of the GDB/MI documentation regarding setting
the current thread or the current frame, thus recommending the use of
general command-line switches such as --frame, or --thread instead.
This patch follows the same steps for the language, adding a similar
new command option: --language LANG. Example of use:
-data-evaluate-expression --language c "sizeof (void*)"
^done,value="4"
gdb/ChangeLog:
* mi/mi-parse.h (struct mi_parse) <language>: New field.
* mi/mi-main.c (mi_cmd_execute): Temporarily set language to
PARSE->LANGUAGE during command execution, if set.
* mi/mi-parse.c: Add "language.h" #include.
(mi_parse): Add parsing of "--language" command option.
* NEWS: Add entry mentioning the new "--language" command option.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-language.exp: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Show): Add xref anchor for "show language" command.
(Context management): Place current subsection text into its own
subsubsection. Add new subsubsection describing the "--language"
command option.
I noticed today that multi-arch-exec.exp was failing in parallel mode.
The bug is that multi-arch-exec.c assumes the non-parallel directory
layout.
This patch fixes the problem using the same "BASEDIR" approach used in
other tests.
Tested both ways on x86-64 Fedora 18.
I'm checking this in.
2013-11-13 Tom Tromey <tromey@redhat.com>
* gdb.multi/multi-arch-exec.exp: Define BASEDIR when compiling.
* gdb.multi/multi-arch-exec.c (main): Use BASEDIR.
This patch implements a new GDB/MI command implementing the equivalent
of the "info exceptions" CLI command. The command syntax is:
-info-ada-exceptions [REGEXP]
Here is an example of usage (slightly formatted by hand to make it
easier to read):
-info-ada-exceptions ions\.a_
^done,ada-exceptions=
{nr_rows="2",nr_cols="2",
hdr=[{width="1",alignment="-1",col_name="name",colhdr="Name"},
{width="1",alignment="-1",col_name="address",colhdr="Address"}],
body=[{name="global_exceptions.a_global_exception",
address="0x0000000000613a80"},
{name="global_exceptions.a_private_exception",
address="0x0000000000613ac0"}]}
Also, in order to allow graphical frontends to easily determine
whether this command is available or not, the output of the
"-list-features" command has been augmented to contain
"info-ada-exceptions".
gdb/Changelog:
* mi/mi-cmds.h (mi_cmd_info_ada_exceptions): Add declaration.
* mi/mi-cmds.c (mi_cmds): Add entry for -info-ada-exceptions
command.
* mi/mi-cmd-info.c: #include "ada-lang.c" and "arch-utils.c".
(mi_cmd_info_ada_exceptions): New function.
* mi/mi-main.c (mi_cmd_list_features): Add "info-ada-exceptions".
gdb/testsuite/ChangeLog:
* gdb.ada/mi_exc_info: New testcase.
This patch adds a new command "info exceptions" whose purpose is to
provide the list of exceptions currently defined in the inferior.
The usage is:
(gdb) info exceptions [REGEXP]
Without argument, the command lists all exceptions. Otherwise,
only those whose name match REGEXP are listed.
For instance:
(gdb) info exceptions
All defined Ada exceptions:
constraint_error: 0x613dc0
program_error: 0x613d40
storage_error: 0x613d00
tasking_error: 0x613cc0
global_exceptions.a_global_exception: 0x613a80
global_exceptions.a_private_exception: 0x613ac0
The name of the command, as well as its output is part of a legacy
I inherited long ago. It's output being parsed by frontends such as
GPS, I cannot easily change it. Same for the command name.
The implementation is mostly self-contained, and is written in a way
that should make it easy to implement the GDB/MI equivalent. The
careful reviewer will notice that the code added in ada-lang.h could
normally be made private inside ada-lang.c. But these will be used
by the GDB/MI implementation. Rather than making those private now,
only to move them later, I've made them public right away.
gdb/ChangeLog:
* ada-lang.h: #include "vec.h".
(struct ada_exc_info): New.
(ada_exc_info): New typedef.
(DEF_VEC_O(ada_exc_info)): New vector.
(ada_exceptions_list): Add declaration.
* ada-lang.c (ada_is_exception_sym)
(ada_is_non_standard_exception_sym, compare_ada_exception_info)
(sort_remove_dups_ada_exceptions_list)
(ada_exc_search_name_matches, ada_add_standard_exceptions)
(ada_add_exceptions_from_frame, ada_add_global_exceptions)
(ada_exceptions_list_1, ada_exceptions_list)
(info_exceptions_command): New function.
(_initialize_ada_language): Add "info exception" command.
gdb/testsuite/ChangeLog:
* gdb.ada/info_exc: New testcase.
When using the GDB/MI commands to insert a catchpoint on a specific
Ada exception, any re-evaluation of that catchpoint (for instance
a re-evaluation performed after a shared library got mapped by the
inferior) fails. For instance, with any Ada program:
(gdb)
-catch-exception -e program_error
^done,bkptno="1",bkpt={[...]}
(gdb)
-exec-run
=thread-group-started,id="i1",pid="28315"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,[...]
&"warning: failed to reevaluate internal exception condition for catchpoint 1: No definition of \"exec\" in current context.\n"
&"warning: failed to reevaluate internal exception condition for catchpoint 1: No definition of \"exec\" in current context.\n"
[...]
The same is true if using an Ada exception catchpoint.
The problem comes from the fact that that we deallocate the strings
given as arguments to create_ada_exception_catchpoint, while the latter
just makes shallow copies of those strings, thus creating dandling
pointers.
This patch fixes the issue by passing freshly allocated strings to
create_ada_exception_catchpoint, while at the same time updating
create_ada_exception_catchpoint's documentation to make it clear
that deallocating the strings is no longer the responsibility of
the caller.
gdb/ChangeLog:
* ada-lang.c (create_ada_exception_catchpoint): Enhance
the documentation of fields "except_string" and "condition".
* mi/mi-cmd-catch.c (mi_cmd_catch_assert): Reallocate
CONDITION on the heap before passing it to
create_ada_exception_catchpoint.
(mi_cmd_catch_exception): Likewise for EXCEPTION_NAME and
CONDITION.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ex_cond: New testcase.
Tested on x86_64-linux. The "-break-list" test FAILs without
this patch.
* python/py-breakpoint.c (bppy_get_temporary): New function.
(bppy_init): New keyword: temporary. Parse it and set breakpoint
to temporary if True.
2013-11-07 Phil Muldoon <pmuldoon@redhat.com>
* gdb.python/py-breakpoint.exp: Add temporary breakpoint tests.
2013-11-07 Phil Muldoon <pmuldoon@redhat.com>
* gdb.texinfo (Breakpoints In Python): Document temporary
option in breakpoint constructor, and add documentation to the
temporary attribute.
This patch is to add a test case to on the performance of GDB handling
load and unload of shared library.
In V4:
- Handle malloc and dlopen failure,
- Document test parameters.
In V3, there are some changes,
- Adapt to perf test framework changes.
- Measure load and unload separately.
In V2, there are some changes,
- A new proc gdb_produce_source to produce source files. I tried to
move all source file generation code out of solib.exp, but
compilation step still needs to know the generated file names. I
have to hard-code the file names in compilation step, which is not
good to me, so I give up on this moving.
- SOLIB_NUMBER -> SOLIB_COUNT
- New variable SOLIB_DLCLOSE_REVERSED_ORDER to control the order of
iterating a list of shared libs to dlclose them.
- New variable GDB_PERFORMANCE to enable these perf test cases.
- Remove dlsym call in solib.c.
- Update solib.py for the updated framework.
gdb/testsuite/
* lib/gdb.exp (gdb_produce_source): New procedure.
* gdb.perf/solib.c: New.
* gdb.perf/solib.exp: New.
* gdb.perf/solib.py: New.
Joel Brobecker
Pedro Alves
Edjunior Barbosa Machado
Hui Zhu
Gabriel Krisman Bertazi
Keven Boell
Sergio Durigan Junior
Andrew Burgess
Yao Qi
Siva Chandra
Doug Evans
Mike Frysinger
Jose E. Marchesi
Jan Kratochvil
Luis Machado
Tom Tromey
Keith Seitz
Doug Evans
Sanimir Agovic
Walfred Tedeschi
Omair Javaid
Phil Muldoon
Doug Evans