ctxobj.exp fails randomly when computer is loaded.
With the addition of $gdb_prompt in the regexp testing for breakpoint hit,
I could not make it fail anymore.
Also fixed a typo in a comment.
This implements the request given in PR breakpoints/12464.
Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5
This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5
In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.
Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.
$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
disable $_hit_bpnum.$_hit_locno
In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.
This also fixes a strange behaviour: when a breakpoint X has only
one location,
enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.
The changes in RFA v4 handle the comments of Tom Tromey:
- Changed convenience var names from $bkptno/$locno to
$_hit_bpnum/$_hit_locno.
- updated the tests and user manual accordingly.
User manual also explictly describes that $_hit_locno is set to 1
for a breakpoint with a single location.
- The variable values are now set in bpstat_do_actions_1 so that
they are set for silent breakpoints, and when several breakpoints
are hit at the same time, that the variables are set to the printed
breakpoint.
The changes in RFA v3 handle the additional comments of Eli:
GDB/NEW:
- Use max 80-column
- Use 'code location' instead of 'location'.
- Fix typo $bkpno
- Ensure that disable $bkptno and disable $bkptno.$locno have
each their explanation inthe example
- Reworded the 'breakpoint-hit' paragraph.
gdb.texinfo:
- Use 'code location' instead of 'location'.
- Add a note to clarify the distinction between $bkptno and $bpnum.
- Use @kbd instead of examples with only one command.
Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
- Use %s for the result of paddress
- Use bkptno_numopt_re instead of 2 different -re cases
- use C@t{++}
- Add index entries for $bkptno and $locno
- Added an example for "locno" in the mi interface
- Added examples in the Break command manual.
I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp test was
failing when run with Clang as the compiler.
This test relies on the compiled binaries having a build-id within
them. For GCC, really GNU ld, the default is to always include a
build-id.
When compiling with Clang though, the default is for no build-id.
I did consider *always* turning on the build-id feature when the
compiler is Clang, but that felt a little weird.
Instead, I propose that we add a new 'build-id' compiler option to
gdb_compile, this flag indicates that the test _requires_ a build-id.
In gcc_compile we can then add the required flags if the compiler is
Clang so that we do get a build-id.
With this change the gdb.debuginfod/fetch_src_and_symbols.exp test
now (mostly) passes with Clang 9.0.1 and 15.0.2, and still passes with
gcc. The 'mostly' part is an unrelated issue, and will be addressed
in a later commit in this series.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
I noticed in test-case gdb.arch/i386-biarch-core.exp that we run into the
completion limit for "complete set gnutarget":
...
set gnutarget vms-libtxt^M
set gnutarget *** List may be truncated, max-completions reached. ***^M
(gdb) PASS: gdb.arch/i386-biarch-core.exp: complete set gnutarget
...
Fix this by using get_set_option_choices.
Also use get_set_option_choices for "complete set architecture i386", which
required extending get_set_option_choices to accept a second argument, such
that we can do:
...
set archs [get_set_option_choices "set architecture" "i386"]
...
because this returns an empty list:
...
set archs [get_set_option_choices "set architecture i386"]
...
because it does "complete set architecture i386 ".
Also clean up the explicit gdb_exit/gdb_start and use clean_restart instead.
Tested on x86_64-linux.
After de-installing bzip2, I run into:
...
Running ppc64-symtab-cordic.exp ...
sh: bzip2: command not found
PATH: gdb.arch/ppc64-symtab-cordic.exp: failed bzip2 for \
src/gdb/testsuite/gdb.arch/cordic.ko.bz2
...
Fix these by:
- using remote_exec instead of catch system, and
- using file tail in the untested message.
I've tried making output redirection work with remote_exec, but that seems to
be broken, so we now:
- copy the file $f.bz2 into the desired location $dir/$f.bz2, and
- decompress the bz2 file using "bzip2 -df $dir/$f.bz2", resulting in a file
$dir/$f.
Factor out new function decompress_bz2 to make the test-case less verbose, and
also use it in gdb.arch/i386-biarch-core.exp.
Tested on x86_64-linux, without and with bzip2 installed.
I get some random failures since commit 8d45c3a82a ("[gdb/testsuite]
Set completions to unlimited in get_set_option_choices"), which can be
reproduced with:
$ make check-read1 TESTS="gdb.base/parse_number.exp"
For instance:
set architecture A^M
Ambiguous item "A".^M
(gdb) FAIL: gdb.base/parse_number.exp: arch=A: set architecture A
The problem is the regexp in get_set_option_choices, it is possible that
is only matches part of a completion result. With check-read1, that is
always one letter.
Fix this by expecting the \r\n at the end of the line, so we only match
entire results. Use ^ in match patterns to ensure we don't miss any
output.
Approved-By: Tom de Vries <tdevries@suse.de>
Change-Id: Ib1733737feab7dde0f7095866e089081a891054e
When running test-case gdb.base/print-file-var.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix these by using the name of a shared lib as returned by gdb_load_shlib.
This required splitting up the gdb_load_shlib functionality, which is now
defined as:
...
proc gdb_load_shlib { file } {
set dest [gdb_download_shlib $file]
gdb_locate_shlib $file
return $dest
}
...
such that we can do gdb_download_shlib before gdb is started.
Tested on x86_64-linux.
Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
On aarch64-linux, with a gdb build without libexpat, so without xml support, I
run into:
...
(gdb) builtin_spawn attach-no-multi-process^M
attach 26808^M
Attaching to Remote target^M
warning: Can not parse XML target description; XML support was disabled at \
compile time^M
Reading symbols from attach-no-multi-process...^M
Remote 'g' packet reply is too long (expected 788 bytes, got 796 bytes): ... ^M
...
The test-case checks for skip_gdbserver_tests and that one contains a check
for xml support:
...
# If GDB is lack of XML support, and targets, like arm, have
# multiple target descriptions, GDB doesn't know which target
# description GDBserver uses, and may fail to parse 'g' packet
# after connection.
if { [gdb_skip_xml_test]
&& ([istarget "arm*-*-linux*"]
|| [istarget "mips*-*-linux*"]
|| [istarget "powerpc*-*-linux*"]
|| [istarget "s390*-*-linux*"]
|| [istarget "x86_64-*-linux*"]
|| [istarget "i\[34567\]86-*-linux*"]) } {
return 1
}
...
but it doesn't trigger because aarch64 is missing.
Fix this by adding istarget "aarch64*-*-linux*".
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Currently, a non-trivial return value from a function cannot currently be
reliably determined on PowerPC. This is due to the fact that the PowerPC
ABI uses register r3 to store the address of the buffer containing the
non-trivial return value when the function is called. The PowerPC ABI
does not guarantee the value in register r3 is not modified in the
function. Thus the value in r3 cannot be reliably used to obtain the
return addreses on exit from the function.
This patch adds a new gdbarch method to allow PowerPC to access the value
of r3 on entry to a function. On PowerPC, the new gdbarch method attempts
to use the DW_OP_entry_value for the DWARF entries, when exiting the
function, to determine the value of r3 on entry to the function. This
requires the use of the -fvar-tracking compiler option to compile the
user application thus generating the DW_OP_entry_value in the binary. The
DW_OP_entry_value entries in the binary file allows GDB to resolve the
DW_TAG_call_site entries. This new gdbarch method is used to get the
return buffer address, in the case of a function returning a nontrivial
data type, on exit from the function. The GDB function should_stop checks
to see if RETURN_BUF is non-zero. By default, RETURN_BUF will be set to
zero by the new gdbarch method call for all architectures except PowerPC.
The get_return_value function will be used to obtain the return value on
all other architectures as is currently being done if RETURN_BUF is zero.
On PowerPC, the new gdbarch method will return a nonzero address in
RETURN_BUF if the value can be determined. The value_at function uses the
return buffer address to get the return value.
This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp.
The correct function return values are now reported.
Note this patch is dependent on patch: "PowerPC, function
ppc64_sysv_abi_return_value add missing return value convention".
This patch has been tested on Power 10 and x86-64 with no regressions.
I realized that the more irregular output of show arch:
...
(gdb) show arch^M
The target architecture is set to "auto" (currently "i386").^M
...
would be a problem for something like:
...
with_set arch powerpc:common64 {}
...
and indeed:
...
(gdb) set arch powerpc:common64^M
The target architecture is set to "powerpc:common64".^M
(gdb) FAIL: gdb.base/foo.exp: set arch powerpc:common64
...
and:
...
(gdb) set arch set to "auto" (currently "i386")^M
Undefined item: "set".^M
...
Fix this in with_set by handling this type of output.
Tested on x86_64-linux.
In some test-case I tried to use get_set_option_choices "set architecture" and
ran into max-completions:
...
set architecture simple^M
set architecture tomcat^M
set architecture xscale^M
set architecture *** List may be truncated, max-completions reached. ***^M
(gdb) PASS: gdb.base/foo.exp: complete set architecture
...
There's only one test-case using this currently: gdb.base/parse_number.exp,
and it locally sets max-completions to unlimited.
Fix this by:
- factoring out a new proc with_set out of proc with_complaints, and
- using it to temporarily set max-completions to unlimited in
get_set_option_choice.
Tested on x86_64-linux, by running test-cases that excercise
get_set_option_choice and with_complaints.
We're currently running into a timeout at:
...
(gdb) start ^M
Error in expression, near `1'.^M
(gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right \
procedure
...
due to the fact that gdb_start_cmd doesn't handle a prompt as reaction to
the start command.
Fix this by handling the prompt. Reduces execution time of the test-case from
1m1s to 1s.
Tested on x86_64-linux.
With gdb 12.1, on powerpc64le I ran into ERRORs related to has_hw_wp_support
usage, which was already fixed on trunk by commits:
- 13f7237241 ("gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc"), and
- 01a32ee0b8 ("PowerPC, fix gdb.base/watchpoint.exp on Power 9")
While looking into these ERRORs and the commits that fix them, it occurred to
me that while the commits fix the root cause, the failure mode is not great.
The test-cases expect a running instance of gdb upon return, which is not
there, so there's an long stream of ERRORs generated as a result.
Fix this at the start of has_hw_wp_support, by (instead of accomodating a
running gdb instance by calling gdb_exit), checking whether it's called
without a running gdb instance, and erroring out otherwise. This way, there's
just one error.
I also noticed that in case we do an early exit due to !runto_main, we don't
clean up, so copy the missing cleanups (gdb_exit and $obj file deletion) from
the regular exit.
Tested on x86_64-linux, using has_hw_wp_support for x86_64 in
skip_hw_watchpoint_tests.
When calling get_func_info inside a test case, it would cause failures
if the function was printed using a C++ style mangled name. The current
patch fixes this by allowing for mangled names along with the current
rules.
Approved-By: Tom Tromey <tom@tromey.com>
With test-case gdb.base/bigcore.exp I run into:
...
(gdb) PASS: gdb.base/bigcore.exp: get inferior pid
signal SIGABRT^M
Continuing with signal SIGABRT.^M
^M
Program terminated with signal SIGABRT, Aborted.^M
The program no longer exists.^M
(gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
UNTESTED: gdb.base/bigcore.exp: can't generate a core file
...
due to find_core_file returning "".
There is a core file name core:
...
$ ls ./outputs/gdb.base/bigcore
bigcore bigcore.corefile core gdb.cmd.1 gdb.in.1 gdbserver.cmd.1
...
but it's not found.
The problem is this statement:
...
lappend files [list ${::testfile}.core core]
...
which adds a single list item "${::testfile}.core core".
Fix this in the most readable way:
...
lappend files ${::testfile}.core
lappend files core
...
Tested on x86_64-linux.
I noticed that running test-case gdb.mi/mi-exec-run.exp with host board
local-remote-host.exp takes about 44 seconds.
I found two silent timeouts responsible for this.
The first is in mi_gdb_exit, where we have:
...
if { [is_remote host] && [board_info host exists fileid] } {
send_gdb "999-gdb-exit\n"
gdb_expect 10 {
-re "y or n" {
send_gdb "y\n"
exp_continue
}
-re "Undefined command.*$gdb_prompt $" {
send_gdb "quit\n"
exp_continue
}
-re "DOSEXIT code" { }
}
}
...
so in gdb.log we see:
...
999-gdb-exit^M
999^exit^M
=thread-exited,id="1",group-id="i1"^M
=thread-group-exited,id="i1"^M
...
after which expect just waits for the timeout.
Fix this by adding a gdb_expect clause to parse the exit:
...
-re "\r\n999\\^exit\r\n" { }
...
Note that we're not parsing the thread-exited/thread-group-exited messages, because
they may not be present:
...
$ gdb -i=mi
=thread-group-added,id="i1"
(gdb)
999-gdb-exit
999^exit
$
...
After fixing that, we have:
...
(gdb) ^M
saw mi error
PASS: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: \
force-fail=1: run failure detected
quit^M
&"quit\n"^M
...
What seems to be happening is that default_gdb_exit sends a cli interpreter
quit command to an mi interpreter, after which again expect just waits for the
timeout.
Fix this by adding mi_gdb_exit to the end of the test-case, as in many other
gdb.mi/*.exp test-cases.
After these two fixes, the test-case takes about 4 seconds.
Tested on x86_64-linux.
On openSUSE Tumbleweed I run into this for the dwarf assembly test-cases, and
some hardcoded assembly test-cases:
...
Running gdb.dwarf2/fission-absolute-dwo.exp ...
gdb compile failed, ld: warning: fission-absolute-dwo.o: \
missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future \
version of the linker
=== gdb Summary ===
# of untested testcases 1
...
Fix the dwarf assembly test-cases by adding the missing .note.GNU-stack in
proc Dwarf::assemble.
Fix the hard-coded test-cases using this command:
...
$ for f in $(find gdb/testsuite/gdb.* -name *.S); do
if ! grep -q note.GNU-stack $f; then
echo -e "\t.section\t.note.GNU-stack,\"\",@progbits" >> $f;
fi;
done
...
Likewise for .s files, and gdb/testsuite/lib/my-syscalls.S.
The idiom for arm seems to be to use %progbits instead, see commit 9a5911c08b
("gdb/testsuite/gdb.dwarf2: Replace @ with % for ARM compatability"), so
hand-edit gdb/testsuite/gdb.arch/arm-disp-step.S to use %progbits instead.
Note that dwarf assembly testcases use %progbits as decided by proc _section.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29674
With test-case gdb.mi/mi-disassemble.exp and check-read1 I run into:
...
FAIL: gdb.mi/mi-disassemble.exp: disassemble /b main
FAIL: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x400549)"
...
The problem for both FAILs is that the output is parsed using
gdb_test_multiple, which has implicit clauses using $gdb_prompt, which can
match before the explicit clauses using $mi_gdb_prompt.
Fix this by passing -prompt "$mi_gdb_prompt$" to gdb_test_multiple.
Tested on x86-64-linux.
I spotted that the gdb.gdb/unittest.exp script causes a temporary file
inserters_extractors-2.txt to be created in build/gdb/testsuite/
instead of in build/gdb/testsuite/output/gdb.gdb/unittest/.
This is because some of the 'maint selftest' tests create temporary
files in GDB's current directory, specifically, the two source files:
gdb/unittests/basic_string_view/inserters/wchar_t/2.cc
gdb/unittests/basic_string_view/inserters/char/2.cc
both create a temporary file called inserters_extractors-2.txt, though
we only run the second of these as part of GDB's selftests.
I initially proposed just using GDB's 'cd' command in unittest.exp to
switch to the test output directory before running the selftests,
however, Pedro pointed out that there was a risk here that, if GDB
crashed during shutdown, the generated core file would be left in the
test output directory rather than in the testsuite directory. As a
result, our clever core file spotting logic would fail to spot the
core file and alert the user.
Instead, I propose this slightly more involved solution. I've added a
new with_gdb_cwd directory proc, used like this:
with_gdb_cwd $directory {
# Tests here...
}
The new proc temporarily switches to $directory and then runs the
tests within the block. After running the tests the previous current
working directory is restored.
Additionally, after switching back to the previous cwd, we check that
GDB is still responsive. This means that if GDB crashed immediately
prior to restoring the previous directory, and left the core file in
the wrong place, then the responsiveness check will fail, and a FAIL
will be emitted, this should be enough to alert the user that
something has gone wrong.
With this commit in place the unittest.exp script now leaves its
temporary file in the test output directory.
In glibc, the r_debug structure contains (amongst others) the following
fields:
int r_version:
Version number for this protocol. It should be greater than 0.
If r_version is 2, struct r_debug is extended to struct r_debug_extended
with one additional field:
struct r_debug_extended *r_next;
Link to the next r_debug_extended structure. Each r_debug_extended
structure represents a different namespace. The first r_debug_extended
structure is for the default namespace.
1. Change solib_svr4_r_map argument to take the debug base.
2. Add solib_svr4_r_next to find the link map in the next namespace from
the r_next field.
3. Update svr4_current_sos_direct to get the link map in the next namespace
from the r_next field.
4. Don't check shared libraries in other namespaces when updating shared
libraries in a new namespace.
5. Update svr4_same to check the load offset in addition to the name
6. Update svr4_default_sos to also set l_addr_inferior
7. Change the flat solib_list into a per-namespace list using the
namespace's r_debug address to identify the namespace.
Add gdb.base/dlmopen.exp to test this.
To remain backwards compatible with older gdbserver, we reserve the
namespace zero for a flat list of solibs from all namespaces. Subsequent
patches will extend RSP to allow listing libraries grouped by namespace.
This fixes PR 11839.
Co-authored-by: Lu, Hongjiu <hongjiu.lu@intel.com>
Check for
warning: Corrupted shared library list
and for
Invalid cast.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
in gdb_test_multiple.
With the test-case included in this patch, we run into:
...
(gdb) target remote localhost:2347^M
`target:twice-connect' has disappeared; keeping its symbols.^M
Remote debugging using localhost:2347^M
warning: Unable to find dynamic linker breakpoint function.^M
GDB will be unable to debug shared library initializers^M
and track explicitly loaded dynamic code.^M
Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M
0x00007ffff7dd4550 in ?? ()^M
(gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started
FAIL: gdb.server/twice-connect.exp: found interpreter
...
The problem originates in find_program_interpreter, where
bfd_get_section_contents is called to read .interp, but fails. The function
returns false but the result is ignored, so find_program_interpreter returns
some random string.
Fix this by checking the result of the call to bfd_get_section_contents.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29652
Compilers default to either PIE or no-PIE executables.
In order to test PIE executables with a compiler that produces non-PIE by
default, we can use target board unix/-fPIE/-pie, which set the multilib_flags
of the target board to "-fPIE -pie".
Likewise, we can use target board unix/-fno-PIE/-no-pie with a compiler that
produces PIE by default.
The target board unix/-fno-PIE/-no-pie has a potential problem when compiling
shared libs, because the multilib_flags will override the attempts of
gdb_compile_shlib to compile with -fPIC. This is taken care of by running the
body of gdb_compile_shlib wrapped in with_PIE_multilib_flags_filtered.
The target board unix/-fPIE/-pie has a problem with nopie compilations. The
current approach is to do the compilation hoping for the best, and if we find
out that the resulting executable is PIE despite specifying nopie, we error
out with the standard error message "nopie failed to prevent PIE executable".
That however does not work for hard-coded assembly nopie test-cases, which will
just noisily refuse to compile:
...
ld: amd64-disp-step0.o: relocation R_X86_64_32S against `.text' can not be \
used when making a PIE object; recompile with -fPIE^M
...
Fix this in gdb_compile by filtering out the PIE settings in the target board
multilib_flags when pie or nopie is specified.
Tested on x86_64-linux.
Add a new proc cond_wrap, that can be used to replace the repetitive:
...
if { $cond } {
wrap {
<body>
}
} else {
<body>
}
...
with the shorter:
...
cond_wrap $cond wrap {
<body>
}
...
Tested on x86_64-linux.
With test-case gdb.dwarf2/macro-source-path.exp and target board unix/-m32, I
run into:
...
as: macro-source-path-gcc11-ld238-dw5-filename-641.o: \
unsupported relocation type: 0x1^M
...
The problem is that we have 64-bit dwarf so the debug_line offset in the
.debug_macro section is an 8-byte entity, emitted using ".8byte":
...
.section .debug_macro
.Lcu_macros4:
.2byte 5 /* version */
.byte 3 /* flags */
.8byte .LLlines3 /* debug_line offset */
...
but the linker doesn't support 8-byte relocation types on a 32-bit architecture.
This is similar to what was fixed in commit a5ac8e7fa3
("[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32") for for instance
.debug_abbrev.
Fix this in the same way, by using _op_offset to emit the debug_line offset.
Tested on x86_64-linux with native and target board unix/-m32.
I noticed in capture_command_output that the output of a single command is
matched using two gdb_test_multiples:
- the first one matching the echoed command and skipping an optional prefix,
- the second one matching the output and the prompt.
This is error-prone, because the first gdb_test_multiple has implicit
clauses which may consume the prompt.
The problem is easy to spot with an example. First consider:
...
set output [capture_command_output "print 1" "\\\$1 = "]
gdb_assert { [string equal $output "1"] }
...
for which we get:
...
PASS: [string equal $output "1"]
...
If we change the prefix string to a no-match, say "1 = ", and update the
output string match accordingly, we get instead:
...
FAIL: capture_command_output for print 1
FAIL: [string equal $output "\$1 = 1"]
...
The first FAIL is produced by the first gdb_test_multiple, consuming the prompt.
The second gdb_test_multiple then silently times out waiting for another prompt,
after which the second FAIL is produced. Note that the timeout is silent
because the gdb_test_multiple is called with an empty message argument.
The second FAIL is because capture_command_output returns "", given that all
the command output was consumed by the first gdb_test_multiple.
Fix this by rewriting capture_command_output to use only a single
gdb_test_multiple.
Tested on x86_64-linux.
I see some random failures in this test:
FAIL: gdb.base/async-shell.exp: run & (timeout)
It can be reliably reproduced on a recent enough GNU/Linux with this
change:
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 44cc28b30051..2a3c8253ba5a 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -1301,6 +1301,7 @@ proc gdb_test_multiple { command message args } {
}
set gdb_test_name "$message"
+ sleep 2
set result 0
set code [catch {gdb_expect $code} string]
"recent enough" means a system where libpthread.so was merged with
libc.so, so at least glibc 2.34.
The problem is that the `run &` command prints some things after the
prompt:
(gdb) [Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
If expect is quick enough, it will consume only up to the prompt. But
if it is slow enough, it will consume those messages at the same time as
the prompt, in which case the gdb_test used for "run &" won't match. By
default, the prompt used by gdb_test uses a `$` to anchor the match at
the end of the buffer. If there's anything following the prompt, it
won't match.
The diff above adds a delay between sending the command and consuming
the output, giving GDB more time to output the messages, giving a good
chance that expect consumes them at the same time as the prompt.
This is normally handled by using gdb_test_multiple and specifying a
pattern that ends with "$gdb_prompt", but not a trailing $. I think
this is common enough that it deserves its own gdb_test option.
Therefore, add the -no-anchor-prompt option to gdb_test, and
gdb_test_no_output for completeness. Use it in
gdb.base/async-shell.exp.
Change-Id: I9051d8800d1c10a2e95db1a575991f7723492f1b
Approved-By: Tom de Vries <tdevries@suse.de>
I noticed that the error message in gdb_test_multiple about trailing newline
in a command does not mention the offending command, nor the word command:
...
if [string match "*\[\r\n\]" $command] {
error "Invalid trailing newline in \"$message\" test"
}
...
Fix this by using instead:
...
error "Invalid trailing newline in \"$command\" command"
...
Also add a test-case to trigger this: gdb.testsuite/gdb-test.exp.
Tested on x86_64-linux.
The struct target_buffer (in gdb_bfd.c) is used to hold information
about an in-memory BFD object created by GDB. For now this mechanism
is used by GDB when loading information about JIT symfiles.
This commit updates target_buffer (in gdb_bfd.c) to be more C++ like,
and, at the same time, adds the base address of the symfile into the
BFD filename.
Right now, every in-memory BFD is given the filename "<in-memory>".
This filename is visible in things like 'maint info symtabs' and
'maint info line-table'. If there are multiple in-memory BFD objects
then it can be hard to match keep track if which BFD is which. This
commit changes the name to be "<in-memory@ADDRESS>" where ADDRESS is
replaced with the base address for where the in-memory symbol file was
read from.
As an example of how this is useful, here's the output of 'maint info
jit' showing a single loaded JIT symfile:
(gdb) maintenance info jit
jit_code_entry address symfile address symfile size
0x00000000004056b0 0x0000000007000000 17320
And here's part of the output from 'maint info symtabs':
(gdb) maintenance info symtabs
...snip...
{ objfile <in-memory@0x7000000> ((struct objfile *) 0x5258250)
{ ((struct compunit_symtab *) 0x4f0afb0)
debugformat DWARF 4
producer GNU C17 9.3.1 20200408 (Red Hat 9.3.1-2) -mtune=generic -march=x86-64 -g -fno-stack-protector -fpic
name jit-elf-solib.c
dirname /tmp/binutils-gdb/build/gdb/testsuite
blockvector ((struct blockvector *) 0x5477850)
user ((struct compunit_symtab *) (null))
{ symtab /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/jit-elf-solib.c ((struct symtab *) 0x4f0b030)
fullname (null)
linetable ((struct linetable *) 0x5477880)
}
}
}
I've added a new test that checks the new in-memory file names are
generated correctly, and also checks that the in-memory JIT files can
be dumped back out using 'dump binary memory'.
When running test-case gdb.server/abspath.exp with host board
local-remote-host-notty, I get:
...
$ git sti
...
deleted: gdb/testsuite/gdb.xml/trivial.xml
...
This happens as follows. The test-case calls skip_gdbserver_test, which calls
gdb_skip_xml_test, which does:
...
set xml_file [gdb_remote_download host "${srcdir}/gdb.xml/trivial.xml"]
...
Then proc gdb_remote_download appends $xml_file (which for this particular
host board happens to be ${srcdir}/gdb.xml/trivial.xml) to cleanfiles, which
ends up being handled in gdb_finish by:
...
eval remote_file target delete $cleanfiles
...
The problem is that a host file is deleted using target delete.
Fix this by splitting cleanfiles up in cleanfiles_target and cleanfiles_host.
Tested on x86_64-linux.
With target board remote-gdbserver-on-localhost and gdb.arch/i386-mpx-call.exp
I run into:
...
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
...
This is due to the have_mpx test which should return 0, but instead returns 1
because the captured output:
...
No MPX support
No MPX support
...
does not match the used regexp:
...
set status [expr ($status == 0) \
&& ![regexp "^No MPX support\r\n" $output]]
...
which does match the captured output with native:
...
No MPX support^M
No MPX support^M
...
Fix this by making the \r in the regexp optional.
Tested on x86_64-linux, with native and target board
remote-gdbserver-on-localhost.
When running test-case gdb.server/solib-list.exp with target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) set solib-search-path $outputs/gdb.server/solib-list^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: \
set solib-search-path $outputs/gdb.server/solib-list
PATH: gdb.server/solib-list.exp: non-stop 0: \
set solib-search-path $outputs/gdb.server/solib-list
...
This is due to this code in gdb_load_shlib:
...
gdb_test "set solib-search-path [file dirname $file]" "" ""
...
Fix this by setting an explicit test name.
Tested on x86_64-linux, with native and target boards
remote-gdbserver-on-localhost, native-gdbserver and native-extended-gdbserver.
I noticed a test failure in gdb.base/completion.exp for RISC-V on a
native Linux target. Upon investigation I discovered a couple of
reasons for the failure, this commit addresses one of them. A later
commit will address the other issue.
The completion.exp test makes use of the capture_command_output proc
to collect the output of the 'maint print registers' command. For
RISC-V this command produces a lot of output.
Currently the capture_command_output proc tries to collect the
complete command output in a single expect buffer, and what I see is
an error caused by the expect buffer becoming full.
This commit rewrites capture_command_output to make use of
gdb_test_multiple to collect the command output line at a time, in
this way we avoid overflowing the expect buffer.
The capture_command_output proc has some logic for skipping a prefix
pattern, which is passed in to the proc as an argument. In order to
handle this correctly (only matching the prefix at the start of the
command output), I use two gdb_test_multiple calls, the first spots
and discards the echoed command and the (optional) prefix pattern, the
second gdb_test_multiple call then collects the rest of the command
output line at a time until a prompt is seen.
There is one slight oddity with the current implementation, which I
have changed in my rewrite, this does, slightly, change the behaviour
of the proc.
The current implementation uses this pattern:
-re "[string_to_regexp ${command}]\[\r\n\]+${prefix}(.*)\[\r\n\]+$gdb_prompt $"
Now a typical command output will look like this:
output here\r\n
(gdb)
As the TCL regexp matching is greedy, TCL will try to match as much as
possible in one part of the pattern before moving on to the next.
Thus, when this matches against (.*)[\r\n]+, the (.*) will end up
matching against 'output here\r' and the [\r\n]+ will match '\n' only.
In short the previous implementation would leave the '\r' on the end
of the returned text, but not the final trailing '\n'.
Now clearly I could make a new version of capture_command_output that
maintained this behaviour, but I couldn't see any reason to do this.
So, my new implementation drops the final '\r\n' completely, in our
example above we now return 'output here' with no '\r'.
This change doesn't seem to affect any of the existing tests, but I
thought it was worth mentioning.
Add another test for the output of MI command -data-disassemble. The
new check validates the format of the 'opcodes' field, specifically,
this test checks that the field contains a series of bytes, separated
by a single space.
We also check that the bytes are in the correct order, that is, the
first byte is from the lowest address, and subsequent bytes are from
increasing addresses.
The motivation for this test (besides more tests being generally good)
is that I plan to make changes to how opcode bytes are displayed in
the disassembler output, and I want to ensure that I don't break any
existing MI behaviour.
There should be no user visible changes to GDB after this commit.
Since commit 52b920c5d2 ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
for ppc64le"), the test-case fails with target board cc-with-debug-names, due
to missing .debug_aranges info.
Add the missing .debug_aranges info.
Also add a file_id option to Dwarf::assemble, to make it possible to contribute
to an already open file.
Tested on x86_64-linux.
If some command in there gives the wrong answer, we currently have to
wait for a timeout for the test to continue. For instance, I currently
see:
print *val->type
$1 = Python Exception <class 'gdb.error'>: Cannot take address of method length.
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: pretty print type (timeout)
We can avoid this and modernize the test at the same time by using the
-prompt option of gdb_test.
gdb_test_no_output currently accepts a -prompt_re option (the variable
name passed to parse_args defines the option name), but I think
it's a typo. It's supposed to be -prompt, like gdb_test. I can't find
anything using -prompt_re using grep. Change it to just "prompt".
Change-Id: Icc0a9a0ef482e62460c708bccdd544c11d711eca
When running gdb.gdb/python-helper.exp, I get some timeouts:
continue
Continuing.
print 1
FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb (timeout)
At this time, GDB is actually processing the stop and reading in some
CUs. selftest_setup does bump the timeout, but it's not for the whole
test.
Since debugging GDB with GDB is (unfortunately) a bit slow, bump the
timeout for the whole duration of the setup and body. On my optimized
build, the command takes just a bit more than the current timeout of 10
seconds. But it's much slower if running the test on an unoptimized
build, so I think it's necessary to bump the timeout for that in any
case.
Change-Id: I4d38285870e76c94f9d0bfdb60648a2e7f2cfa5d
The test gdb.tui/tui-missing-src.exp fails on my CI machine, and I
concluded that it is caused by the long source directory name:
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb
The long name causes some particular redrawing that doesn't happen for
shorter directories, and causes a Term::command call to return too
early.
This can be reproduced by cloning the binutils-gdb repo in a directory
with a name similar to the one shown above.
$ pwd
/home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/build/gdb
$ make check-read1 TESTS="gdb.tui/tui-missing-src.exp"
FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
FAIL: gdb.tui/tui-missing-src.exp: f2.c must be displayed in source window
FAIL: gdb.tui/tui-missing-src.exp: check source box is empty after return
FAIL: gdb.tui/tui-missing-src.exp: Back in main
Note that using "make check" instead of "make check-read1" only shows
the last 2 failures for me.
When running gdb.tui/tui-missing-src.exp in a directory with a shorter
name, the terminal looks like this by the time the "checking if inside
f2" test runs:
Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 23):
0 +-...ld/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-missing-src/f2.c-+
1 | 1 |
2 | 2 int |
3 | 3 f2 (int x) |
4 | 4 { |
5 | > 5 x <<= 1; |
6 | 6 return x+5; |
7 | 7 } |
8 | 8 |
9 | 9 |
10 | 10 |
11 | 11 |
12 | 12 |
13 | 13 |
14 +------------------------------------------------------------------------------+
15 multi-thre Thread 0x7ffff7cc07 In: f2 L5 PC: 0x555555555143
16 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
17 missing-src/main.c:6
18 (gdb) next
19 (gdb) step
20 f2 (x=4)
21 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
22 missing-src/f2.c:5
23 (gdb)
PASS: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
When running the `Term::command "step"` just before, GDB writes the
"step", which makes the `wait_for` proc go in the "looking for the
prompt" mode, to know when the command's execution is complete. As some
new output appears, lines that must disappear are deleted using the
"Delete Line" operation [1] and some new ones are drawn. The source
window gets redrawn with the contents of the f2.c file. Then, GDB
writes the prompt (at line 23 above), which satisfies `wait_for`, which
then returns. The state of the terminal is therefore correct for the
"check if inside f2" and "f2.c must be displayed in the source window"
tests.
In the non-working case, the terminal looks like this by the time the
"check if inside f2" test runs:
Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 17):
0 +------------------------------------------------------------------------------+
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | [ No Source Available ] |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 +------------------------------------------------------------------------------+
15 multi-thre Thread 0x7ffff7cc1b In: main L7 PC: 0x555555555128
16 sing-src/main.c:6
17 (gdb) ary breakpoint 1, main ()
18 at /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd6
19 4/target_board/unix/src/binutils-gdb/build/gdb/testsuite/outputs/gdb.tui/tui-mis
20 sing-src/main.c:6
21 (gdb) next
22 (gdb) step
23
FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
What happened is: GDB wrote the "step" command, which make the
`wait_for` proc go in its "looking for the prompt" mode. However,
curses decided to redraw whatever scrolled up to line 17 using some
standard character insertion operations:
+++ Cursor Down (1), cursor: (16, 0) -> (17, 0)
+++ Inserting string '('
+++ Inserted char '(', cursor: (17, 0) -> (17, 1)
+++ Inserted string '(', cursor: (17, 0) -> (17, 1)
+++ Inserting string 'g'
+++ Inserted char 'g', cursor: (17, 1) -> (17, 2)
+++ Inserted string 'g', cursor: (17, 1) -> (17, 2)
+++ Inserting string 'd'
+++ Inserted char 'd', cursor: (17, 2) -> (17, 3)
+++ Inserted string 'd', cursor: (17, 2) -> (17, 3)
+++ Inserting string 'b'
+++ Inserted char 'b', cursor: (17, 3) -> (17, 4)
+++ Inserted string 'b', cursor: (17, 3) -> (17, 4)
+++ Inserting string ')'
+++ Inserted char ')', cursor: (17, 4) -> (17, 5)
+++ Inserted string ')', cursor: (17, 4) -> (17, 5)
+++ Inserting string ' '
+++ Inserted char ' ', cursor: (17, 5) -> (17, 6)
+++ Inserted string ' ', cursor: (17, 5) -> (17, 6)
And that causes `wait_for` to think the "step" command is complete.
This is wrong, as the prompt at line 17 isn't the prompt drawn after the
completion of the "step" command. The subsequent tests now run with a
partially updated screen (what is shown above) and obviously fail.
The ideal way to fix this would be for `wait_for` to be smarter, to
avoid it confusing the different prompts drawn.
However, I would also like to reduce the variations in TUI test results
due to the directories (source and build) in which tests are ran. TUI
tests are more prone to differences in test results due to variations in
directory names than other tests, as it makes curses take different
redrawing decisions. So in this patch, I propose to make TUI tests use
"set filename-display basename", which makes GDB omit directory names
when it prints file names. This way, regardless of where you run the
tests, you should get the same results (all other things being equal).
Doing this happens to fix my failures and makes my CI happy (which in
turns makes me happy). To be clear, I understand that this does not fix
the root issue of `proc wait_for` being confused. However, it makes TUI
test runs be more similar for everyone, such that there's less chance of
TUI tests randomly failing for somebody. If some other change triggers
the `wait_for` problem again in the future, hopefully everybody will see
the problem and we can work on getting it fixed more easily than if just
one unlucky person sees the problem.
Note that there are other reasons why TUI tests could vary, like
different curses library versions taking different re-drawing decisions.
However, I think my change is a good step towards more stable test
results.
[1] https://vt100.net/docs/vt510-rm/DL.html
Change-Id: Ib18da83317e7b78a46f77892af0d2e39bd261bf5
GDB's testsuite can override dejagnu's default_target_compile if the
system provided dejagnu installation does not provide support to compile
languages GDB needs.
Recent version of dejagnu (1.6.3, installed on RHEL-9) includes ba60272
"Establish a default C compiler by evaluating [find_gcc] if no other
compiler is given."[1]. This commit removed calls such as
`set_board_info compiler "[find_gcc]"` from the various baseboards
and has default_target_compile call `find_gcc` itself to find a compiler
if none was specified by the board description.
On systems with dejagnu-1.6.3, if GDB's overrides is needed to support
languages still unknown to dejagnu, we end up in the following
situation:
- The system board files do not set the C compiler anymore,
- GDB's replacement for default_target_compile assumes that the
compiler should have been set up by the board file.
In this situation, no one sets the C compiler for the board and as a
result many test are not compiled and not executed:
[...]
Running .../gdb/testsuite/gdb.base/bt-on-error-and-warning.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
Running .../gdb/testsuite/gdb.base/dprintf-non-stop.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
Running .../gdb/testsuite/gdb.base/structs3.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
[...]
We are observing this error with ROCgdb[2], a downstream port of GDB
supporting AMD GPUs. This port needs to use GDB's override of
default_target_compile to compile HIP programs since dejagnu does not
provide support for this language yet.
This patch changes gdb_default_target_compile_1 in a similar way
default_target_compile has been updated so both implementations remain
compatible. Even if this is not strictly required by GDB just yet,
I believe keeping both implementations in sync desirable.
Using board files provided with dejagnu <=1.6.2 is still supported: if
the compiler is set by the board file, gdb_default_target_compile_1 uses
it and does not need `find_gcc`.
Patch tested on x86_64 RHEL-9 and ubuntu-20.04 on top of GDB and ROCgdb.
[1] http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=ba60272a5ac6f6a7012acca03f596a6ed003f044
[2] https://github.com/ROCm-Developer-Tools/ROCgdb
Change-Id: Ibff52684d9cab8243a7c6748ecbd29f50c37e669
Different compilers link the epilogue of functions to different lines.
As an example, gcc links it to the closing brace of the function,
whereas clang links it to the last statement of the function. This
difference is important for the testsuite, since the where GDB will land
after a step can be wildly different. Where possible, this dependency
should be side-stepped in the testsuite, but it isn't always possible,
so this commit adds a gdb_caching_proc that is able to detect where the
epilogue is linked, so tests can react accordingly.
We currently have a single test for GDB's debuginfod support, this is
gdb.debuginfod/fetch_src_and_symbols.exp, this script does all the
setup, starts debuginfod, and then does the testing.
This commit tries to split the existing script in two, there is a new
library lib/debuginfod-support.exp, which contains a helper functions
related to running debuginfod tests. All the code in the new library
is basically copied from the existing test case (which is why I
retained the copyright date range on the new library), with some minor
adjustments to try and make the code a little more generic.
One change I made, for example, is the library offers functions to
shut down debuginfod, previously we just relied on expect shutting
down debuginfod when dejagnu completed.
The existing test script is updated to make use of the new library
code, and this test is still passing for me. The only change in the
test results is a single test where I changed the name to remove the
port number from the test name - the port number can change from run
to run, so could make it hard to compare test results.
I have also done a little light house keeping on the original test
script, updating and adding new comments, and making use of
proc_with_prefix in a couple of places.
Currently, GDB's testsuite uses a set amount of step commands to exit
functions. This is a problem if a compiler emits different epilogue
information from gcc, or emits no epilogue information at all. It was
most noticeable if Clang was used to test GDB.
To fix this unreliability, this commit introduces a new proc that will
step the inferior until it is stopped at a line that matches the given
regexp, or until it steps too many times - defined as an optional
argument. If the line is found, it shows up as a single PASS in the
test, and if the line is not found, a single FAIL is emitted.
This patch only introduces this proc, but does not add it to any
existing tests, these will be introduced in the following commit.
In commit cd919f5533 ("[gdb/testsuite] Fix
gdb.dwarf2/dw2-dir-file-name.exp"), I made gdb.dwarf2/dw2-dir-file-name.exp
independent of prologue analyzers, using this change:
...
- gdb_breakpoint $func
+ gdb_breakpoint *$func
...
That however caused a regression on ppc64le. For PowerPC, as described in the
ELFv2 ABI, a function can have a global and local entry point.
Setting a breakpoint on *$func effectively creates a breakpoint for the global
entry point, so if the function is entered through the local entry point, the
breakpoint doesn't trigger.
Fix this by reverting commit cd919f5533, and setting the breakpoint on
${func}_label instead.
Tested on x86_64-linux and ppc64le-linux.
When running test-case gdb.cp/cpexprs-debug-types.exp on target board
cc-with-debug-names/gdb:debug_flags=-gdwarf-5, we get an executable with
a .debug_names section, but no .debug_types section. For dwarf-5, the TUs
are no longer put in a separate unit, but instead they're put in the
.debug_info section.
When loading the executable, the .debug_names section is silently ignored
because of this check in dwarf2_read_debug_names:
...
if (map->tu_count != 0)
{
/* We can only handle a single .debug_types when we have an
index. */
if (per_bfd->types.size () != 1)
return false;
...
which triggers because per_bfd->types.size () == 0.
The intention of the check is to make sure we don't have more that one
.debug_types section, as can happen in a object file (see PR12984):
...
$ grep "\.debug_types" 11.s
.section .debug_types,"G",@progbits,wt.75c042c23a9a07ee,comdat
.section .debug_types,"G",@progbits,wt.c59c413bf50a4607,comdat
...
Fix this by:
- changing the check condition to "per_bfd->types.size () > 1", and
- handling per_bfd->types.size () == 0.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29385
Add test-case gdb.dwarf2/debug-names-bad-cu-index.exp, a regression test for
commit 2fe9a3c41f ("[gdb/symtab] Fix bad compile unit index complaint").
Tested on x86_64-linux.
Add a test-case gdb.dwarf2/debug-names-tu.exp, that uses the dwarf assembler
to specify a .debug_names index with the TU list referring to a TU from the
.debug_types section.
This is intended to produce something similar to:
...
$ gcc -g -fdebug-types-section ~/hello.c -gdwarf-4
$ gdb-add-index -dwarf-5 a.out
...
Tested on x86_64-linux.
When writing a dwarf testcase for some C++ code I wanted to use the
MACRO_AT_range which in turn uses the function_range proc in dwarf.exp
to extract the bounds of 'main'.
However, the macro failed as GDB prints the C++ 'main' with its
arguments as 'main(int, char**)' or 'main()'.
The reason for this is that in read.c::dwarf2_compute_name we call
c_type_print_args on C++ functions and append their arguments to the
function name. This happens to all C++ functions, but is only visible
when the function doesn't have a linkage name.
An example might make this more clear. Given the following code
>> cat c.cpp
int foo (int a, float b)
{
return 0;
}
int main (int argc, char **argv)
{
return 0;
}
which is legal in both languages, C and C++, and compiling it with
e.g. clang or gcc will make the disassemble command look like:
>> clang --version
clang version 10.0.0-4ubuntu1
...
>> clang -O0 -g ./c.cpp
>> gdb -q ./a.out -ex "start"
...
(gdb) disassemble main
Dump of assembler code for function main(int, char**):
0x0000000000401120 <+0>: push %rbp
0x0000000000401121 <+1>: mov %rsp,%rbp
...
0x0000000000401135 <+21>: ret
End of assembler dump.
(gdb) disassemble foo
Dump of assembler code for function _Z3fooif:
0x0000000000401110 <+0>: push %rbp
0x0000000000401111 <+1>: mov %rsp,%rbp
...
0x000000000040111f <+15>: ret
End of assembler dump.
Note, that main is emitted with its arguments while for foo the linkage
name is being printed, as also visible in its DWARF:
>> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3
<2b> DW_AT_low_pc : 0x401110
<33> DW_AT_high_pc : 0x10
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif
<3d> DW_AT_name : (indirect string, offset: 0x42): foo
<41> DW_AT_decl_file : 1
<42> DW_AT_decl_line : 1
<43> DW_AT_type : <0x9a>
Now, let's rename the C++ file and compile it as C:
>> mv c.cpp c.c
>> clang -O0 -g ./c.c
>> gdb -q ./a.out -ex "start'
...
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000401120 <+0>: push %rbp
0x0000000000401121 <+1>: mov %rsp,%rbp
...
0x0000000000401135 <+21>: ret
End of assembler dump.
(gdb) disassemble foo
Dump of assembler code for function foo:
0x0000000000401110 <+0>: push %rbp
0x0000000000401111 <+1>: mov %rsp,%rbp
...
0x000000000040111f <+15>: ret
End of assembler dump.
Note, for foo we did not get a linkage name emitted in DWARF, so
it is printed by its name:
>> objdump --dwarf=info ./a.out | grep foo -A3 -B3
<2b> DW_AT_low_pc : 0x401110
<33> DW_AT_high_pc : 0x10
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_name : (indirect string, offset: 0x37): foo
<3d> DW_AT_decl_file : 1
<3e> DW_AT_decl_line : 1
<3f> DW_AT_prototyped : 1
To make the macro and proc work with C++ as well, an optional argument
list was added to the regex matching the function name in the
disassemble command in function_range. This does not change any used
behavior as currently, there exists no C++ test using the proc
function_range.
Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
