| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch rearranges the DWARF reader so that more work is done in
the background. This is PR symtab/29942.
The idea here is that there is only a small amount of work that must
be done on the main thread when scanning DWARF -- before the main
scan, the only part is mapping the section data.
Currently, the DWARF reader uses the quick_symbol_functions "lazy"
functionality to defer even starting to read. This patch instead
changes the reader to start reading immediately, but doing more in
worker tasks.
Before this patch, "file" on my machine:
(gdb) file /tmp/gdb
2023-10-23 12:29:56.885 - command started
Reading symbols from /tmp/gdb...
2023-10-23 12:29:58.047 - command finished
Command execution time: 5.867228 (cpu), 1.162444 (wall)
After the patch, more work is done in the background and so this takes
a bit less time:
(gdb) file /tmp/gdb
2023-10-23 13:25:51.391 - command started
Reading symbols from /tmp/gdb...
2023-10-23 13:25:51.712 - command finished
Command execution time: 1.894500 (cpu), 0.320306 (wall)
I think this could be further sped up by using the shared library load
map to avoid objfile loops like the one in expand_symtab_containing_pc
-- it seems like the correct objfile could be chosen more directly.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29942
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30174
|
|
On aarch64-linux, I run into:
...
FAIL: gdb.base/annota1.exp: backtrace from shlibrary (timeout)
...
due to the PAC marker showing up:
...
^Z^Zframe-address^M
0x000000000041025c [PAC]^M
^Z^Zframe-address-end^M
...
In the docs the marker is documented as follows:
...
When GDB is debugging the AArch64 architecture, and the program is using the
v8.3-A feature Pointer Authentication (PAC), then whenever the link register
$lr is pointing to an PAC function its value will be masked. When GDB prints
a backtrace, any addresses that required unmasking will be postfixed with the
marker [PAC]. When using the MI, this is printed as part of the addr_flags
field.
...
Update the test-case to allow the PAC marker.
Likewise in a few other test-cases.
While we're at it, rewrite the affected pattern pat_begin in annota1.exp into
a more readable form. Likewise for the corresponding pat_end.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/31202
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31202
|
|
This commit adds a mechanism for GDB to detect the linetable opcode
DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
that a certain instruction marks the point where the frame is destroyed.
While the standard allows for multiple points marked with epilogue_begin
in the same function, for performance reasons, the function that
searches for the epilogue address will only find the last address that
sets this flag for a given block.
This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
use the epilogue begin directly, and only if an epilogue can't be found
will it attempt heuristics based on the current instruction.
Finally, this commit also changes the dwarf assembler to be able to emit
epilogue-begin instructions, to make it easier to test this patch
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fortran provides additional entry points for subroutines and functions.
These entry points may use only a subset (or a different set) of the
parameters of the original subroutine. The entry points may be described
via the DWARF tag DW_TAG_entry_point.
This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
Currently, between ifx/ifort/gfortran, only ifort is actually emitting
this tag. Both, ifx and gfortran use the DW_TAG_subprogram tag as
workaround/alternative. Thus, this patch really only adds more ifort
support. Even so, some of the attached tests still fail for ifort, due
to some wrong line info generated for the entry points in ifort.
After this patch it is possible to set a breakpoint in gdb with the
ifort compiled example at the entry points 'foo' and 'foobar', which was not
possible before.
As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
which uses some underlying c compiled code and adds some Fortran style DWARF
to it emitting the DW_TAG_entry_point. Before this patch it was not
possible to actually define breakpoint at the entry point tags.
For gfortran there actually exists a bug on bugzilla, asking for the use
of DW_TAG_entry_point over DW_TAG_subprogram:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134
This patch was originally posted here
https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html
but its review/pinging got lost after a while. I reworked it to fit the
current GDB.
Co-authored-by: Bernhard Heckel <bernhard.heckel@intel.com>
Co-authored-by: Tim Wiederhake <tim.wiederhake@intel.com>
Approved-by: Tom Tromey <tom@tromey.com>
|
|
PR rust/31005 points out that dynamic type resolution of a LOC_CONST
or LOC_CONST_BYTES symbol will fail, leading to output like:
from_index=<error reading variable: Cannot access memory at address 0x0>
This patch fixes the problem by using the constant value or bytes when
performing type resolution.
Thanks to tpzker@thepuzzlemaker.info for a first version of this
patch.
I also tested this on a big-endian PPC system (cfarm203).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31005
|
|
This reverts commit 1c04f72368c ("[gdb/symtab] Fix assert in set_length"), due
to a regression reported in PR29572, and implements a different fix for PR29453.
The fix is to not use the CU table in a .debug_names section to construct
all_units, but instead use create_all_units, and then verify the CU
table from .debug_names. This also fixes PR25969, so remove the KFAIL.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29572
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25969
|
|
In the commit:
commit 4793f551a5aa68522fd5fbbb7e8f621148f410cd
Date: Mon Nov 27 13:33:17 2023 +0000
gdb: allow use of ~ in 'save gdb-index' command
I added a test which has a directory name within the GDB command,
which then appears in the test name as I failed to give the test a
better name.
Fixed in this commit.
|
|
Add a call to gdb_tilde_expand in the save_gdb_index_command function,
this means that we can now do:
(gdb) save gdb-index ~/blah/
Previous this wouldn't work.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On pinebook I ran into:
...
Running gdb.tui/tui-layout-asm-short-prog.exp ...
gdb compile failed, gdb.tui/tui-layout-asm-short-prog.S: Assembler messages:
gdb.tui/tui-layout-asm-short-prog.S:23: Error: \
junk at end of line, first unrecognized character is `,'
...
Fix this by using %progbits instead of @progbits for arm.
Approved-by: Luis Machado <luis.machado@arm.com>
Tested on x86_64-linux and pinebook.
|
|
Currently, when GDB is reverse stepping out of a function into the same
function due to a recursive call, it doesn't print frame information, as
reported by PR record/29178. This happens because when the inferior
leaves the current frame, GDB decides to refresh the step information,
clobbering the original step_frame_id, making it impossible to figure
out later on that the frame has been changed.
This commit changes GDB so that, if we notice we're in this exact
situation, we won't refresh the step information.
Because of implementation details, this change can cause some debug
information to be read when it normally wouldn't before, which showed up
as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that
isn't a problem, the test was changed to allow for the new output.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Recently added test-case gdb.dwarf2/dw2-gas-workaround.exp:
- passes when gdb is configured using $(cd ../src; pwd)/configure, but
- fails when using ../src/configure.
Fix this by making the matching more precise:
...
- -re -wrap "$objdir.*" {
+ -re -wrap "name_for_id = $objdir/$srcfile\r\n.*" {
...
such that we only fail on the line:
...
[symtab-create] start_subfile: name = dw2-lines.c, name_for_id = \
/data/vries/gdb/leap-15-4/build/gdb/testsuite/dw2-lines.c^M
...
Reported-By: Carl Love <cel@us.ibm.com>
|
|
While working on background reading of DWARF, I came across the
DWZ-reading code. This code can query the user (via the debuginfod
support) -- something that cannot be done off the main thread.
Looking into it, I realized that this code can be run much earlier,
avoiding this problem. Digging a bit deeper, I also found a
discrepancy here between how the DWARF reader works in "readnow" mode
as compared to the normal modes.
This patch cleans this up by trying to read the DWZ file earlier, and
also by having the DWARF reader convert any exception here into a
warning. This unifies the various cases, but also makes it so that
errors do not prevent gdb from continuing on to the extent possible.
Regression tested on x86-64 Fedora 38.
|
|
When running test-case gdb.tui/tui-layout-asm-short-prog.exp on AlmaLinux 9.2
ppc64le, I run into:
...
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
...
The problem is that we get:
...
7 [ No Assembly Available ]
...
because tui_get_begin_asm_address doesn't succeed.
In more detail, tui_get_begin_asm_address calls:
...
find_line_pc (sal.symtab, sal.line, &addr);
...
with:
...
(gdb) p *sal.symtab
$5 = {next = 0x130393c0, m_compunit = 0x130392f0, m_linetable = 0x0,
filename = "tui-layout-asm-short-prog.S",
filename_for_id = "$gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S",
m_language = language_asm, fullname = 0x0}
(gdb) p sal.line
$6 = 1
...
The problem is the filename_for_id which is the source file prefixed with the
compilation dir rather than the source dir.
This is due to faulty debug info generated by gas, PR28629:
...
<1a> DW_AT_name : tui-layout-asm-short-prog.S
<1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite
<22> DW_AT_producer : GNU AS 2.35.2
...
The DW_AT_name is relative, and it's relative to the DW_AT_comp_dir entry,
making the effective name $gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S.
The bug is fixed starting version 2.38, where we get instead:
...
<1a> DW_AT_name :
$gdb/src/gdb/testsuite/gdb.tui/tui-layout-asm-short-prog.S
<1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite
<22> DW_AT_producer : GNU AS 2.38
...
Work around the faulty debug info by constructing the filename_for_id using
the second directory from the directory table in the .debug_line header:
...
The Directory Table (offset 0x22, lines 2, columns 1):
Entry Name
0 $gdb/build/gdb/testsuite
1 $gdb/src/gdb/testsuite/gdb.tui
...
Note that the used gas contains a backport of commit 3417bfca676 ("GAS:
DWARF-5: Ensure that the 0'th entry in the directory table contains the
current working directory."), because directory 0 is correct. With the
unpatched 2.35.2 release the directory 0 entry is incorrect: it's a copy of
entry 1.
Add a dwarf assembly test-case that reflects the debug info as generated by
unpatched gas 2.35.2.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
If we make writing an index-cache entry very slow by doing this in
index_cache::store:
...
try
{
+ sleep (15);
index_cache_debug ("writing index cache for objfile %s",
bfd_get_filename (per_bfd->obfd));
...
we run into:
...
FAIL: gdb.dwarf2/per-bfd-sharing.exp: \
couldn't remove files in temporary cache dir
...
The FAIL happens because there is no index-cache entry in the cache dir.
The problem is that gdb is killed (by gdb_exit) before the index-cache entry
is written.
Fix this by using "maint wait-for-index-cache".
Tested on x86_64-linux.
PR testsuite/30528
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30528
|
|
When using glibc debuginfo generated with gas 2.39, we run into PR gas/29517:
...
$ gdb -q -batch a.out -ex start -ex "p (char *)strstr (\"haha\", \"ah\")"
Temporary breakpoint 1 at 0x40051b: file hello.c, line 6.
Temporary breakpoint 1, main () at hello.c:6
6 printf ("hello\n");
Invalid cast.
...
while without glibc debuginfo installed we get the expected result:
...
$n = 0x7ffff7daa1b1 "aha"
...
and likewise with glibc debuginfo generated with gas 2.40.
The strstr ifunc resolves to __strstr_sse2_unaligned. The problem is that gas
generates dwarf that states that the return type is void:
...
<1><3e1e58>: Abbrev Number: 2 (DW_TAG_subprogram)
<3e1e59> DW_AT_name : __strstr_sse2_unaligned
<3e1e5d> DW_AT_external : 1
<3e1e5e> DW_AT_low_pc : 0xbbd2e
<3e1e66> DW_AT_high_pc : 0xbc1c3
...
while the return type should be a DW_TAG_unspecified_type, as is the case
with gas 2.40.
We can still use the workaround of casting to another function type for both
__strstr_sse2_unaligned:
...
(gdb) p ((char * (*) (const char *, const char *))__strstr_sse2_unaligned) \
("haha", "ah")
$n = 0x7ffff7daa211 "aha"
...
and strstr (which requires using *strstr to dereference the ifunc before we
cast):
...
gdb) p ((char * (*) (const char *, const char *))*strstr) ("haha", "ah")
$n = 0x7ffff7daa251 "aha"
...
but that's a bit cumbersome to use.
Work around this in the dwarf reader, such that we have instead:
...
(gdb) p (char *)strstr ("haha", "ah")
$n = 0x7ffff7daa1b1 "aha"
...
This also requires fixing producer_is_gcc to stop returning true for
producer "GNU AS 2.39.0".
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR symtab/30911
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30911
|
|
This started with me running into this comment in symfile.c:
/* FIXME, should use print_sys_errmsg but it's not filtered. */
gdb_printf (_("`%ps' has disappeared; keeping its symbols.\n"),
styled_string (file_name_style.style (), filename));
In this particular case I think I disagree with the comment; I think
the output should be a warning rather than just a message printed to
gdb_stdout, I think when the executable, or some other objfile that is
currently being debugged, disappears from disk, this is likely an
unexpected situation, and worth warning the user about.
So, in theory, I could just call print_sys_errmsg and remove the
comment, but that would mean loosing the filename styling in the
output... so in the end I remove the comment and updated the code to
call warning.
But that got me looking at print_sys_errmsg and how it's used.
Currently the function takes a string and an errno, and prints, to
stderr, the string followed by the result of calling strerror on the
errno.
In some places the string passed to print_sys_errmsg is just a
filename, and this is used when something goes wrong. In these cases,
I think calling warning rather than gdb_printf to gdb_stderr, would be
better, and in fact, in a couple of places we manually print a
"warning" prefix, and then call print_sys_errmsg. And so, for these
users I have added a new function warning_filename_and_errno, which
takes a filename, which is printed with styling, and an errno, which
is passed through strerror and the resulting string printed. This new
function calls warning to print its output. I then updated some of
the print_sys_errmsg users to use this new function.
Some other users of print_sys_errmsg are also emitting what is clearly
a warning, however, the string being passed in is more than just a
filename, so the new warning_filename_and_errno function can't be
used, it would style the whole string. For these users I have
switched to calling warning directly, this allows me to style the
warning message correctly.
Finally, in inflow.c there is one last call to print_sys_errmsg, in
this case I just inlined the definition of print_sys_errmsg. This is
a really weird case, as after printing this message GDB just does a
hard exit. This is pretty old code, dating back to the initial GDB
import, I guess it should be updated to call error() maybe, but I'm
reluctant to make this change as part of this commit, just in case
there's some reason why we can't throw an error at this point.
With that done there are now no users of print_sys_errmsg, and so the
old function can be removed.
While I was doing all of the above I added some additional filename
styling in soure.c, this is in an else block where the if contained
the print_sys_errmsg call, so these felt related.
And finally, while I was updating the uses of print_sys_errmsg in
procfs.c, I noticed that we used a static errmsg buffer to format some
error strings. As the above changes got rid of one of the users of
errmsg I also removed the other two users, and the static buffer.
There were a couple of tests that depended on the existing output
message format that needed updating. In one case we gained an extra
'warning: ' prefix, and in the other 'Warning: ' becomes 'warning: ',
I think in both cases the new output is an improvement.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
There are two methods to factor out type information in a dwarf4 executable:
- use -fdebug-info-types to generate type units in a .debug_types section, and
- use dwz to create partial units.
The dwz method has an extra benefit: it also allows to factor out information
between executables into a newly created .dwz file, pointed to by a
.gnu_debugaltlink section.
There is nothing prohibiting a .gnu_debugaltlink file to contain a
.debug_types section.
It's just not generated by dwz or any other tool atm, and consequently gdb has
no support for it. Enhancement PR symtab/30838 is open about the lack of
support.
Make the current situation explicit by emitting a dwarf error:
...
(gdb) file struct-with-sig-2^M
Reading symbols from struct-with-sig-2...^M
Dwarf Error: .debug_types section not supported in dwz file^M
...
and add an assert in write_gdbindex:
...
+ /* See enhancement PR symtab/30838. */
+ gdb_assert (!(per_cu->is_dwz && per_cu->is_debug_types));
...
to clarify why we can use:
...
data_buf &cu_list = (per_cu->is_debug_types
? types_cu_list
: per_cu->is_dwz ? dwz_cu_list : objfile_cu_list);
...
The test-case is a modified copy from gdb.dwarf2/struct-with-sig.exp, so it
keeps the copyright years range.
Tested on x86_64-linux.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30838
|
|
I ran test-case gdb.dwarf2/dwzbuildid.exp with target board cc-with-gdb-index,
and noticed that compilation failure for one exec prohibited testing of all
execs.
Fix this by restructuring the test-case, such that we have:
...
PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: set debug-file-directory
PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: print the_int
UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=mismatch: compilation failed
UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=fallback: compilation failed
...
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/dwzbuildid.exp using target board readnow, I
get:
...
(gdb) file dwzbuildid-mismatch^M
Reading symbols from dwzbuildid-mismatch...^M
warning: File "dwzbuildid5.o" has a different build-id, file skipped^M
could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch^M
(gdb) delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break -qualified main^M
No symbol table is loaded. Use the "file" command.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: gdb_breakpoint: set breakpoint at main
...
This is PR symtab/26797: when using readnow, a failure in reading the dwarf
results in the minimal symbols not being available.
Add a corresponding KFAIL.
Tested on x86_64-linux.
|
|
While investigating the execs of gdb.dwarf2/dwzbuildid.exp using readelf I ran
into a warning:
...
$ readelf -w dwzbuildid-ok > READELF
readelf: Warning: .debug_info offset of 0x2e in .debug_aranges section does not
point to a CU header.
...
AFAICT, the warning is incorrect, I've filed PR binutils/30835 about that.
While looking at the .debug_aranges section, I noticed that the entries for
the CUs generated by the dwarf assembler are missing.
Fix this by adding the missing .debug_aranges entries.
Tested on x86_64-linux.
|
|
When looking at the execs from test-case gdb.dwarf2/dwzbuildid.exp using
readelf, I run into:
...
$ readelf -w dwzbuildid-ok > READELF
readelf: Warning: Corrupt debuglink section: .gnu_debugaltlink
readelf: Warning: Build-ID is too short (0x6 bytes)
...
Fix this by ensuring the Build-IDs are the required 20 bytes.
Tested on x86_64-linux.
|
|
This patch fixes some testcases that formerly had patterns with
hardwired "/" pathname separators in them, which broke when testing on
(remote) Windows host.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running test-case gdb.dwarf2/nullptr_t.exp with target board
cc-with-dwz-m, I run into:
...
FAIL: gdb.dwarf2/nullptr_t.exp: decltype(nullptr) symbol
...
The problem is that were looking for "typedef void decltype\\(nullptr\\)"
using "maint print symbols -source $srcfile", but dwz has moved the typedef to
a PU, so it's shown by "maint print symbols -source <unknown>" instead.
Fix this by dropping the "-source $srcfile" bit.
Tested on x86_64-linux, with make-check-all.sh.
|
|
When running test-case gdb.mi/print-simple-values.exp with gcc 4.8.4, I run
into a compilation failure due to the test-case requiring c++11 and the
compiler defaulting to less than that.
Fix this by compiling with -std=c++11.
Likewise in a few other test-cases.
Tested on x86_64-linux.
|
|
Building gdb with gcc 7.5.0 and -flto -O2 -flto-partition=one generates a
self-referencing DIE:
...
<2><91dace>: Abbrev Number: 405 (DW_TAG_label)
<91dad0> DW_AT_abstract_origin: <0x91dace>
...
When encountering the self-reference DIE in inherit_abstract_dies we loop
following the abstract origin, effectively hanging gdb.
Fix this by handling self-referencing DIEs in the loop in
inherit_abstract_dies.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30799
https://sourceware.org/bugzilla/show_bug.cgi?id=30799
|
|
While working on a dwarf assembly test-case I accidentally created the
following pathological dwarf:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xbe>
...
and noticed gdb segfaulting during cooked index creating due to running out of
stack. This is a regression from gdb-12, where gdb just hung.
Fix this by inhibiting the scan_attributes self-recursion for self-references.
The same test-case with -readnow makes gdb hang, so also fix this in
dwarf2_attr and follow_die_ref.
Note that this doesn't fix the same problems for the more complicated case of:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xc6>
<1><c6>: Abbrev Number: 4 (DW_TAG_class_type)
<c7> DW_AT_name : c2
<ca> DW_AT_specification: <0xbe>
...
but the approach for deciding whether to fix pathological dwarf cases is as
per PR27981 comment 3:
...
yes if it is cheap/obvious, and no if it is something complicated or expensive.
...
and at this point I'm not sure whether fixing this will fall in the first
category.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Test-case gdb.dwarf2/pr13961.exp contains:
...
<1><25>: Abbrev Number: 8 (DW_TAG_class_type)
<26> DW_AT_specification: <0x2a>
<1><2a>: Abbrev Number: 2 (DW_TAG_class_type)
<2b> DW_AT_name : foo
<2f> DW_AT_byte_size : 4
<30> DW_AT_decl_file : 1
<31> DW_AT_decl_line : 1
<32> DW_AT_sibling : <0x44>
...
The DIE at 0x25 contains an intra-CU forward reference, and is deferred during
DIE indexing in the cooked_index, by adding it to m_deferred_entries.
The resulting cooked index entries are:
...
[25] ((cooked_index_entry *) 0x333b5d0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
[26] ((cooked_index_entry *) 0x333b630)
name: foo
canonical: foo
qualified: foo::foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0x333b5d0) [foo]
...
Notice that 0x2a is the parent of 0x25, and that this is why the qualified
name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo".
The parent is set here in cooked_indexer::make_index:
...
for (const auto &entry : m_deferred_entries)
{
void *obj = m_die_range_map.find (entry.spec_offset);
cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj);
m_index_storage->add (entry.die_offset, entry.tag, entry.flags,
entry.name, parent, m_per_cu);
}
...
and AFAICT, we store in m_die_range_map the parent of the respective
spec_offset DIE (though that's not clear from the comment describing it).
So, the root cause of this is that when we lookup the parent for DIE 0x25, we get
m_die_range_map.find (0x2a) == 0x2a.
This is an off-by-one error, fixed in cooked_indexer::recurse by:
...
- CORE_ADDR start = form_addr (parent_entry->die_offset,
+ CORE_ADDR start = form_addr (parent_entry->die_offset + 1,
...
which gives us:
...
[12] ((cooked_index_entry *) 0x41e21f0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0)
[13] ((cooked_index_entry *) 0x41e2190)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30739
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30739
|
|
cc-with-gnu-debuglink
When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-gnu-debuglink, I run into:
...
(gdb) PASS: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo
maint print symbols -objfile enqueued-cu-base-addr^M
(gdb) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The problem is that the CU we're trying to print is in objfile
enqueued-cu-base-addr.debug instead of enqueued-cu-base-addr.
Fix this by replacing "-objfile enqueued-cu-base-addr" with "-source cu2".
Tested on x86_64-linux.
|
|
I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-debug-names, and ran into:
...
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error)
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The first FAIL is a known issue, PR symtab/29572.
The following FAIL is a consequence of the first FAIL, so require for the
second test that the first test passes.
Tested on x86_64-linux, with target boards unix and cc-with-debug-names.
|
|
As reported in PR testsuite/30633, when running test-case
gdb.dwarf2/typeddwarf.exp with target board native-gdbserver on Ubuntu
22.04.2, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x0000000000000001 in ?? ()^M
(gdb) FAIL: gdb.dwarf2/typeddwarf.exp: runto: run to main
...
We run into the FAIL as follows:
- due to using gdbserver, we attach at the point of the first instruction, in
_start
- we then set a breakpoint at main
- the test-case is a .s file, that has main renamed to _start in the assembly,
but not in the debuginfo
- setting a breakpoint at main sets the breakpoint at the same instruction
we're currently stopped at
- continue doesn't hit the breakpoint, and we return out of _start, which
causes a sigsegv
Note that this is for the amd64 case (using gdb.dwarf2/typeddwarf-amd64.S).
For the i386 case (using gdb.dwarf2/typeddwarf.S), setting a breakpoint in
main sets it one insn after function entry, and consequently the problem does
not occur.
The FAIL is a regression since commit 90cce6c0551 ("[gdb/testsuite] Add nopie
in a few test-cases").
Without nopie the executable is PIE, with nopie it's static instead.
In the PIE case, we attach at the point of _start in the dynamic linker, and
consequently we do not skip the breakpoint in main, and also don't run into
the FAIL.
Fix this by:
- removing the -nostdlib setting, and
- renaming _start to main in both .S files.
The change to use -nostdlib and rename main to _start was originally added
in commit 6edba76fe8b (submitted here:
https://sourceware.org/pipermail/gdb-patches/2011-May/082657.html ) , I assume
to fix the problem now fixed by using nopie.
Tested on x86_64-linux.
Reported-By: Simon Marchi <simon.marchi@efficios.com>
Tested-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30633
|
|
Jakub pointed out that using DW_FORM_implicit_const with
DW_AT_bit_size would cause gdb to crash. This happened because
DW_FORM_implicit_const is not an "unsigned" form, causing as_unsigned
to assert. This patch fixes the problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30651
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Consider the test-case:
...
$ cat main.c
int main (void) { return 0; }
$ cat static-optimized-out.c
static int aaa;
...
compiled like this:
...
$ gcc-12 static-optimized-out.c main.c -g -O2 -flto
...
There's a difference in behaviour depending on symtab expansion state:
...
$ gdb -q -batch a.out -ex "print aaa"
No symbol "aaa" in current context.
$ gdb -q -batch a.out -ex "maint expand-symtab" -ex "print aaa"
$1 = <optimized out>
...
The reason for the difference is that the optimized out variable aaa:
...
<1><104>: Abbrev Number: 2 (DW_TAG_variable)
<105> DW_AT_name : aaa
<109> DW_AT_decl_file : 1
<10a> DW_AT_decl_line : 18
<10b> DW_AT_decl_column : 12
<10c> DW_AT_type : <0x110>
...
is not added to the cooked index because of this clause in abbrev_table::read:
...
else if (!has_location && !has_specification_or_origin && !has_external
&& cur_abbrev->tag == DW_TAG_variable)
cur_abbrev->interesting = false;
...
Fix this inconsistency by making sure that the optimized out variable is added
to the cooked index.
Regression tested on x86_64-linux.
Add two test-cases, a C test-case gdb.opt/static-optimized-out.exp and a dwarf
assembly test-case gdb.dwarf2/static-optimized-out.exp.
Tested gdb.opt/static-optimized-out.exp with gcc-8 to gcc-12, for which we now
consistently get:
...
(gdb) print aaa^M
$1 = <optimized out>^M
...
and with gcc 7.5.0 and clang 13.0.1, for which we still consistently get:
...
(gdb) print aaa^M
No symbol "aaa" in current context.^M
...
due to missing debug info for the variable.
PR symtab/30656
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30656
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running test-case gdb.dwarf2/forward-spec.exp with check-read1 we run
into:
...
parent: ((cooked_index_entry *) 0xFAIL: <exp>: v has a parent
7fdc1c002ed0) [ns]^M
...
The problem is using regexps containing '.' to avoid escaping, which makes
them too generic.
Fix this by eliminating the '.' from the regexps.
Tested on x86_64-linux.
|
|
When running test-case gdb.arch/i386-disp-step.exp with target board
unix/-m32/-fPIE/-pie we run into:
...
gdb compile failed, ld: i386-disp-step0.o: warning: relocation in read-only section `.text'
ld: warning: creating DT_TEXTREL in a PIE
...
Fix this by adding nopie in the compilation flags.
Likewise in a few other test-cases.
Tested on x86_64-linux.
|
|
In test-case gdb.dwarf2/implptr.exp I noticed:
...
} elseif {![is_x86_like_target]} {
# This test can only be run on x86 targets.
unsupported "needs x86-like target"
return 0
}
...
Use instead "require is_x86_like_target".
Tested on x86_64-linux.
|
|
We recently realized that symbol_needs_eval_fail.exp and
symbol_needs_eval_timeout.exp invalidly dereference an int (4 bytes on
x86_64) by reading 8 bytes (the size of a pointer).
Here how it goes:
In gdb/testsuite/gdb.dwarf2/symbol_needs_eval.c a global variable is
defined:
int exec_mask = 1;
and later both tests build some DWARF using the assembler doing:
set exec_mask_var [gdb_target_symbol exec_mask]
...
DW_TAG_variable {
{DW_AT_name a}
{DW_AT_type :$int_type_label}
{DW_AT_location {
DW_OP_addr $exec_mask_var
DW_OP_deref
...
}
}
The definition of the DW_OP_deref (from Dwarf5 2.5.1.3 Stack Operations)
says that "The size of the data retrieved from the dereferenced address
is the size of an address on the target machine."
On x86_64, the size of an int is 4 while the size of an address is 8.
The result is that when evaluating this expression, the debugger reads
outside of the `a` variable.
Fix this by using `DW_OP_deref_size $int_size` instead. To achieve
this, this patch adds the necessary steps so we can figure out what
`sizeof(int)` evaluates to for the current target.
While at it, also change the definition of the int type in the assembled
DWARF information so we use the actual target's size for an int instead
of the literal 4.
Tested on x86_64 Linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit implements a fix for a bug reported against GDB on
Fedora bugzilla...
https://bugzilla.redhat.com/show_bug.cgi?id=2166796
The test case in that bug report involved running gdb against the 'jq'
program (which is a command-line JSON processor) on Fedora 37. Since
the debug info is compiler (and compile-time option) dependent, it
won't necessarily show up in other distributions or even past or
future versions of Fedora. (E.g. when trying the example shown below
on Fedora 38, GDB says that the value of 'value' has been optimized
out. I.e. it does not demonstrate the same DWARF error that can be
see when using Fedora 37.)
That said, on Fedora 37, the bug could be reproduced as follows:
[kev@f37-1 ~]$ gdb jq -q -ex 'b src/util.c:415' -ex 'r </dev/null'
Reading symbols from jq...
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from /home/kev/.cache/debuginfod_client/9d3c8b4197350a190a74972d481de32abf641aa4/debuginfo...
No source file named src/util.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (src/util.c:415) pending.
Starting program: /usr/bin/jq </dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, jq_util_input_next_input (state=0x55555555d7f0) at src/util.c:416
416 if (state->parser == NULL) {
(gdb) p value
DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op.
This is undesirable - rather than output an error about the DWARF
info, we'd prefer to see a value, even if it is uninitialized.
Examination of the debuginfo showed the following:
<1><468f1>: Abbrev Number: 112 (DW_TAG_subprogram)
<468f2> DW_AT_external : 1
<468f2> DW_AT_name : (indirect string, offset: 0x4781): jq_util_input_next_input
<468f6> DW_AT_decl_file : 10
<468f6> DW_AT_decl_line : 411
<468f8> DW_AT_decl_column : 4
<468f9> DW_AT_prototyped : 1
<468f9> DW_AT_type : <0x3f2>
<468fd> DW_AT_sibling : <0x4692e>
...
<2><46921>: Abbrev Number: 102 (DW_TAG_variable)
<46922> DW_AT_name : (indirect string, offset: 0x8cb): value
<46926> DW_AT_decl_file : 10
<46926> DW_AT_decl_line : 414
<46928> DW_AT_decl_column : 6
<46929> DW_AT_type : <0x3f2>
Note that there's no DW_AT_location, so I looked for an abstract origin entry:
<2><2dfa0>: Abbrev Number: 90 (DW_TAG_variable)
<2dfa1> DW_AT_abstract_origin: <0x46921>
<2dfa5> DW_AT_location : 0x27cf1 (location list)
<2dfa9> DW_AT_GNU_locviews: 0x27ce1
(Note that the DW_AT_abstract_origin attribute's value is 0x46921 which
is the DIE for the local variable "value".)
Looking at the location list, I see:
00027cf1 v000000000000000 v000000000000000 views at 00027ce1 for:
000000000002f8fe 000000000002f92e (DW_OP_reg13 (r13); DW_OP_GNU_uninit; DW_OP_piece: 8; DW_OP_reg12 (r12); DW_OP_GNU_uninit; DW_OP_piece: 8)
While DW_OP_GNU_uninit is not the very last op, it is the last op
prior to DW_OP_piece. The fix involved changing the DW_OP_GNU_uninit
case in dwarf_expr_context::execute_stack_op in gdb/dwarf2/expr.c so
that DW_OP_GNU_uninit may appear just before DW_OP_piece.
With the fix in place, attempting to print 'value' now looks like
this:
(gdb) p value
$1 = [uninitialized] {kind_flags = 0 '\000', pad_ = 0 '\000', offset = 0,
size = 0, u = {ptr = 0x0, number = 0}}
Note that "[uninitialized]" is part of the output. (But also note
that there's an extra space character.)
I've made a new test case,
gdb.dwarf2/DW_OP_piece_with_DW_OP_GNU_uninit.exp, by adapting an
existing one, gdb.dwarf2/opt-out-not-implptr.exp. Since it uses the
DWARF assembler, the test case does not depend on a specific compiler
version or compiler options.
Tested on Fedora 37 and Fedora 38.
|
|
The gdb.dwarf2/dw2-prologue-end-2.exp test was failing for both AArch64 and
Arm.
As Tom pointed out here (https://inbox.sourceware.org/gdb-patches/6663707c-4297-c2f2-a0bd-f3e84fc62aad@suse.de/),
there are issues with both the prologue skipper for AArch64 and Arm and an
incorrect assumption by the testcase.
This patch fixes both of AArch64's and Arm's prologue skippers to not skip past
the end of a function. It also incorporates a fix to the testcase so it
doesn't assume the prologue skipper will stop at the first instruction of the
functions/labels.
Regression-tested on aarch64-linux/arm-linux Ubuntu 20.04/22.04 and
x86_64-linux Ubuntu 20.04.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30506
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Co-Authored-By: Luis Machado <luis.machado@arm.com>
|
|
This commit adds a test for the following commit:
commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff
Date: Tue Nov 28 16:23:32 2006 +0000
* symtab.c (find_pc_sect_line): Do not return a line before
the start of a symtab.
We have been carrying a test for that commit in the Fedora GDB tree
since that commit was added to GDB. I don't know why the test wasn't
added along with the original commit, but as was written, the test is
pretty gross, it uses objcopy to pull the .text section from an object
file, which was then injected into another source file within a .asm
statement...
... these days we can just make use of the DWARF assembler to achieve
the same results, so I've rewritten the test and think it is worth
adding this to upstream GDB.
The original patch was about about how we find the best symtab and
line table entry, and what to do when GDB can't find a good match.
The new test creates a CU with two functions, only one of which is
covered by the line table. With the above patch reverted GDB returns
an invalid address.
With the above patch reverted I did run the testsuite to see what
other tests might already be exercising this functionality, and I
found two tests:
gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp
gdb.dwarf2/dw2-vendor-extended-opcode.exp
These are pretty similar, they either create minimal, or no line table
for one of the functions in the source file, and as a consequence GDB
returns an unexpected address at some point during the test.
However, both of those tests are really focused on other issues, so I
think this new test does add some value. Plus the new test is not
large, so it's not a huge cost to also run this new test.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The cooked index scanner has special code to handle forward DIE
references. However, a bug report lead to the discovery that this
code does not work -- the "deferred_entry::spec_offset" field is
written to but never used, i.e., the lookup is done using the wrong
key.
This patch fixes the bug and adds a regression test.
The test in the bug itself used a thread_local variable, which
provoked a failure at runtime. This test instead uses "maint print
objfiles" and then inspects to ensure that the entry in question has a
parent. This lets us avoid a clang dependency in the test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30271
|
|
The commit:
commit 08ec06d6440745ef9204d39197aa1e732df41056
Date: Wed Mar 29 10:41:07 2023 +0100
gdb/testsuite: special case '^' in gdb_test pattern
Added some special handling of '^' to gdb_test -- a leading '^' will
cause the command regexp to automatically be included in the expected
output pattern.
It was pointed out that the '-wrap' flag of gdb_test_multiple is
supposed to work in the same way as gdb_test, and that the recent
changes for '^' had not been replicated for gdb_test_multiple. This
patch addresses this issue.
So, after this commit, the following two constructs should have the
same meaning:
gdb_test "command" "^output" "test name"
gdb_test_multiple "command" "test name" {
-re -wrap "^output" {
pass $gdb_test_name
}
}
In both cases the '^' will case gdb.exp to inject a regexp that
matches 'command' after the '^' and before the 'output', this is in
addition to adding the $gdb_prompt pattern after 'output' in the
normal way.
The special '^' handling is only applied when '-wrap' is used, as this
is the only mode that aims to mimic gdb_test.
While working on this patch I realised that I could actually improve
the logic for the special '^' handling in the case where the expected
output pattern is empty. I replicated these updates for both gdb_test
and gdb_test_multiple in order to keep these two paths in sync.
There were a small number of tests that needed adjustment after this
change, mostly just removing command regexps that are now added
automatically, but the gdb.base/settings.exp case was a little weird
as it turns out trying to match a single blank line is probably harder
now than it used to be -- still, I suspect this is a pretty rare case,
so I think the benefits (improved anchoring) outweigh this small
downside (IMHO).
|
|
When running test-case gdb.dwarf2/opt-out-not-implptr.exp with target board
unix/-m32 we have:
...
(gdb) print noptr^M
$1 = {0, <optimized out>, <optimized out>, <optimized out>}^M
(gdb) FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr
...
The problem happens when evaluating this dwarf expression:
...
<45> DW_AT_location : 13 byte block: 10 86 ea d7 d0 96 8e cf 92 5c 9f 93 8 \
(DW_OP_constu: 6639779683436459270; DW_OP_stack_value; DW_OP_piece: 8)
...
The DW_OP_constu pushes a value with "generic type" on to the DWARF stack, and
the "generic type" has the size of an address on the target machine, which for
target board unix/-m32 is 4 bytes. Consequently, the constant is abbreviated.
Next, the DW_OP_piece declares that the resulting 4-byte value is 8 bytes
large, and we hit this clause in rw_pieced_value:
...
/* Use zeroes if piece reaches beyond stack value. */
if (p->offset + p->size > stack_value_size_bits)
break;
...
and consequently get a zero.
We could just add require is_target_64 to the test-case, but instead, add a
32-bit case and require is_target_64 just for the 64-bit case.
Tested on x86_64-linux.
|
|
A user reported a bug where printing a certain array of integer types
would result in the nonsensical:
(gdb) p l_126
$1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>}
I tracked this down to some issues in the DWARF expression code.
First, check_pieced_synthetic_pointer did not account for the
situation where a location expression does not describe all the bits
of a value -- in this case it returned true, meaning there is a
synthetic pointer, but in fact these bits are optimized out. (It
turns out this incorrect output had already been erroneously tested
for as well.)
Next, rw_pieced_value did not mark these bits as optimized-out,
either.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30296
|
|
After this commit:
commit e2f620135d92f7cd670af4e524fffec7ac307666
Date: Thu Mar 30 13:26:25 2023 +0100
gdb/testsuite: change newline patterns used in gdb_test
It was pointed out in PR gdb/30403 that the same patterns can be found
in other lib/gdb.exp procs and that it would probably be a good idea
if these procs remained in sync with gdb_test. Actually, the bug
specifically calls out gdb_test_multiple when using with '-wrap', but
I found a couple of other locations in gdb_continue_to_breakpoint,
gdb_test_multiline, get_valueof, and get_local_valueof.
In all these locations one or both of the following issues are
addressed:
1. A leading pattern of '[\r\n]*' is pointless. If there is a
newline it will be matched, but if there is not then the testsuite
doesn't care. Also, as expect is happy to skip non-matched output
at the start of a pattern, if there is a newline expect is happy to
skip over it before matching the rest. As such, this leading
pattern is removed.
2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow
unexpected blank lines at the end of a command's output, but also,
if the pattern from the test script ends with a '\r', '\n', or '.'
then these will partially match the trailing newline, with the
remainder of the newline matched by the pattern from gdb.exp. This
split matching doesn't add any value, it's just something that has
appeared as a consequence of how gdb.exp was originally written. In
this case the '\[\r\n\]*' is replaced with '\r\n'.
I've rerun the testsuite and fixed the regressions that I saw, these
were places where GDB emits a blank line at the end of the command
output, which we now need to explicitly match in the test script, this
was for:
gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
gdb.guile/guile.exp
gdb.python/python.exp
Or a location where the test script was matching part of the newline
sequence, while gdb.exp was previously matching the remainder of the
newline sequence. Now we rely on gdb.exp to match the complete
newline sequence, this was for:
gdb.base/commands.exp
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403
|
|
In gdb.dwarf2/dw2-abs-hi-pc.exp we do:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...
The use of expr is not idiomatic. Fix this by using set instead:
...
set sources [lmap i $sources { set tmp $srcdir/$subdir/$i }]
...
Reported-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Andreas Schwab <schwab@suse.de>
|
|
Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat:
...
set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }]
...
but that's only supported starting tcl 8.6.
Fix this by using "expr" instead:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...
Tested on x86_64-linux.
|
|
[ Changes in v2:
- rebase on trunk
Changes in v3:
- add test-case ]
We should exclude matches to the ending PC to prevent false matches with the
next function, as prologue_end is located at the end PC.
<fun1>:
0x00: ... <-- start_pc
0x04: ...
0x08: ... <-- breakpoint
0x0c: ret
<fun2>:
0x10: ret <-- end_pc | prologue_end of fun2
Tested on x86_64-linux.
Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1])
Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case)
Approved-by: Kevin Buettner <kevinb@redhat.com>
[1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
PR symtab/30369
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369
|
|
With DWARF 5, it's possible to produce an empty file name in the File Name
Table of the .debug_line section:
...
The File Name Table (offset 0x112, lines 1, columns 2):
Entry Dir Name
0 1 (indirect line string, offset: 0x2d):
...
Currently, when gdb reads an exec containing such debug info, it segfaults:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \
gdb/dwarf2/read.c:18716
18716 if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL)
...
because read_direct_string transforms "" into a nullptr, and we end up
dereferencing the nullptr.
Note that the behaviour of read_direct_string has been present since repo
creation.
Fix this in read_formatted_entries, by transforming nullptr filenames in to ""
filenames.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
PR symtab/30357
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357
|
|
Fix test-case gdb.dwarf2/imported-unit-bp-c.exp on remote by removing a
downloaded source file.
Tested on x86_64-linux.
|
|
Declare test-case gdb.dwarf2/gdb-add-index-symlink.exp unsupported for remote
host, because the current implementation of gdb_ensure_index doesn't support it.
Tested on x86_64-linux.
|
