| Age | Commit message (Collapse) | Author |
|---|
|
Compiling GDB with a recent GCC exposes a problem:
../../gdb/typeprint.c: In function 'void whatis_exp(const char*, int)':
../../gdb/typeprint.c:515:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
real_type = value_rtti_type (val, &full, &top, &using_enc);
~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The warning is correct. There are indeed code paths that use
uninitialized 'val', leading to crashes. Inside the
value_rtti_indirect_type/value_rtti_type calls here in whatis_exp:
if (opts.objectprint)
{
if (((TYPE_CODE (type) == TYPE_CODE_PTR) || TYPE_IS_REFERENCE (type))
&& (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_STRUCT))
real_type = value_rtti_indirect_type (val, &full, &top, &using_enc);
else if (TYPE_CODE (type) == TYPE_CODE_STRUCT)
real_type = value_rtti_type (val, &full, &top, &using_enc);
}
We reach those calls above with "set print object on", and then with
any of:
(gdb) whatis struct some_structure_type
(gdb) whatis struct some_structure_type *
(gdb) whatis struct some_structure_type &
because "whatis" with a type argument enters this branch:
/* The behavior of "whatis" depends on whether the user
expression names a type directly, or a language expression
(including variable names). If the former, then "whatis"
strips one level of typedefs, only. If an expression,
"whatis" prints the type of the expression without stripping
any typedef level. "ptype" always strips all levels of
typedefs. */
if (show == -1 && expr->elts[0].opcode == OP_TYPE)
{
which does not initialize VAL. Trying the above triggers crashes like
this:
(gdb) set print object on
(gdb) whatis some_structure_type
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00000000005dda90 in check_typedef (type=0x6120736573756170) at src/gdb/gdbtypes.c:2388
2388 int instance_flags = TYPE_INSTANCE_FLAGS (type);
...
This is a regression caused by a recent-ish refactoring of the code on
'whatis_exp', introduced by:
commit c973d0aa4a2c737ab527ae44a617f1c357e07364
Date: Mon Aug 21 11:34:32 2017 +0100
Fix type casts losing typedefs and reimplement "whatis" typedef stripping
Fix this by setting VAL to NULL in the "whatis TYPE" case, and
skipping fetching the dynamic type if there's no value to fetch it
from.
New tests included.
gdb/ChangeLog:
2018-01-22 Pedro Alves <palves@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
* typeprint.c (whatis_exp): Initialize "val" in the "whatis type"
case.
gdb/testsuite/ChangeLog:
2018-01-22 Pedro Alves <palves@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/whatis.exp: Add tests for 'set print object on' +
'whatis <struct>' 'whatis <struct> *' and 'whatis <struct> &'.
|
|
One test in gdb.compile/compile.exp passes on one fedora builder,
bt
#0 0x00007ffff7ff43f6 in _gdb_expr (__regs=0x7ffff7ff2000) at gdb
command line:1^M
#1 <function called from gdb>^M
#2 main () at /home/gdb-buildbot/fedora-x86-64-1/fedora-x86-64/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M
(gdb) PASS: gdb.compile/compile.exp: bt
but fails on my machine with gcc trunk,
bt^M
#0 _gdb_expr (__regs=0x7ffff7ff3000) at gdb command line:1^M
#1 <function called from gdb>^M
#2 main () at gdb/testsuite/gdb.compile/compile.c:106^M
(gdb) FAIL: gdb.compile/compile.exp: bt
The test should be tweaked to match both cases (pc in the start of line
vs pc in the middle of line). Note that I am not clear that why libcc1
emits debug info this way so that the address is in the middle of line.
gdb/testsuite:
2018-01-17 Yao Qi <yao.qi@linaro.org>
* gdb.compile/compile.exp: Match the address printed for
frame in the output of command "bt".
|
|
In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan
pointed out that the scalar printing patches caused a regression in
scm-ports.exp on x86.
What happens is that on x86, this:
set sp_reg [get_integer_valueof "\$sp" 0]
... ends up setting sp_reg to a negative value, because
get_integer_valueof uses "print/d":
print /d $sp
$1 = -11496
Then later the test suite does:
gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \
"= $sp_reg" \
"seek to \$sp"
... expecting this value to be identical to the saved $sp_reg value.
However it gets:
guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))
= 4294955800
"print" is just a wrapper for guile's format:
gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))"
The seek function returns a scm_t_off, the printing of which is
handled by guile, not by gdb.
Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
build.
2018-01-15 Tom Tromey <tom@tromey.com>
* gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
compute sp_reg.
|
|
This adds a testcase for the previous commit. The regression was
related to in-line step overs. The reason we didn't see it on native
x86-64/s390 GNU/Linux testing is that native debugging uses displaced
stepping by default (because native debugging defaults to "maint set
target-non-stop on"), unlike remote debugging.
So in order to trigger the bug with native debugging as well, the
testcase disables displaced stepping explicitly.
Also, instead of using watchpoints to trigger the regression, the
testcase uses a breakpoint at address 0, which should be more
portable.
gdb/testsuite/ChangeLog:
2018-01-12 Pedro Alves <palves@redhat.com>
* gdb.base/continue-after-aborted-step-over.c: New.
* gdb.base/continue-after-aborted-step-over.exp: New.
|
|
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00285.html>,
Maciej reported that commit:
commit 5cd63fda035d4ba949e6478406162c4673b3c9ef
Date: Wed Oct 4 18:21:10 2017 +0100
Subject: Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
made GDB stop working with older stubs. Any attempt to continue
execution after the initial connection fails with:
[...]
Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670
Listening on port 2346
target remote [...]:2346
Remote debugging using [...]:2346
Reading symbols from .../lib64/ld.so.1...done.
[Switching to Thread <main>]
(gdb) continue
Cannot execute this command without a live selected thread.
(gdb)
The problem is:
(gdb) c
Cannot execute this command without a live selected thread.
(gdb) info threads
Id Target Id Frame
1 Thread 14917 0x00007f341cd98ed0 in _start () from /lib64/ld-linux-x86-64.so.2
The current thread <Thread ID 2> has terminated. See `help thread'.
^^^^^^^^^^^
(gdb)
Note, thread _2_. There's really only one thread in the inferior
(it's still at the entry point), but still GDB added a bogus second
thread.
The reason GDB started adding a second thread after 5cd63fda035d is
this hunk:
+ if (event->ptid == null_ptid)
+ {
+ const char *thr = strstr (p1 + 1, ";thread:");
+ if (thr != NULL)
+ event->ptid = read_ptid (thr + strlen (";thread:"),
+ NULL);
+ else
+ event->ptid = magic_null_ptid;
+ }
Note the else branch that falls back to magic_null_ptid. We reach
that when we process the initial stop reply sent back in response to
the the "?" (status) packet early in the connection setup:
Sending packet: $?#3f...Ack
Packet received: T0506:0000000000000000;07:40a510f4fd7f0000;10:d0fe1201577f0000;
And note that that response does not include a ";thread:XXX" part.
This stop reply is processed after listing threads with qfThreadInfo /
qsThreadInfo :
Sending packet: $qfThreadInfo#bb...Ack
Packet received: m3915
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
meaning, when we process that stop reply, we treat the event as coming
from a thread with ptid == magic_null_ptid, which is not yet in the
thread list, so we add it then:
(top-gdb) p ptid
$1 = {m_pid = 42000, m_lwp = -1, m_tid = 1}
(top-gdb) bt
#0 0x0000000000840a8c in add_thread_silent(ptid_t) (ptid=...) at src/gdb/thread.c:269
#1 0x00000000007ad61d in remote_add_thread(ptid_t, int, int) (ptid=..., running=0, executing=0)
at src/gdb/remote.c:1838
#2 0x00000000007ad8de in remote_notice_new_inferior(ptid_t, int) (currthread=..., executing=0)
at src/gdb/remote.c:1921
#3 0x00000000007b758b in process_stop_reply(stop_reply*, target_waitstatus*) (stop_reply=0x1158860, status=0x7fffffffcc00)
at src/gdb/remote.c:7217
#4 0x00000000007b7a38 in remote_wait_as(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/remote.c:7380
#5 0x00000000007b7cd1 in remote_wait(target_ops*, ptid_t, target_waitstatus*, int) (ops=0x102fac0 <remote_ops>, ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7446
#6 0x000000000081587b in delegate_wait(target_ops*, ptid_t, target_waitstatus*, int) (self=0x102fac0 <remote_ops>, arg1=..., arg2=0x7fffffffcc00, arg3=0) at src/gdb/target-delegates.c:138
#7 0x0000000000827d77 in target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/target.c:2179
#8 0x0000000000715fda in do_target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/infrun.c:3589
#9 0x0000000000716351 in wait_for_inferior() () at src/gdb/infrun.c:3707
#10 0x0000000000715435 in start_remote(int) (from_tty=1) at src/gdb/infrun.c:3212
things go downhill from this.
We don't see the problem with current master gdbserver, because that
version always sends the ";thread:" part in the initial stop reply:
Sending packet: $?#3f...Packet received: T0506:0000000000000000;07:a0d4ffffff7f0000;10:d05eddf7ff7f0000;thread:p3cea.3cea;core:3;
Years ago I had added a "--disable-packet=" command line option to
gdbserver which comes in handy for testing this, since the existing
"--disable-packet=Tthread" precisely makes gdbserver not send that
";thread:" part in stop replies. The testcase added by this commit
emulates old gdbserver making use of that.
I've compared a testrun at 5cd63fda035d^ (before regression) with
'current master+patch', against old gdbserver at f8b73d13b7ca^. I
hacked out --once, and "monitor exit" to be able to test. The results
are a bit too unstable to tell accurately, but it looked like there
were no regressions. Maciej confirmed this worked for him as well.
No regressions on master (against master gdbserver).
gdb/ChangeLog:
2018-01-11 Pedro Alves <palves@redhat.com>
PR remote/22597
* remote.c (remote_parse_stop_reply): Default to the last-set
general thread instead of to 'magic_null_ptid'.
gdb/testsuite/ChangeLog:
2018-01-11 Pedro Alves <palves@redhat.com>
PR remote/22597
* gdb.server/stop-reply-no-thread.c: New file.
* gdb.server/stop-reply-no-thread.exp: New file.
|
|
A previous patch fixed verbatim matching in the lookup at the minimal
symbol level, but we should also be finding that same symbol through
the partial/full symtab search.
For example, this is what happens if we use "print" instead of
"break":
(gdb) p <MixedCaseFunc>
$1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc>
Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a
function without parameters, and the expression above means calling
it. If you try it before having started the inferior, you'd get the
following (expected) error:
(gdb) print <MixedCaseFunc>
You can't do that without a process to debug.
The main idea behind making the name matcher be determined by the
symbol's language is so that C++ (etc.) wildmatching in linespecs
works even if the current language is not C++, as e.g., when you step
through C or assembly code.
Ada's verbatim matching syntax however ("<...>") isn't quite the same.
It is more a property of the current language than of a particular
symbol's language. We want to support this syntax when debugging an
Ada program, but it's reason of existence is to find non-Ada symbols.
This suggests going back to enabling it depending on current language
instead of language of the symbol being matched.
I'm not entirely happy with the "current_language" reference (though I
think that it's harmless). I think we could try storing the current
language in the lookup_name_info object, and then convert a bunch of
functions more to pass around lookup_name_info objects instead of
"const char *" names. I.e., build the lookup_name_info higher up.
I'm not sure about that, I'll have to think more about it. Maybe
something different will be better. Meanwhile, this gets us going.
I've extended the testcase to also exercise a no-debug-info function,
for extra coverage of the minsyms-only paths.
gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* dwarf2read.c
(gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher):
Adjust to use language_get_symbol_name_matcher instead of
language_defn::la_get_symbol_name_matcher.
* language.c (language_get_symbol_name_matcher): If in Ada mode
and the lookup name is a verbatim match, return Ada's matcher.
* language.h (language_get_symbol_name_matcher): Adjust comment.
(ada_lookup_name_info::verbatim_p):: New method.
gdb/testsuite/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* gdb.ada/bp_c_mixed_case.exp: Add intro comment. Test printing C
functions too. Test setting breakpoints and printing C functions
with no debug info too.
* gdb.ada/bp_c_mixed_case/qux.c: New file.
|
|
This patch fixes the regression covered by the test added by:
commit 344420da6beac1e0b2f7964e7101f8dcdb509b0d
Date: Thu Jan 4 03:30:37 2018 -0500
Subject: Add "complete break ada" test to gdb.ada/complete.exp
The regression had been introduced by:
commit b5ec771e60c1a0863e51eb491c85c674097e9e13
Date: Wed Nov 8 14:22:32 2017 +0000
Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching
The gist of it is that linespec completion in Ada mode is generating
additional matches that should not appear in the match list
(internally generated symbols, or symbols that should be enclosed
between "<...>"). These extraneous entries have uppercase characters, such as:
break ada__stringsS
break ada__strings__R11s
[etc]
These matches come from minimal symbols. The problem is that Ada
minsyms end up with no language set (language_auto), and thus we end
up using the generic symbol name matcher for those instead of Ada's.
We already had a special case for in compare_symbol_name to handle
this, but it was limited to expressions, while the case at hand is
completing a linespec. Fix this by applying the special case to
linespec completion as well. I.e., remove the EXPRESSION check from
compare_symbol_name. That alone turns out to not be sufficient still
-- GDB would still show a couple entries that shouldn't be there:
~~
break ada__exceptions__exception_data__append_info_exception_name__2Xn
break ada__exceptions__exception_data__exception_name_length__2Xn
~~
The reason is that these minimal symbols end up with their language
set to language_cplus / C++, because those encoded names manage to
demangle successfully as C++ symbols (using an old C++ mangling
scheme):
$ echo ada__exceptions__exception_data__append_info_exception_name__2Xn | c++filt
Xn::ada__exceptions__exception_data__append_info_exception_name(void)
It's unfortunate that Ada's encoding scheme doesn't start with some
unique prefix like "_Z" in the C++ Itanium ABI mangling scheme. For
now, paper over that by treating C++ minsyms as Ada minsyms.
gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* ada-lang.c (ada_collect_symbol_completion_matches): If the
minsym's language is language_auto or language_cplus, pass down
language_ada instead.
* symtab.c (compare_symbol_name): Don't frob symbol language here.
gdb/testsuite/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* gdb.ada/complete.exp ("complete break ada"): Replace kfail with
a fail.
|
|
The problem here is that we are using the user-provided lookup name
literally for name comparisons. I.e., "<MixedCase>" with the "<>"s
included.
This commit fixes the minsym lookup case. psymbol/symbol lookup will
be fixed in a follow up.
In the minsym case, we're using using the user-provided lookup name
literally for linkage name comparisons. That obviously can't work
since the "<>" are not really part of the linkage name.
The original idea was that we'd use the symbol's language to select
the right symbol name matching algorithm, but that doesn't work for
Ada because it's not really possible to unambiguously tell from the
linkage name alone whether we're dealing with Ada symbols, so Ada
minsyms end up with no language set, or sometimes C++ set.
So fix this by treating Ada mode specially when determining the
linkage name to match against.
gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* minsyms.c (linkage_name_str): New function.
(iterate_over_minimal_symbols): Use it.
gdb/testsuite/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls.
|
|
When we set bfd/development.sh:$development to false, GDBserver failed to
build,
selftest.o: In function `selftests::run_tests(char const*)':
binutils-gdb/gdb/gdbserver/../common/selftest.c:97:undefined reference to `selftests::reset()'
collect2: error: ld returned 1 exit status
selftest.o shouldn't be compiled and linked when $development is false.
With this patch, in release mode, GDBserver doesn't nothing with option
--selftest,
$ ./gdbserver --selftest=foo
Selftests are not available in a non-development build.
$ ./gdbserver --selftest
Selftests are not available in a non-development build.
gdb/gdbserver:
2018-01-08 Yao Qi <yao.qi@linaro.org>
Simon Marchi <simon.marchi@ericsson.com>
* Makefile.in (OBS): Remove selftest.o.
* configure.ac: Set srv_selftest_objs if $development is true.
(GDBSERVER_DEPFILES): Append $srv_selftest_objs.
* configure: Re-generated.
* server.c (captured_main): Wrap variable selftest_filter with
GDB_SELF_TEST.
gdb/testsuite:
2018-01-08 Simon Marchi <simon.marchi@ericsson.com>
* gdb.server/unittest.exp: Match the output in non-development
mode.
|
|
We don't build GDB selftests bits when $development is false. However, if
we turn bfd/development.sh:$development to false, common/selftest.c is
compiled which is not expected. It causes the build failure,
selftest.o: In function `selftests::run_tests(char const*)':
binutils-gdb/gdb/common/selftest.c:97: undefined reference to `selftests::reset()'
collect2: error: ld returned 1 exit status
I fix this issue by putting selftest.o selftest-arch.o into CONFIG_OBS
only when $development is true. After this is fixed, there are other
build failures in maint.c, this patch fixes them as well.
In the release mode, the output of these commands are:
(gdb) maintenance selftest
Selftests are not available in a non-development build.
(gdb) maintenance selftest foo
Selftests are not available in a non-development build.
(gdb) maintenance info selftests
Selftests are not available in a non-development build.
gdb:
2018-01-08 Yao Qi <yao.qi@linaro.org>
Simon Marchi <simon.marchi@ericsson.com>
* Makefile.in (COMMON_SFILES): Remove selftest-arch.c and
common/selftest.c.
(COMMON_OBS): Remove selftest.o.
* configure.ac: Append selftest-arch.c and common/selftest.c to
CONFIG_SRCS. Append selftest-arch.o and selftest.o to COMMON_OBS.
* configure: Re-generated.
* maint.c (maintenance_selftest): Wrap selftests::run_tests with
GDB_SELF_TEST.
(maintenance_info_selftests): Likewise.
gdb/testsuite:
2018-01-08 Simon Marchi <simon.marchi@ericsson.com>
* gdb.gdb/unittest.exp: Match output in non-development mode.
|
|
At https://sourceware.org/bugzilla/show_bug.cgi?id=18653#c7, Andrew
reports that the fix for PR gdb/18653 made GDB useless if you preload
libSegFault.so, because GDB internal-errors on startup:
$ LD_PRELOAD=libSegFault.so gdb
src/gdb/common/signals-state-save-restore.c:64: internal-error: unexpected signal handler
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Aborted (core dumped)
$
The internal error comes from the code saving the signal dispositions
inherited from gdb's parent:
(top-gdb) bt
#0 0x000000000056b001 in internal_error(char const*, int, char const*, ...) (file=0xaf5f38 "src/gdb/common/signals-state-save-restore.c", line=64, fmt=0xaf5f18 "unexpected signal handler") at src/gdb/common/errors.c:54
#1 0x00000000005752c9 in save_original_signals_state() () at src/gdb/common/signals-state-save-restore.c:64
#2 0x00000000007425de in captured_main_1(captured_main_args*) (context=0x7fffffffd860)
at src/gdb/main.c:509
#3 0x0000000000743622 in captured_main(void*) (data=0x7fffffffd860) at src/gdb/main.c:1145
During symbol reading, cannot get low and high bounds for subprogram DIE at 24065.
#4 0x00000000007436f9 in gdb_main(captured_main_args*) (args=0x7fffffffd860) at src/gdb/main.c:1171
#5 0x0000000000413acd in main(int, char**) (argc=1, argv=0x7fffffffd968) at src/gdb/gdb.c:32
This commit downgrades the internal error to a warning. You'll get
instead:
~~~
$ LD_PRELOAD=libSegFault.so gdb
warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)
won't be propagated to spawned programs.
GNU gdb (GDB) 8.0.50.20171213-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
(gdb)
~~~
This also moves the location where save_original_signals_state is
called a bit further below (to after option processing), so that "-q"
disables the warning:
~~~
$ LD_PRELOAD=libSegFault.so gdb -q
(gdb)
~~~
New testcase included.
gdb/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/18653
* common/signals-state-save-restore.c
(save_original_signals_state): New parameter 'quiet'. Warn if we
find a custom handler preinstalled, instead of internal erroring.
But only warn if !quiet.
* common/signals-state-save-restore.h
(save_original_signals_state): New parameter 'quiet'.
* main.c (captured_main_1): Move save_original_signals_state call
after option handling, and pass QUIET.
gdb/gdbserver/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/18653
* server.c (captured_main): Pass quiet=false to
save_original_signals_state.
gdb/testsuite/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/18653
* gdb.base/libsegfault.exp: New.
|
|
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00298.html>, Joel
wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider the following code which first declares a tagged type (the
equivalent of a class in Ada), and then a procedure which takes a
pointer (access) to this type's 'Class.
package Pck is
type Top_T is tagged record
N : Integer := 1;
end record;
procedure Inspect (Obj: access Top_T'Class);
end Pck;
Putting a breakpoint in that procedure and then running to it triggers
an internal error:
(gdb) break inspect
(gdb) continue
Breakpoint 1, pck.inspect (obj=0x63e010
/[...]/gdb/stack.c:621: internal-error: void print_frame_args(symbol*, frame_info*, int, ui_file*): Assertion `nsym != NULL' failed.
What's special about this subprogram is that it takes an access to
what we call a 'Class type, and for implementation reasons, the
compiler adds an extra argument named "objL". If you are curious why,
it allows the compiler for perform dynamic accessibility checks that
are mandated by the language.
If we look at the location where we get the internal error (in
stack.c), we find that we are looping over the symbol of each
parameter, and for each parameter, we do:
/* We have to look up the symbol because arguments can have
two entries (one a parameter, one a local) and the one we
want is the local, which lookup_symbol will find for us.
[...]
nsym = lookup_symbol (SYMBOL_LINKAGE_NAME (sym),
b, VAR_DOMAIN, NULL).symbol;
gdb_assert (nsym != NULL);
The lookup_symbol goes through the lookup structure, which means the
symbol's linkage name ("objL") gets transformed into a
lookup_name_info object (in block_lookup_symbol), before it gets fed
to the block symbol dictionary iterators. This, in turn, triggers the
symbol matching by comparing the "lookup" name which, for Ada, means
among other things, lowercasing the given name to "objl". It is this
transformation that causes the lookup find no matches, and therefore
trip this assertion.
Going back to the "offending" call to lookup_symbol in stack.c, what
we are trying to do, here, is do a lookup by linkage name. So, I
think what we mean to be doing is a completely literal symbol lookup,
so maybe not even strcmp_iw, but actually just plain strcmp???
In the past, in practice, you could get that effect by doing a lookup
using the C language. But that doesn't work, because we still end up
somehow using Ada's lookup_name routine which transforms "objL".
So, ideally, as I hinted before, I think what we need is a way to
perform a literal lookup so that searches by linkage names like the
above can be performed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This commit fixes the problem by implementing something similar to
Joel's literal idea, but with some important differences.
I considered adding a symbol_name_match_type::LINKAGE and supporting
searching by linkage name for any language, but the problem with that
is that the dictionaries only work with SYMBOL_SEARCH_NAME, because
that's what is used for hashing. We'd need separate dictionaries for
hashed linkage names.
So with the current symbol tables infrastructure, it's not literal
linkage names that we want to pass down, but instead literal _search_
names (SYMBOL_SEARCH_NAME, etc.).
However, psymbols have no overload/function parameter info in C++, so
a straight strcmp doesn't work properly for C++ name matching.
So what we do is be a little less aggressive then and add a new
symbol_name_match_type::SEARCH_SYMBOL instead that takes as input a
non-user-input search symbol, and then we skip any decoding/demangling
steps and make:
- Ada treat that as a verbatim match,
- other languages treat it as symbol_name_match_type::FULL.
This also fixes the new '"maint check-psymtabs" for Ada' testcase for
me (gdb.ada/maint_with_ada.exp). I've not removed the kfail yet
because Joel still sees that testcase failing with this patch.
That'll be fixed in follow up patches.
gdb/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/22670
* ada-lang.c (literal_symbol_name_matcher): New function.
(ada_get_symbol_name_matcher): Use it for
symbol_name_match_type::SEARCH_NAME.
* block.c (block_lookup_symbol): New parameter 'match_type'. Pass
it down instead of assuming symbol_name_match_type::FULL.
* block.h (block_lookup_symbol): New parameter 'match_type'.
* c-valprint.c (print_unpacked_pointer): Use
lookup_symbol_search_name instead of lookup_symbol.
* compile/compile-object-load.c (get_out_value_type): Pass down
symbol_name_match_type::SEARCH_NAME.
* cp-namespace.c (cp_basic_lookup_symbol): Pass down
symbol_name_match_type::FULL.
* cp-support.c (cp_get_symbol_name_matcher): Handle
symbol_name_match_type::SEARCH_NAME.
* infrun.c (insert_exception_resume_breakpoint): Use
lookup_symbol_search_name.
* p-valprint.c (pascal_val_print): Use lookup_symbol_search_name.
* psymtab.c (maintenance_check_psymtabs): Use
symbol_name_match_type::SEARCH_NAME and SYMBOL_SEARCH_NAME.
* stack.c (print_frame_args): Use lookup_symbol_search_name and
SYMBOL_SEARCH_NAME.
* symtab.c (lookup_local_symbol): Don't demangle the lookup name
if symbol_name_match_type::SEARCH_NAME.
(lookup_symbol_in_language): Pass down
symbol_name_match_type::FULL.
(lookup_symbol_search_name): New.
(lookup_language_this): Pass down
symbol_name_match_type::SEARCH_NAME.
(lookup_symbol_aux, lookup_local_symbol): New parameter
'match_type'. Pass it down.
* symtab.h (symbol_name_match_type::SEARCH_NAME): New enumerator.
(lookup_symbol_search_name): New declaration.
(lookup_symbol_in_block): New 'match_type' parameter.
gdb/testsuite/ChangeLog:
2018-01-05 Joel Brobecker <brobecker@adacore.com>
PR gdb/22670
* gdb.ada/access_tagged_param.exp: New file.
* gdb.ada/access_tagged_param/foo.adb: New file.
|
|
The comments about mixed case in the testcase are actually a red
herring. The problem here is that we'd get to
ada_lookup_encoded_symbol with "my_table", which wraps the looked up
name in "<>"s to force a verbatim match, and that in turn disables
wild matching.
Fix this by swapping around the internals of ada_lookup_encoded_symbol
and ada_lookup_symbol, thus avoiding the encoding and
verbatim-wrapping in the ada_lookup_symbol case, the case that starts
with a user-provided lookup name.
Ada encoding is still done of course, in the ada_lookup_name_info
ctor. This could be also seen as avoiding the double-encoding problem
in a different way.
gdb/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/22670
* ada-lang.c (ada_lookup_encoded_symbol): Reimplement in terms of
ada_lookup_symbol.
(ada_lookup_symbol): Reimplement in terms of
ada_lookup_symbol_list, bits factored out from
ada_lookup_encoded_symbol.
gdb/testsuite/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/22670
* gdb.ada/info_addr_mixed_case.exp: Remove kfail. Extend test to
exercise lower case too, and to exercise both full matching and
wild matching.
|
|
This commit adds a new testcase testing the "check-psymtabs" and
"check-symtabs" maintenance commands.
The "maintenance check-psymtabs" commands is currently known to
produce some errors. While the situation was admetedly made worse
by the following patch...
commit b5ec771e60c1a0863e51eb491c85c674097e9e13
Date: Wed Nov 8 14:22:32 2017 +0000
Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching
... hence the reference to PR gdb/22670, the command was already
spotting one inconsistency prior to it:
(gdb) maintenance check-psymtabs
Global symbol `interfaces__cS' only found in /[...]/b~var_arr_typedef.adb psymtab
For now, the "check-psymtab" test is KFAIL-ed.
gdb/testsuite/ChangeLog:
PR gdb/22670
* gdb.ada/maint_with_ada: New testcase.
Tested on x86_64-linux.
|
|
This patch adds a new testcase to demonstrate a regression introduced by:
commit b5ec771e60c1a0863e51eb491c85c674097e9e13
Date: Wed Nov 8 14:22:32 2017 +0000
Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching
The purpose of the testcase is to verify that a user can insert
a breakpoint on a C function while debugging Ada, even if the name
of the function includes uppercase letters, requiring us to use
Ada's "<...>" notation to tell the GDB that the symbol name should
be looked up verbatim.
As of the commit above, GDB is no longer finding the function:
(gdb) break <MixedCaseFunc>
Function "<MixedCaseFunc>" not defined.
Make breakpoint pending on future shared library load? (y or [n])
Before the patch, the breakpoint was inserted without problem.
gdb/testsuite/ChangeLog:
PR gdb/22670
* gdb.ada/bp_c_mixed_case: New testcase.
Tested on x86_64-linux; generates a KPASS before the regression
was introduced, and now generates a KFAIL.
|
|
This patch adds a new test to demonstrate a regression introduced by:
commit b5ec771e60c1a0863e51eb491c85c674097e9e13
Date: Wed Nov 8 14:22:32 2017 +0000
Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching
The original purpose of the new test is to exercise the "complete"
command with an expression for which a large number of matches are
returned and to verify that each match returned is a plausible match.
In this particular case, the commit above causes GDB to generate
additional matches which should in fact not appear in the list
(internally generated symbols, or symbols that should be enclosed
between "<...>"). These extraneous entries are easy to spot, because
they have uppercase characters, such as:
break ada__stringsS
break ada__strings__R11s
[etc]
For now, the new test is KFAIL'ed, to avoid generating a new FAIL
while we work on fixing that regression.
gdb/testsuite/ChangeLog:
PR gdb/22670
* gdb.ada/complete.exp: Add "complete break ada" test.
Tested on x86_64-linux with GDB built before and after the patch
that caused the regression (b5ec771e60c1a0863e51eb491c85c674097e9e13).
The test passes before the regression, and generates a KFAIL after.
|
|
This patch adds a new testcase to demonstrate a regression introduced by:
commit b5ec771e60c1a0863e51eb491c85c674097e9e13
Date: Wed Nov 8 14:22:32 2017 +0000
Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching
The purpose of the testcase is to verify that a user can use any
casing for an Ada symbol name passed to the "info address" command.
After the patch above was applied, GDB was no longer able to find
the symbol:
(gdb) info address My_Table
No symbol "My_Table" in current context.
gdb/testsuite/ChangeLog:
PR gdb/22670
* gdb.ada/info_addr_mixed_case: New testcase.
Tested on x86_64-linux, both before and after the patch.
|
|
When using gdb for debugging Ada source code, there are several catchpoint
types you can define in order to stop upon certain conditions. Let's
use this small example:
procedure Foo is
begin
begin
raise Constraint_Error;
exception
when Program_Error =>
null;
when Constraint_Error =>
null;
when others =>
null;
end;
end Foo;
One can stop when the exception is being raised by using the exception
catchpoint like below:
(gdb) catch exception
Catchpoint 1: all Ada exceptions
(gdb)
In that case, when running Foo, gdb will stop at the line where the exception
was raised:
begin
>>> raise Constraint_Error;
exception
This patch introduces new type of catchpoint, when the user wants to stop
at the location of the exception handling.
Imagine we want to stop on any exception handled by the program, we can do:
(gdb) catch handlers
Catchpoint 1: all Ada exceptions handlers
(gdb) r
Starting program: /tmp/foo
By doing so, when running Foo, gdb will stop here:
Catchpoint 1, exception at 0x000000000040255a in foo () at foo.adb:25
25 when Constraint_Error =>
(gdb)
It is also possible to stop when the Constraint_Error exception is being
handled in this program. With this patch, we can use:
(gdb) catch handlers Constraint_Error
Catchpoint 1: `Constraint_Error' Ada exception handlers
(gdb)
Like for other catchpoint, you can set a condition when adding a catchpoint
on exception handlers.
Here the handlers catchpoint checks Global_Var:
(gdb) catch handlers Constraint_Error if Global_Var /= 0
gdb/ChangeLog:
* ada-lang.h (ada_exception_catchpoint_kind) <ada_catch_handlers>:
Add field.
* ada-lang.c (struct exception_support_info) <catch_handlers_sym>:
Add field.
(default_exception_support_info) <catch_handlers_sym>: Add field.
(exception_support_info_fallback) <catch_handlers_sym>: Add field.
(ada_exception_name_addr_1): Add "catch handlers" handling.
(ada_exception_catchpoint_cond_string) <ex>: New parameter.
Update all callers.
(create_excep_cond_exprs) <ex>: Add parameter.
(re_set_exception): Update create_excep_cond_exprs call.
(print_it_exception, print_one_exception, print_mention_exception)
(print_recreate_exception): Add "catch handler" handling.
(allocate_location_catch_handlers, re_set_catch_handlers)
(check_status_catch_handlers, print_it_catch_handlers)
(print_one_catch_handlers, print_mention_catch_handlers)
(print_recreate_catch_handlers): New function.
(catch_handlers_breakpoint_ops): New variable.
(catch_ada_exception_command_split) <is_catch_handlers_cmd>:
Add parameter. Add "catch handler" handling.
(ada_exception_sym_name, ada_exception_breakpoint_ops):
Add "catch handler" handling.
(ada_exception_catchpoint_cond_string): Add "catch handler"
handling.
(create_ada_exception_catchpoint): Update create_excep_cond_exprs
call.
(catch_ada_handlers_command): New function.
(initialize_ada_catchpoint_ops): Initialize "catch handlers"
operations structure.
(_initialize_ada_language): Add "catch handlers" command entry.
* NEWS: Document "catch handlers" feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Set Catchpoints): Add documentation for new
"catch handlers" action.
gdb/testsuite/ChangeLog:
* gdb.ada/excep_handle.exp: New testcase.
* gdb.ada/excep_handle/foo.adb: New file.
* gdb.ada/excep_handle/pck.ads: New file.
Tested on x86_64-linux.
|
|
My copyright year update in the copyright headers of the step-line
testcase caused it to start failing, due to shift in line numbers.
FAIL: gdb.base/step-line.exp: continue to f1
FAIL: gdb.base/step-line.exp: next to dummy 2
FAIL: gdb.base/step-line.exp: next over dummy 2
FAIL: gdb.base/step-line.exp: step into f2
FAIL: gdb.base/step-line.exp: next over dummy 4
FAIL: gdb.base/step-line.exp: next to dummy 5
FAIL: gdb.base/step-line.exp: next to dummy 6
FAIL: gdb.base/step-line.exp: next over dummy 6
FAIL: gdb.base/step-line.exp: next to dummy 7
FAIL: gdb.base/step-line.exp: next to dummy 8
FAIL: gdb.base/step-line.exp: next over dummy 8
FAIL: gdb.base/step-line.exp: next to dummy 9
FAIL: gdb.base/step-line.exp: next to dummy 10
FAIL: gdb.base/step-line.exp: next over dummy 10
This was caused by the copyright.py script after I changed it to
also update this testcase, which made the following transformation:
- Copyright (C) 2001-2017
- Free Software Foundation, Inc.
+ Copyright (C) 2001-2018 Free Software Foundation, Inc.
We can easily unbreak the testcase without having to go back to
manual edits each year by adding an extra line in the header.
gdb/testsuite/ChangeLog:
* gdb.base/step-line.c: Add extra empty line in copyright header.
* gdb.base/step-line.inp: Likewise.
Tested on x86_64-linux.
|
|
Consider the following Ada code:
procedure Nested (L, U : Integer) is
subtype Small_Type is Integer range L .. U;
type Record_Type (I : Small_Type := L) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
A1 : Array_Type :=
(1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
procedure Discard (R : Record_Type) is
begin
null;
end Discard;
begin
Discard (A1 (1)); -- STOP
end;
Trying to print a slice of that array currently yields:
(gdb) p a1(1..3)
$1 = ((i => 0, s => ""), (i => 0, s => ""), (i => 0, s => ""))
We expected instead:
(gdb) p a1(1..3)
$1 = ((i => 0, s => ""), (i => 1, s => "A"), (i => 2, s => "AB"))
This is because the functions we use in ada-lang.c to create the type
of the array slice (ada_value_slice and ada_value_slice_from_ptr) was
not taking into account the stride of the array. This patch fixes this.
gdb/ChangeLog:
* ada-lang.c (ada_value_slice_from_ptr): Take array stride into
account when creating the array type of the slice.
(ada_value_slice): Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_stride.exp: Add slice test.
Note that, with the current use of ada_value_slice, the enhancement
to handle dynamic array strides seems unnecessary, because I do not
see how an array with a dynamic stride can be referenced by either
by reference or pointer. Since references are coerced to array pointers,
in both cases, the slice is performed by ada_value_slice_from_ptr.
But ada_value_slice is enhanced nonetheless, in the spirit of making
the code more robust, in case we missed something, and also as similar
as possible with its from_ptr counterpart.
tested on x86_64-linux.
|
|
This patch adds support for DW_AT_byte_stride, using Ada as one
example of where this would be useful. However, the implementation
is language-agnostic.
Consider the following Ada code:
procedure Nested (L, U : Integer) is
subtype Small_Type is Integer range L .. U;
type Record_Type (I : Small_Type := L) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
A1 : Array_Type :=
(1 => (I => 0, S => <>),
2 => (I => 1, S => "A"),
3 => (I => 2, S => "AB"));
procedure Discard (R : Record_Type) is
begin
null;
end Discard;
begin
Discard (A1 (1)); -- STOP
end;
It defines an array A1 of Record_Type, which is a variant record
type whose maximum size actually depends on the value of the
parameters passed when calling Nested. As a result, the stride
of the array A1 cannot be known statically, which leads the compiler
to generate a dynamic DW_AT_byte_stride attribute for our type.
Here is what the debugging info looks like with GNAT:
.uleb128 0x10 # (DIE (0x14e) DW_TAG_array_type)
.long .LASF17 # DW_AT_name: "foo__nested__T18b"
.long 0x141 # DW_AT_byte_stride
.long 0xdc # DW_AT_type
.uleb128 0x11 # (DIE (0x15f) DW_TAG_subrange_type)
.long 0x166 # DW_AT_type
.byte 0x3 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x14e
There DW_AT_byte_stride is a reference to a local (internal)
variable:
.uleb128 0x9 # (DIE (0x141) DW_TAG_variable)
.long .LASF6 # DW_AT_name: "foo__nested__T18b___PAD___XVZ"
This patch enhances GDB to handle this dynamic byte stride attribute
by first adding a new dynamic_prop_node_kind (DYN_PROP_BYTE_STRIDE)
to store the array dynamic stride info (when dynamic). It then enhances
the dynamic type resolver to handle this dynamic property.
Before applying this patch, trying to print the value of some of
A1's elements after having stopped at the "STOP" comment does not
work. For instance:
(gdb) p a1(2)
Cannot access memory at address 0x80000268dec0
With this patch applied, GDB now prints the value of all 3 elements
correctly:
(gdb) print A1(1)
$1 = (i => 0, s => "")
(gdb) print A1(2)
$2 = (i => 1, s => "A")
(gdb) print A1(3)
$3 = (i => 2, s => "AB")
gdb/ChangeLog:
* gdbtypes.h (enum dynamic_prop_node_kind) <DYN_PROP_BYTE_STRIDE>:
New enum value.
(create_array_type_with_stride): Add byte_stride_prop parameter.
* gdbtypes.c (create_array_type_with_stride) <byte_stride_prop>:
New parameter. Update all callers in this file.
(array_type_has_dynamic_stride): New function.
(is_dynamic_type_internal, resolve_dynamic_array): Add handling
of arrays with dynamic byte strides.
* dwarf2read.c (read_array_type): Add support for dynamic
DW_AT_byte_stride attributes.
gdb/testsuite/ChangeLog:
* gdb.ada/dyn_stride: New testcase.
Tested on x86_64-linux.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files
|
|
tdesc_register_in_reggroup_p in now able to handle arbitrary
groups. This is useful when groups are created while the
target descriptor file is received from the remote.
This can be the case of a soft core target processor where
registers/groups can change.
gdb/ChangeLog:
yyyy-mm-dd Franck Jullien <franck.jullien@gmail.com>
Stafford Horne <shorne@gmail.com>
* target-descriptions.c (tdesc_register_in_reggroup_p): Support
arbitrary strings.
(tdesc_use_registers): Add logic to register new reggroups.
(tdesc_reg::group): Update comment to indicate we allow
arbitrary strings.
* NEWS (Changes since GDB 8.0): Announce that GDB supports
arbitrary reggroups.
gdb/testsuite/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
* gdb.xml/extra-regs.xml: Add example foo reggroup.
* gdb.xml/tdesc-regs.exp: Add test to check for foo reggroup.
gdb/doc/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
* gdb.texinfo (Target Description Format): Explain that arbitrary
strings are now allowed for register groups.
|
|
Until now this feature has existed but was not documented. Adding docs
and tests.
gdb/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
* infcmd.c (_initialize_infcmd): Add help for info reg $reggroup
and info all-registers $reggroup feature.
gdb/doc/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
* gdb.texinfo (Registers): Document info reg $reggroup feature.
gdb/testsuite/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
* gdb.base/reggroups.c: New file.
* gdb.base/reggroups.exp: New file.
|
|
Doing some unrelated grepping found that there were some missing
spaces, fix it.
|
|
Consider the following Ada code defining a global variable whose
type is an array of static bounds (1 .. 2), but where its elements
are a variant record whose size is not statically known:
type Ints is array (Natural range <>) of Integer;
type Bounded_Ints (Max_Size : Natural) is record
Length : Natural := 0;
Objs : Ints (1 .. Max_Size);
end record;
type Ints_Doubled is array (1 .. 2) of Bounded_Ints (Idem (0));
Global : Ints_Doubled;
When compiling this program at -O2 using a GCC-6.4-based compiler
on x86_64-linux, trying to print the value of that global variable
yields:
(gdb) p global
$1 =
Let's look at the debugging info, which starts with the global
variable itself...
.uleb128 0x19 # (DIE (0x25e) DW_TAG_variable)
.long .LASF32 # DW_AT_name: "fd__global"
.long 0x273 # DW_AT_type
... its type is a reference to a typedef ...
.uleb128 0x14 # (DIE (0x273) DW_TAG_reference_type)
.byte 0x8 # DW_AT_byte_size
.long 0x202 # DW_AT_type
[...]
.uleb128 0x15 # (DIE (0x202) DW_TAG_typedef)
.long .LASF19 # DW_AT_name: "fd__ints_doubled"
.long 0x20d # DW_AT_type
... of an array (1..2) ...
.uleb128 0x2 # (DIE (0x20d) DW_TAG_array_type)
.long .LASF19 # DW_AT_name: "fd__ints_doubled"
.long 0x15b # DW_AT_type
.long 0x221 # DW_AT_sibling
.uleb128 0x16 # (DIE (0x21a) DW_TAG_subrange_type)
.long 0x40 # DW_AT_type
.sleb128 2 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x20d
... of a struct whose name is fd__Tints_doubledC:
.uleb128 0x10 # (DIE (0x15b) DW_TAG_structure_type)
.long .LASF11 # DW_AT_name: "fd__Tints_doubledC"
.long 0x1e4 # DW_AT_GNAT_descriptive_type
# DW_AT_artificial
.long 0x1e4 # DW_AT_sibling
.uleb128 0x7 # (DIE (0x16a) DW_TAG_member)
.long .LASF4 # DW_AT_name: "max_size"
[snip]
The error occurs while Ada evaluator is trying to "fix"
the element type inside the array, so as to determine its actual
size. For that, it searches for a parallel "XVZ" variable,
which, when found, contains the object's actual size.
Unfortunately in our case, the variable exists but has been
optimized out, as seen by the presence of a variable DIE in
the debugging info, but with no address attribute:
.uleb128 0x18 # (DIE (0x24e) DW_TAG_variable)
.long .LASF31 # DW_AT_name: "fd__Tints_doubledC___XVZ"
.long 0x257 # DW_AT_type
# DW_AT_artificial
Discussing this with some members of AdaCore's compiler team,
it is expected that the optimizer can get rid of this variable,
and we don't want to pessimize the code just to improve debuggability,
since -O2 is about performance. So, the idea of this patch is
not to make it work, but provide a bit more information to help
users understand what kind of error is preventing GDB from being
able to print the variable's value.
The first hurdle we had to clear was the fact that ada_val_print
traps all exceptions (including QUIT ones!), and does so completly
silently. So, the fix was to add a trace of the exception being
generated. While doing so, we fix an old XXX/FIXME by only catching
errors, letting QUIT exceptions go through.
Once this is done, we now get an error message, which gives a first
clue as to what was happening:
(gdb) p fd.global
$1 = <error reading variable: value has been optimized out>
However, it would be more useful to know which value it was
that was optimized out. For that purpose, we enhanced
ada-lang.c::ada_to_fixed_type_1 so as to re-throw the error
with a message which indicates which variable we failed to read.
With those changes, the new output is now:
(gdb) p fd.global
$1 = <error reading variable: unable to read value of fd__Tints_doubledC___XVZ (value has been optimized out)>
gdb/ChangeLog:
* ada-lang.c (ada_to_fixed_type_1): Rethrow errors with
a more detailed exception message when getting an exception
while trying to read the value of an XVZ variable.
* ada-valprint.c (ada_val_print): Only catch RETURN_MASK_ERROR
exceptions. Print an error message when an exception is caught.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/ada-valprint-error.c: New file.
* gdb.dwarf2/ada-valprint-error.exp: New file.
Tested on x86_64-linux
|
|
Consider the following code, which declares a variabled called "input"
of type "parameter", which is a record with one component called "u2",
where the type of that component is a simple 3-element array of
floating point values:
type Float_Array_3 is array (1 .. 3) of Float;
type parameters is record
u2 : Float_Array_3;
end record;
input : parameters;
Trying to assign a value to input.u2 causes GDB to crash:
(gdb) p input.u2 := (0.25,0.5,0.75)
[1] 20228 segmentation fault (core dumped) [...]/gdb
The crash occurs because input.u2 is described in the debugging
info as a typedef of an array. Indeed, input's type is:
<1><ae9>: Abbrev Number: 7 (DW_TAG_structure_type)
<aea> DW_AT_name : (indirect string, offset: 0x1045): target_wrapper__parameters
[...]
<2><af5>: Abbrev Number: 8 (DW_TAG_member)
<af6> DW_AT_name : u2
[...]
<afb> DW_AT_type : <0xaca>
and, looking at DIE 0xaca to get input.u2's type, we see:
<1><aca>: Abbrev Number: 4 (DW_TAG_typedef)
<acb> DW_AT_name : (indirect string, offset: 0x1060): target_wrapper__float_array_3
[...]
<ad1> DW_AT_type : <0xad5>
We can also confirm, following the DW_AT_type attribute (0xad5), that
it's a typedef of our array:
<1><ad5>: Abbrev Number: 5 (DW_TAG_array_type)
<ad6> DW_AT_name : (indirect string, offset: 0x1060): target_wrapper__float_array_3
[...]
In fact, this scenario uncovered 2 areas where typedef handling
is missing, thus causing a crash. The first happens inside
assign_aggregate:
if (ada_is_direct_array_type (lhs_type))
{
lhs = ada_coerce_to_simple_array (lhs);
lhs_type = value_type (lhs);
low_index = TYPE_ARRAY_LOWER_BOUND_VALUE (lhs_type);
high_index = TYPE_ARRAY_UPPER_BOUND_VALUE (lhs_type);
}
Here, lhs_type is a TYPE_CODE_TYPEDEF. ada_is_direct_array_type
knows how to handle it, but TYPE_ARRAY_LOWER_BOUND_VALUE assumes
that the given type is a TYPE_CODE_ARRAY. As such, it ends up
accessing some fields in lhs_type which it shouldn't, and kaboom.
We fixed this issue by making sure that the TYPE_CODE_TYPEDEF
layer gets stripped.
Once this is done, we hit a different kind of error, also leading to
a SEGV, this time in assign_component. The code looks like this:
if (TYPE_CODE (value_type (lhs)) == TYPE_CODE_ARRAY)
[...]
else
[...]
Because once again lhs is a TYPE_CODE_TYPEDEF, the check fail,
and we end up assuming that lhs is a struct, executing the "else"
block, which is:
else
{
elt = ada_index_struct_field (index, lhs, 0, value_type (lhs));
elt = ada_to_fixed_value (elt);
}
Since lhs is not a struct, ada_index_struct_field returns NULL,
which ada_to_fixed_value does not handle well, hence another crash.
This patch fixes this other issue the same way, by stripping
TYPE_CODE_TYPEDEF layers.
gdb/ChangeLog:
* ada-lang.c (assign_component): Strip any TYPE_CODE_TYPEDEF
layer from lhs' type.
(assign_aggregate): Likewise.
gdb/testsuite:
* gdb.ada/assign_arr: New testcase.
Tested on x86_64-linux.
|
|
Using this small example:
procedure Foo is
type Integer_Access is access all Integer;
procedure P (A : Integer_Access) is
begin
null;
end P;
begin
P (null);
end Foo;
and doing this debug session:
(gdb) b p
Breakpoint 1 at 0x402d67: file foo.adb, line 7.
(gdb) print p(null)
Breakpoint 1, foo.p (a=0x641010) at foo.adb:10
... ^^^^^^^^^^
shows that something goes wrong between the initial null value and the
received parameter value in the 'f' function.
The value for the parameter 'a' we get is the address of the value we
would expect instead of the value itself. This can be checked by doing:
(gdb) p *a
$1 = 0
Before this fix, in ada_convert_value, this function was looking to the
actual value (the null value here) to determine if the formal (parameter
'a' in the procedure 'P' in this exemple) requires a pointer or not which
is a wrong assumption and leads to push the address of the value to the
inferior instead of the value itself.
This is fixed by this patch.
gdb/ChangeLog:
* ada-lang.c (ada_convert_actual): Change the way actual value
are passed to the inferior when the inferior expects a pointer type.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_ptr: New testcase.
Tested on x86_64-linux.
|
|
This commit implements the pahole-like '/o' option for 'ptype', which
prints the offsets and sizes of struct fields, reporting whenever
there is a hole found.
The output is heavily based on pahole(1), with a few modifications
here and there to adjust it to our reality. Here's an example:
/* offset | size */ type = struct wer : public tuv {
public:
/* 32 | 24 */ struct tyu {
/* 32:31 | 4 */ int a1 : 1;
/* 32:28 | 4 */ int a2 : 3;
/* 32: 5 | 4 */ int a3 : 23;
/* 35: 3 | 1 */ char a4 : 2;
/* XXX 3-bit hole */
/* XXX 4-byte hole */
/* 40 | 8 */ int64_t a5;
/* 48:27 | 4 */ int a6 : 5;
/* 48:56 | 8 */ int64_t a7 : 3;
/* total size (bytes): 24 */
} a1;
/* total size (bytes): 56 */
}
A big part of this patch handles the formatting logic of 'ptype',
which is a bit messy. The code to handle bitfield offsets, however,
took some time to craft. My thanks to Pedro Alves for figuring things
out and pointing me to the right direction, as well as coming up with
a way to inspect the layout of structs with bitfields (see testcase
for comments).
After many discussions both on IRC and at the mailing list, I tried to
implement printing vtables and inherited classes. Unfortunately the
code grew too complex and there were still a few corner cases failing
so I had to drop the attempt. This should be implemented in a future
patch.
This patch is the start of a long-term work I'll do to flush the local
patches we carry for Fedora GDB. In this specific case, I'm aiming at
upstreaming the feature implemented by the 'pahole.py' script that is
shipped with Fedora GDB:
<https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-archer.patch#_311>
This has been regression-tested on the BuildBot. There's a new
testcase for it, along with an update to the documentation. I also
thought it was worth mentioning this feature in the NEWS file.
gdb/ChangeLog:
2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
PR cli/16224
* NEWS (Changes since GDB 8.0): Mention new '/o' flag.
* c-typeprint.c (OFFSET_SPC_LEN): New define.
(c_type_print_varspec_prefix): New argument 'struct
print_offset_data *'.
(c_type_print_base_1): New function and prototype.
(c_print_type_1): New function, with code from 'c_print_type'.
(c_print_type): Use 'c_print_type_1'.
(c_type_print_varspec_prefix): New argument 'struct
print_offset_data *'. Use it. Call 'c_type_print_base_1'
instead of 'c_print_type_base'.
(print_spaces_filtered_with_print_options): New function.
(output_access_specifier): Take new argument FLAGS. Modify
function to call 'print_spaces_filtered_with_print_options'.
(c_print_type_vtable_offset_marker): New function.
(c_print_type_union_field_offset): New function.
(c_print_type_struct_field_offset): New function.
(c_print_type_no_offsets): New function.
(c_type_print_base_struct_union): New argument 'struct
print_offset_data *'. Print offsets and sizes for
struct/union/class fields.
* typeprint.c (const struct type_print_options
type_print_raw_options): Initialize 'print_offsets'.
(static struct type_print_options default_ptype_flags):
Likewise.
(struct print_offset_data print_offset_default_data): New
variable.
(whatis_exp): Handle '/o' option.
(_initialize_typeprint): Add '/o' flag to ptype's help.
* typeprint.h (struct print_offset_data): New struct.
(struct type_print_options) <print_offsets>: New field.
gdb/testsuite/ChangeLog:
2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/16224
* gdb.base/ptype-offsets.cc: New file.
* gdb.base/ptype-offsets.exp: New file.
gdb/doc/ChangeLog:
2017-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/16224
* gdb.texinfo (ptype): Add documentation for new flag '/o'.
|
|
I see the following test failure when gdb is configured without XML
support,
maintenance check xml-descriptions binutils-gdb/gdb/testsuite/../features
warning: Can not parse XML target description; XML support was disabled at compile time^M
Tested 29 XML files, 29 failed
(gdb) FAIL: gdb.gdb/unittest.exp: maintenance check xml-descriptions ${srcdir}/../features
gdb/testsuite:
2017-12-15 Yao Qi <yao.qi@linaro.org>
* gdb.gdb/unittest.exp: Skip 'maintenance check xml-descriptions'
if XML is disabled.
|
|
Consider the following code:
type Top_T is tagged record
N : Integer := 1;
U : Integer := 974;
A : Integer := 48;
end record;
type Middle_T is new Top.Top_T with record
N : Character := 'a';
C : Integer := 3;
end record;
type Bottom_T is new Middle.Middle_T with record
N : Float := 4.0;
C : Character := '5';
X : Integer := 6;
A : Character := 'J';
end record;
Tagged records in Ada provide object-oriented features, and what
is interesting in the code above is that a child tagged record
introduce additional components (fields) which sometimes have
the same name as one of the components in the parent. For instance,
Bottom_T introduces a component named "C", while at the same time
inheriting from Middle_T which also has a component named "C";
so, in essence, type Bottom_T has two components with the same name!
And before people start wondering why the language can possibly
be allowing that, this can only happen if the parent type has
a private definition. In our case, this was brought to our attention
when the parent was a generic paramenter.
With that in mind... Let's say we now have a variable declared
and initialized as follow:
TC : Top_A := new Bottom_T;
And then we use this variable to call this function
procedure Assign (Obj: in out Top_T; TV : Integer);
as follow:
Assign (Top_T (B), 12);
Now, we're in the debugger, and we're inside that procedure
(Top.Assign in our gdb testcase), and we want to print
the value of obj.c:
Usually, the tagged record or one of the parent type owns the
component to print and there's no issue but in this particular
case, what does it mean to ask for Obj.C ? Since the actual
type for object is type Bottom_T, it could mean two things: type
component C from the Middle_T view, but also component C from
Bottom_T. So in that "undefined" case, when the component is
not found in the non-resolved type (which includes all the
components of the parent type), then resolve it and see if we
get better luck once expanded.
In the case of homonyms in the derived tagged type, we don't
guaranty anything, and pick the one that's easiest for us
to program.
This patch fixes the behavior like described above.
gdb/ChangeLog:
* ada-lang.c (ada_value_primitive_field): Handle field search
in case of homonyms.
(find_struct_field): Ditto.
(ada_search_struct_field): Ditto.
(ada_value_struct_elt): Ditto.
(ada_lookup_struct_elt_type): Ditto.
gdb/testsuite/ChangeLog:
* gdb.ada/same_component_name: New testcase.
Tested on x86_64-linux.
|
|
Consider the following Ada Code:
type Str is new String (1 .. 4);
My_str : Str := "ABCD";
This simply declares a 4-character string type. Trying to perform
equality tests using it currently yield an error:
(gdb) p my_str = my_str
Attempt to compare array with non-array
(gdb) p my_str = "ABCD"
Attempt to compare array with non-array
The error occurs because my_str is defined as an object whose
type is a typdef to a TYPE_CODE_ARRAY, which ada_value_equal
is not expecting at all (yet). This patch fixes this oversight.
gdb/ChangeLog:
* ada-lang.c (ada_value_equal): Add handling of typedef types
when comparing array objects.
gdb/testsuite/ChangeLog:
* gdb.ada/str_binop_equal: New testcase.
Tested on x86_64-linux.
|
|
The reasons for not supporting task switching when debugging core files
appear to now mostly be OBE. In particular, on GNU/Linux, the thread
layer is now able to retrieve the same thread info as in the live
process. So, this patch is mostly about just removing the guard
that limited the use of task switching to live processes.
gdb/ChangeLog:
* ada-tasks.c (read_atcb): Properly set task_info->ptid
when !target_has_execution as well.
(task_command): Remove error when !target_has_execution.
gdb/testsuite/ChangeLog:
* gdb.ada/task_switch_in_core: New testcase.
|
|
This patch adds the possibility to pass a qualified=True|False parameter
when creating a breakpoint in Python. It is equivalent to using
-qualified in a linespec. The parameter actually accepts any Python
value, and converts it to boolean using Python's standard rules for
that (https://docs.python.org/3/library/stdtypes.html#truth).
Unlike the -source/-line/-function/-label parameters, it is possible to
use -qualified with a "normal" (non-explicit) linespec. Therefore, it
is possible (unlike these other parameters) to use this new parameter
along with the spec parameter.
I updated the py-breakpoint.exp test. To be able to test multiple
locations using a namespace, I had to switch the test case to compile as
C++. If we really wanted to, we could run it as both C and C++, but
omit the C++-specific parts when running it as C.
gdb/ChangeLog:
* location.h (string_to_event_location): Add match_type
parameter.
* location.c (string_to_event_location): Likewise.
* python/py-breakpoint.c (bppy_init): Handle qualified
parameter.
gdb/doc/ChangeLog:
* python.texi (Manipulating breakpoints using Python): Document
qualified parameter to gdb.Breakpoint.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.c (foo_ns::multiply): New function.
* gdb.python/py-breakpoint.exp: Compile the test case as c++,
call test_bkpt_qualified.
(test_bkpt_qualified): New proc.
|
|
While writing the tests included in the previous commit, I noticed
that test_gdb_complete_tab_multiple would not FAIL if GDB happens to
show more completions than expected before the expected list.
E.g., with something like this, expecting "p foo" to complete to
"foo2" and "foo3":
test_gdb_complete_tab_multiple "p foo" "" {
"foo2"
"foo3"
}
and then if foo actually completes to:
(gdb) p foo[TAB]
foo1 foo2 foo3
^^^^
we'd still PASS. (Note the spurious "foo1" above.)
This tightens the regexp with a beginning anchor thus making the
completions above cause a FAIL. Other similar functions in
completion-support.exp already do something like this; I had just
missed this one originally. Thankfully, this did not expose any
problems in the gdb.linespec/ tests. Phew.
gdb/testsuite/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* lib/completion-support.exp (test_gdb_complete_tab_multiple):
Tighten regexp by matching with an anchor.
|
|
I noticed this regression in the expression completer:
"(gdb) p std::[TAB]" => "(gdb) p std::std::"
obviously we should have not completed to "std::std::".
The problem is that in the earlier big completer rework, I missed
taking into account the fact that with expressions, the completion
word point is not always at the start of the symbol name (it is with
linespecs).
The fix is to run the common prefix / LCD string (what readline uses
to expand the input line) through make_completion_match_str too.
New testcase included, exercising both TAB completion and the complete
command.
gdb/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* completer.c (completion_tracker::maybe_add_completion): New
'text' and 'word' parameters. Use make_completion_match_str.
(completion_tracker::add_completion): New 'text' and 'word'
parameters. Pass down.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref. Adjust.
* completer.h (completion_tracker::add_completion): New 'text' and
'word' parameters.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref.
* symtab.c (completion_list_add_name): Pass down 'text' and 'word'
as well.
gdb/testsuite/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* gdb.cp/cpcompletion.exp: Load completion-support.exp.
("expression with namespace"): New set of tests.
* gdb.cp/pr9594.cc (Test_NS::foo, Test_NS::bar)
(Nested::Test_NS::qux): New.
* lib/completion-support.exp (test_gdb_complete_cmd_multiple): Add
defaults to 'start_quote_char' and 'end_quote_char' parameters.
|
|
The "server" command prefix no longer turns confirmation queries off.
We can reproduce this with any program by tring to delete all breakpoints,
for instance:
(gdb) break main
Breakpoint 1 at 0x40049b: file /[...]/break-fun-addr1.c, line 21.
(gdb) server delete breakpoints
Delete all breakpoints? (y or n)
GDB should not be asking "Delete all breakpoints? (y or n)", but
instead just delete all breakpoints without asking for confirmation.
Looking at utils.c::defaulted_query gives a glimpse of how this feature
is expected to work:
/* Automatically answer the default value if the user did not want
prompts or the command was issued with the server prefix. */
if (!confirm || server_command)
return def_value;
So, it relies on the server_command global to be set when the "server "
command prefix is used, which is no longer the case since the following
commit:
commit b69d38afdea34e4fecab5ea47ffe1e594e0b6233
Date: Wed Mar 9 18:25:00 2016 +0000
Subject: Command line input handling TLC
The patch was simplifying the handling for the command line, and
I believe there was just a small oversight of removing the setting
of the server_command global.
This patch restores that, and adds a testcase to make sure we test
that feature.
gdb/ChangeLog:
* event-top.c (handle_line_of_input): Set server_command.
gdb/testsuite/ChangeLog:
* gdb.base/server-del-break.c: New file.
* gdb.base/server-del-break.exp: New file.
Tested on x86_64-linux, no regression.
|
|
gdb/testsuite/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
* gdb.xml/tdesc-regs.exp: Add or1k support.
|
|
The test case requires adding a nop instruction. For or1k the
instruction is `l.nop`. This change uses the correct operation.
gdb/testsuite/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
* gdb.base/bp-permanent.c: Define nop of or1k.
|
|
Recent versions of GNAT are capable of reordering record components
to make their access for efficient. This patch adapts this test to
accept both cases (reordered or not).
gdb/testsuite/ChangeLog:
* gdb.ada/variant_record_packed_array.exp: Adapt test to accept
output with components being reordered.
Tested on x86_64-linux.
|
|
Recent versions of GNAT are capable of reordering record components
to make their access for efficient. This patch adapts this test to
accept both cases (reordered or not).
gdb/testsuite/ChangeLog:
* gdb.ada/pkd_arr_elem.exp: Adapt "print test" test to accept
output with components being reordered.
|
|
Some testcases needed to be updated as they were missing
.debug_aranges. While that does not matter for no-index (as GDB
builds the mapping internally during dwarf2_build_psymtabs_hard) and
neither for .gdb_index (as GDB uses that internally built mapping
which it stores into .gdb_index) it does matter for .debug_names as
that simply assumes existing .debug_aranges from GCC.
gdb/ChangeLog:
2017-12-08 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* defs.h (elf_sym_fns_debug_names): New declaration.
* dwarf2read.c: Include "hash_enum.h".
(mapped_debug_names): New.
(struct dwarf2_per_objfile): Add debug_names, debug_aranges and
debug_names_table.
(dwarf2_elf_names): Add ".debug_names" and ".debug_aranges".
(struct dwz_file): Add debug_names.
(dwarf2_per_objfile::locate_sections): Handle debug_names and
debug_aranges.
(locate_dwz_sections): Handle debug_names.
(create_signatured_type_table_from_debug_names)
(create_addrmap_from_aranges): New.
(dwarf2_read_index): Update function comment.
(dwarf5_augmentation): Moved up.
(read_debug_names_from_section, create_cus_from_debug_names_list)
(create_cus_from_debug_names, dwarf2_read_debug_names): New.
(dwarf5_djb_hash): Moved up.
(dw2_debug_names_iterator): New.
(read_indirect_string_at_offset): New declaration.
(mapped_debug_names::namei_to_name)
(dw2_debug_names_iterator::find_vec_in_debug_names)
(dw2_debug_names_iterator::next, dw2_debug_names_lookup_symbol)
(dw2_debug_names_dump, dw2_debug_names_expand_symtabs_for_function)
(dw2_debug_names_expand_symtabs_matching, dwarf2_debug_names_functions):
New.
(dwarf2_initialize_objfile): Return also elf_sym_fns_debug_names.
(debug_names::djb_hash): Rename it to dwarf5_djb_hash.
(debug_names::build): Update djb_hash caller.
(write_debug_names): Move out and rename augmentation to
dwarf5_augmentation.
* elfread.c (elf_sym_fns_debug_names): New.
* psymtab.h (dwarf2_debug_names_functions): New declaration.
* symfile.h (struct dwarf2_debug_sections): Add debug_names and
debug_aranges.
* xcoffread.c (dwarf2_xcoff_names): Add debug_names and debug_aranges.
gdb/testsuite/ChangeLog:
2017-12-08 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.base/maint.exp (check for .gdb_index): Check also for
.debug_names.
* gdb.dlang/watch-loc.c (.debug_aranges): New.
* gdb.dwarf2/dw2-case-insensitive-debug.S: Likewise.
* gdb.dwarf2/gdb-index.exp (check if index present, .gdb_index used)
(.gdb_index used after symbol reloading): Support also .debug_names.
* gdb.mi/dw2-ref-missing-frame-func.c (.debug_aranges): New.
|
|
Nowadays, GDB can't set watchpoint on tagged address on AArch64,
(gdb) p p2
$1 = (int *) 0xf000fffffffff474
(gdb) watch *((int *) 0xf000fffffffff474)
Hardware watchpoint 2: *((int *) 0xf000fffffffff474)
(gdb) c
Continuing.
main () at
binutils-gdb/gdb/testsuite/gdb.arch/aarch64-tagged-pointer.c:45
45 void (*func_ptr) (void) = foo;
Unexpected error setting hardware debug registers
This patch is about setting watchpoint on a tagged address. Unlike
breakpoint, watchpoint record the expression rather than the address, and
when a watchpoint is fired, GDB checks the expression value changed
instead of matching address, so we can mask the watchpoint address by
getting rid of non-significant bits of address.
gdb:
2017-12-08 Yao Qi <yao.qi@linaro.org>
* breakpoint.c (update_watchpoint): Call
address_significant.
gdb/testsuite:
2017-12-08 Yao Qi <yao.qi@linaro.org>
* gdb.arch/aarch64-tagged-pointer.c (main): Update.
* gdb.arch/aarch64-tagged-pointer.exp: Add tests for watchpoint.
|
|
Tag in tagged address on AArch64 is treated as a non-significant bits of
address, which can be got by gdbarch method significant_addr_bit, and gdb
can clear these bits.
With this patch, when user sets a breakpoint on tagged address on AArch64,
GDB will drop the top byte of address, and put breakpoint at the new place,
as shown below,
(gdb) hbreak *func_ptr
warning: Breakpoint address adjusted from 0xf000000000400690 to 0x00400690.
Hardware assisted breakpoint 2 at 0x400690
(gdb) break *func_ptr
warning: Breakpoint address adjusted from 0xf000000000400690 to 0x00400690.
Breakpoint 3 at 0x400690
When program hits a breakpoint, the stopped pc reported by Linux kernel is
the address *without* tag, so it is better the address recorded in
breakpoint location is the one without tag too, so we can still match
breakpoint location address and stopped pc reported by Linux kernel, by
simple compare.
gdb:
2017-12-08 Yao Qi <yao.qi@linaro.org>
* breakpoint.c (adjust_breakpoint_address): Call
address_significant.
gdb/testsuite:
2017-12-08 Yao Qi <yao.qi@linaro.org>
* gdb.arch/aarch64-tagged-pointer.c (main): Update.
* gdb.arch/aarch64-tagged-pointer.exp: Add test for breakpoint.
|
|
ARMv8 supports tagged address, that is, the top one byte in address
is ignored. It is always enabled on aarch64-linux. See
https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt
The tag in the tagged address is modeled as non-significant bits in
address, so this patch adds a new gdbarch method significant_addr_bit and
clear the non-significant bits (the top byte in ARMv8) of the virtual
address at the point before passing address to target cache layer. IOW,
the address used in the target cache layer is already cleared.
Before this patch,
(gdb) x/x 0x0000000000411030
0x411030 <global>: 0x00000000
(gdb) x/x 0xf000000000411030
0xf000000000411030: Cannot access memory at address 0xf000000000411030
After this patch,
(gdb) x/x 0x0000000000411030
0x411030 <global>: 0x00000000
(gdb) x/x 0xf000000000411030
0xf000000000411030: 0x00000000
Note that I used address_significant in paddress, but it causes a
regression gdb.base/long_long.exp, because gdb clears the non-significant
bits in address, but test still expects them.
p/a val.oct^M
$24 = 0x2ee53977053977^M
(gdb) FAIL: gdb.base/long_long.exp: p/a val.oct
so I defer the change there.
gdb:
2017-12-08 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_gdbarch_init): Install gdbarch
significant_addr_bit.
* gdbarch.sh (significant_addr_bit): New.
* gdbarch.c, gdbarch.h: Re-generated.
* target.c (memory_xfer_partial): Call address_significant.
* utils.c (address_significant): New function.
* utils.h (address_significant): Declare.
2017-12-08 Yao Qi <yao.qi@linaro.org>
gdb/testsuite:
* gdb.arch/aarch64-tagged-pointer.c: New file.
* gdb.arch/aarch64-tagged-pointer.exp: New file.
|
|
Since:
commit 7022349d5c86bae74b49225515f42d2e221bd368
Author: Pedro Alves <palves@redhat.com>
Date: Mon Sep 4 20:21:13 2017 +0100
Stop assuming no-debug-info functions return int
We now have to explicitly tell GDB the type of the non-debug-info
function we want to print (by casting). This commit adjusts the
"print" statement on gdb.arch/i386-sse-stack-align.exp to do the
proper cast, fixing a failure that started to happen after the
mentioned commit.
gdb/testsuite/ChangeLog:
2017-12-08 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/i386-sse-stack-align.exp: Cast "print" function call
"int".
|
|
breakpoints/22569 involves an internal error generated by the rather
innocent looking command:
(gdb) break -source test.cpp main
.../linespec.c:3302: internal-error: void decode_line_full(...):
Assertion `result.size () == 1 || canonical->pre_expanded' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The input string is tokenized into "-source", "test.cpp", and "main"
(input parsing breaks on whitespace). create_breakpoint is then called with
the explicit location (containing only the source file name) and "main" as
the extra_string argument.
No SaLs are created for this underspecified explicit location, and the
"result.size () == 1" evaluates false (as does the pre_expanded condition).
This triggers the assertion.
Normally string_to_explicit_location validates the input string. However,
the presence of the string "main" causes the parser to exit early:
802 else
803 {
804 /* End of the explicit location specification.
805 Stop parsing and return whatever explicit location was
806 parsed. */
807 *argp = start;
808 return location;
809 }
This bypasses the validation that is done a few lines down in this function
which would have emitted the expected error. This patch fixes that.
Additionally, this patch also fixes an inconsistency with error reporting
in this use case:
(gdb) b -source foo
Source filename requires function, label, or line offset.
(gdb) b -source foo main
No source file named foo.
These two commands should have elicited the same error message.
gdb/ChangeLog:
PR breakpoints/22569
* location.c (string_to_explicit_location): When terminating
parsing early, break out of enclosing loop instead of returning.
gdb/testsuite/ChangeLog:
PR breakpoints/22569
* gdb.linespec/ls-errs.exp: Change expected result of "break
-source this file has spaces.c -line 3".
Check that an explicit source file followed by whitespace is
identified as an invalid explicit location.
|
|
GDB currently does not track types defined in classes. Consider:
class A
{
public:
class B
{
public:
class C { };
};
};
(gdb) ptype A
type = class A {
<no data fields>
}
This patch changes this behavior so that GDB records these nested types
and displays them to the user when he has set the (new) "print type"
option "nested-type-limit."
Example:
(gdb) set print type nested-type-limit 1
(gdb) ptype A
type = class A {
<no data fields>
class A::B {
<no data fields>
};
}
(gdb) set print type nested-type-limit 2
type = class A {
<no data fields>
class A::B {
<no data fields>
class A::B::C {
<no data fields>
};
};
}
By default, the code maintains the status quo, that is, it will not print
any nested type definitions at all.
Testing is carried out via cp_ptype_class which required quite a bit of
modification to permit recursive calling (for the nested types). This
was most easily facilitated by turning the ptype command output into a
queue. Upshot: the test suite now has stack and queue data structures that
may be used by test writers.
gdb/ChangeLog
* NEWS (New commands): Mention set/show print type nested-type-limit.
* c-typeprint.c (c_type_print_base): Print out nested types.
* dwarf2read.c (struct typedef_field_list): Rename to ...
(struct decl_field_list): ... this. Change all uses.
(struct field_info) <nested_types_list, nested_types_list_count>:
New fields.
(add_partial_symbol): Look for nested type definitions in C++, too.
(dwarf2_add_typedef): Rename to ...
(dwarf2_add_type_defn): ... this.
(type_can_define_types): New function.
Update assertion to use type_can_define_types.
Permit NULL for a field's name.
(process_structure_scope): Handle child DIEs of types that can
define types.
Copy the list of nested types into the type struct.
* gdbtypes.h (struct typedef_field): Rename to ...
(struct decl_field): ... this. Change all uses.
[is_protected, is_private]: New fields.
(struct cplus_struct_type) <nested_types, nested_types_count>: New
fields.
(TYPE_NESTED_TYPES_ARRAY, TYPE_NESTED_TYPES_FIELD)
(TYPE_NESTED_TYPES_FIELD_NAME, TYPE_NESTED_TYPES_FIELD_TYPE)
(TYPE_NESTED_TYPES_COUNT, TYPE_NESTED_TYPES_FIELD_PROTECTED)
(TYPE_NESTED_TYPES_FIELD_PRIVATE): New macros.
* typeprint.c (type_print_raw_options, default_ptype_flags): Add
default value for print_nested_type_limit.
(print_nested_type_limit): New static variable.
(set_print_type_nested_types, show_print_type_nested_types): New
functions.
(_initialize_typeprint): Register new commands for set/show
`print-nested-type-limit'.
* typeprint.h (struct type_print_options) [print_nested_type_limit]:
New field.
gdb/testsuite/ChangeLog
* gdb.cp/nested-types.cc: New file.
* gdb.cp/nested-types.exp: New file.
* lib/cp-support.exp: Load data-structures.exp library.
(debug_cp_test_ptype_class): New global.
(cp_ptype_class_verbose, next_line): New procedures.
(cp_test_ptype_class): Add and document new parameter `recursive_qid'.
Add and document new return value.
Switch the list of lines to a queue.
Add support for new `type' key for nested type definitions.
Add debugging/troubleshooting messages.
* lib/data-structures.exp: New file.
gdb/doc/ChangeLog
* gdb.texinfo (Symbols): Document "set print type nested-type-limit"
and "show print type nested-type-limit".
|
|
The prefix in test_bkpt_explicit_loc is wrong. Instead of using
with_test_prefix directly, define test_bkpt_explicit_loc with
proc_with_prefix.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.exp (test_bkpt_explicit_loc): Define
with proc_with_prefix, don't use with_test_prefix.
|
|
Pedro pointed out a regression in "commands", where trying to clear a
breakpoint's command list would fail:
(top-gdb) commands
Type commands for breakpoint(s) 3, one per line.
End with a line saying just "end".
>end
No breakpoints specified.
(top-gdb)
I believe the bug was introduced by my patch that changes
counted_command_line to be a shared_ptr. This causes the problem
because now the counted_command_line in commands_command_1 can be NULL,
whereas previously it never could be.
After some discussion, we agreed to simply remove the error case from
commands_command_1.
2017-12-07 Tom Tromey <tom@tromey.com>
PR breakpoints/22511:
* breakpoint.c (commands_command_1): Don't throw an exception when
no commands have been read.
2017-12-07 Tom Tromey <tom@tromey.com>
* gdb.base/break.exp: Add test for empty "commands".
|
