objdump: '-S' should trigger search for separate debuginfo.
Add with_source_code to the command line options that trigger
might_need_separate_debug_info and dump_any_debugging. This helps
'objdump -S' download missing files via debuginfod without the need for
specifying extra command line options like '-L'.
Bruno Larsen [Wed, 20 Jul 2022 19:44:37 +0000 (16:44 -0300)]
gdb/testsuite: Update gdb.base/so-impl-ld.exp
gdb.base/so-impl-ld.exp was setup assuming that the compiler would add
epilogue information and that GDB would stop in the } line. This would
make clang tests fail like so:
step^M
solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M
7|__ return arg*arg;|__|___/* HERE */^M
(gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call
next^M
main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M
22|_ return 0;^M
(gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call
next^M
0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call
This patch changes it so solib_main has 2 lines where GDB can stop
regardless of compiler choices, and updates the exp file to
generically deal with unknown number of steps until leaving that
function.
Bruno Larsen [Wed, 20 Jul 2022 19:44:26 +0000 (16:44 -0300)]
gdb/testsuite: introduce gdb_step_until
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.
Bruno Larsen [Wed, 20 Jul 2022 19:44:36 +0000 (16:44 -0300)]
explicitly test for stderr in gdb.base/dprintf.exp
Not all compilers add stderr debug information when compiling a
program. Clang, for instance, prefers to add nothing from standard
libraries and let an external debug package have this information.
Because of this, gdb.base/dprintf.exp was failing when GDB attempted to
use dprintf as a call to fprintf(stderrr, ...), like this:
(gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call
continue
Continuing.
kickoff 1234
also to stderr 1234
'stderr' has unknown type; cast it to its declared type
(gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout)
To avoid this false positive, we explicitly test to see if
the compiler has added information about stderr at all, and abort
testing dprintf as an fprintf call if it is unavailable.
Jiangshuai Li [Tue, 13 Sep 2022 03:20:54 +0000 (11:20 +0800)]
gdbserver/csky add csky gdbserver support
Add new files:
gdb/arch/csky.c
gdb/arch/csky.h
gdb/features/cskyv2-linux.c
gdbserver/linux-csky-low.cc
1. In gdb/arch/csky.c file, add function "csky_create_target_description()"
for csky_target::low_arch_setup(). later, it can be used for csky native gdb.
2. In gdb/features/cskyv2-linux.c file, create target_tdesc for csky, include
gprs, pc, hi, lo, float, vector and float control registers.
3. In gdbserver/linux-csky-low.cc file, using PTRACE_GET/SET_RGESET to
get/set registers. The main data structures in asm/ptrace.h are:
struct pt_regs {
unsigned long tls;
unsigned long lr;
unsigned long pc;
unsigned long sr;
unsigned long usp;
/*
* a0, a1, a2, a3:
* r0, r1, r2, r3
*/
unsigned long orig_a0;
unsigned long a0;
unsigned long a1;
unsigned long a2;
unsigned long a3;
/*
* r4 ~ r13
*/
unsigned long regs[10];
/* r16 ~ r30 */
unsigned long exregs[15];
unsigned long rhi;
unsigned long rlo;
unsigned long dcsr;
};
struct user_fp {
unsigned long vr[96];
unsigned long fcr;
unsigned long fesr;
unsigned long fid;
unsigned long reserved;
};
Tom Tromey [Wed, 17 Aug 2022 17:47:17 +0000 (11:47 -0600)]
Use checked_static_cast in more places
I went through all the uses of dynamic_cast<> in gdb, looking for ones
that could be replaced with checked_static_cast. This patch is the
result. Regression tested on x86-64 Fedora 34.
Peter Bergner [Mon, 12 Sep 2022 19:56:20 +0000 (14:56 -0500)]
ppc: Document the -mfuture and -Mfuture options and make them usable
The -mfuture and -Mfuture options which are used for adding potential
new ISA instructions were not documented. They also lacked a bitmask
so new instructions could not be enabled by those options. Fixed.
Bruno Larsen [Wed, 20 Jul 2022 19:44:34 +0000 (16:44 -0300)]
add xfails to gdb.base/complex-parts.exp when testing with clang
clang doesn't add encoding to the name of complex variables, only says
that the type name is complex, making the relevant tests fail.
This patch adds the xfails to the tests that expect the variable name to
include it.
These symbols are local static variables, and "main" is the name of
the function they are defined in. GCC instead appends a sequence
number to the linkage name:
$ nm -A call-ar-st.gcc | grep integer_
call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968
$ nm -A call-ar-st.clang | grep integer_
call-ar-st:00000000004061a0 b main.integer_array
This commit changes the testcase to accept both outputs, as they are
functionally identical.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4
Bruno Larsen [Wed, 20 Jul 2022 19:44:31 +0000 (16:44 -0300)]
update gdb.base/info-program.exp to not fail with clang
The test specifically mentions that it doesn't care where the program
stops, however it was still testing for a specific location. The clang
compiler emits different line information for epilogue, so GDB reports a
different stopping location, depending on the used compiler. With this
patch the test works even with clang.
Bruno Larsen [Wed, 20 Jul 2022 19:44:30 +0000 (16:44 -0300)]
gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang
Clang organizes the variables differently to gcc in the original version
of this code, leading to the following differences when testing
p (int*) &dataglobal + 1
gcc:
$16 = (int *) 0x404034 <datalocal>
clang:
$16 = (int *) 0x404034 <dataglobal8>
However, since the important part of this test doesn't seem to be which
symbol is linked, but rather if GDB is correctly increasing the
address. This test was changed to actually measure address changes,
instead of assuming the ordering and naming of symbols.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Martin Storsjö [Tue, 6 Sep 2022 15:39:07 +0000 (18:39 +0300)]
ld: pe: Apply review suggestions on the existing exports/imports arrays
Use a separate explicit max_exports/imports field, instead of
deducing it from the number of allocated elements. Use a named
constant for the incremental growth of the array.
Use bool instead of int for boolean values.
Remove an unnecessary if statement/scope in the def_file_free
function.
Add more verbose comments about parameters, and about insertion
into an array of structs.
Generally use unsigned integers for all array indices and sizes.
The num_exports/imports fields are kept as is as signed integers,
since changing them to unsigned would require a disproportionate
amount of changes ti pe-dll.c to avoid comparisons between signed
and unsigned.
Simply use xrealloc instead of a check and xmalloc/xrealloc;
xrealloc can take NULL as the first parameter (and does a similar
check internally). (This wasn't requested in review though,
but noticed while working on the code.)
Martin Storsjö [Fri, 2 Sep 2022 09:22:29 +0000 (12:22 +0300)]
ld: pe: Improve performance of object file exclude symbol directives
Store the list of excluded symbols in a sorted list, speeding up
checking for duplicates when inserting new entries.
This is done in the same way as is done for exports and imports
(while the previous implementation was done with a linked list,
based on the implementation for aligncomm).
When linking object files with excluded symbols, there can potentially
be very large numbers of excluded symbols (just like builds with
exports can have a large number of exported symbols).
This improves the link performance somewhat, when linking with large
numbers of excluded symbols.
The later actual use of the excluded symbols within pe-dll.c
handles them via an unordered linked list still, though.
Tom de Vries [Mon, 12 Sep 2022 08:05:18 +0000 (10:05 +0200)]
[gdb] Fix abort in selftest run_on_main_thread with ^C
When running selftest run_on_main_thread and pressing ^C, we can run into:
...
Running selftest run_on_main_thread.
terminate called without an active exception
Fatal signal: Aborted
...
The selftest function looks like this:
...
static void
run_tests ()
{
std::thread thread;
done = false;
{
gdb::block_signals blocker;
thread = std::thread (set_done);
}
while (!done && gdb_do_one_event () >= 0)
;
/* Actually the test will just hang, but we want to test
something. */
SELF_CHECK (done);
thread.join ();
}
...
The error message we see is due to the destructor of thread being called while
thread is joinable.
This is supposed to be taken care of by thread.join (), but the ^C prevents
that one from being called, while the destructor is still called.
Fix this by ensuring thread.join () is called (if indeed required) before the
destructor using SCOPE_EXIT.
Tom de Vries [Mon, 12 Sep 2022 08:05:18 +0000 (10:05 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for ppc64le
In commit cd919f5533c ("[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 cd919f5533c, and setting the breakpoint on
${func}_label instead.
Tom de Vries [Mon, 12 Sep 2022 08:05:18 +0000 (10:05 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp with clang
When running test-case gdb.dwarf2/dw2-dir-file-name.exp with clang, we run
into:
...
(gdb) break *compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400580^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x0000000000400580 in \
compdir_missing.ldir_missing.file_basename ()^M
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
The problem is that the test-case uses labels outside functions, which is know
to cause problem with clang, as documented in the comment for proc
function_range.
Fix this by using get_func_info instead.
Tested on x86_64-linux, with both gcc 7.5.0 and clang 13.0.0.
Jan Beulich [Mon, 12 Sep 2022 06:19:55 +0000 (08:19 +0200)]
x86: avoid i386_dis_printf()'s staging area for a fair part of output
While PR binutils/29483 has now been addressed differently, this
originally proposed change still has its merits: Avoiding vsnprintf()
for typically far more than half of the overall output results in a 2-3%
performance gain in my testing (with debug builds of objdump, libbfd,
and libopcodes).
With that part of output no longer using staging_area[], the array also
doesn't need to be quite as large anymore (the largest presently used
size is 27, from "64-bit address is disabled").
While limiting the scope of "res" it became apparent that
- no caller cares about the function's return value,
- the comment about the return value was wrong,
- a particular positive return value would have been meaningless to the
caller.
Therefore convert the function to return "void" at the same time.
Nelson Chu [Mon, 12 Sep 2022 01:26:52 +0000 (09:26 +0800)]
RISC-V: PR28509, the default visibility symbol cannot be referenced by R_RISCV_JAL.
When generating the shared object, the default visibility symbols may bind
externally, which means they will be exported to the dynamic symbol table,
and are preemptible by default. These symbols cannot be referenced by the
non-pic R_RISCV_JAL and R_RISCV_RVC_JUMP. However, consider that linker
may relax the R_RISCV_CALL relocations to R_RISCV_JAL or R_RISCV_RVC_JUMP,
if these relocations are relocated to the plt entries, then we won't report
error for them. Perhaps we also need the similar checks for the
R_RISCV_BRANCH and R_RISCV_RVC_BRANCH relocations.
After applying this patch, and revert the following glibc patch,
riscv: Fix incorrect jal with HIDDEN_JUMPTARGET
https://sourceware.org/git/?p=glibc.git;a=commit;h=68389203832ab39dd0dbaabbc4059e7fff51c29b
I get the expected errors as follows,
ld: relocation R_RISCV_RVC_JUMP against `__sigsetjmp' which may bind externally can not be used when making a shared object; recompile with -fPIC
ld: relocation R_RISCV_JAL against `exit' which may bind externally can not be used when making a shared object; recompile with -fPIC
Besides, we also have similar changes for libgcc,
RISC-V: jal cannot refer to a default visibility symbol for shared object
https://github.com/gcc-mirror/gcc/commit/45116f342057b7facecd3d05c2091ce3a77eda59
bfd/
pr 28509
* elfnn-riscv.c (riscv_elf_relocate_section): Report errors when
makeing a shard object, and the referenced symbols of R_RISCV_JAL
relocations are default visibility. Besides, we should handle most
of the cases here, so don't need the unresolvable check later for
R_RISCV_JAL and R_RISCV_RVC_JUMP.
ld/
pr 28509
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/lib-nopic-01a.s: Removed.
* testsuite/ld-riscv-elf/lib-nopic-01b.d: Likewise.
* testsuite/ld-riscv-elf/lib-nopic-01b.s: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-01.d: New testcase.
* testsuite/ld-riscv-elf/shared-lib-nopic-01.s: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-02.d: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-02.s: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-03.d: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-03.s: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-04.d: Likewise.
* testsuite/ld-riscv-elf/shared-lib-nopic-04.s: Likewise.
Tom de Vries [Sun, 11 Sep 2022 07:01:03 +0000 (09:01 +0200)]
[gdb/symtab] Fix handling of DW_TAG_unspecified_type
Currently, the test-case contained in this patch fails:
...
(gdb) p (int) foo ()^M
Invalid cast.^M
(gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo ()
...
because DW_TAG_unspecified_type is translated as void.
There's some code in read_unspecified_type that marks the type as stub, but
that's only active for ada:
...
if (cu->lang () == language_ada)
type->set_is_stub (true);
...
Fix this by:
- marking the type as a stub for all languages, and
- handling the stub return type case in call_function_by_hand_dummy.
Tsukasa OI [Mon, 5 Sep 2022 07:54:51 +0000 (07:54 +0000)]
RISC-V: Fix vector CSR requirements
Vector CSRs are also required on smaller vector subsets.
Not only that the most of vector CSRs are general purpose (and must be
accessible for every vector subsets), current minimum vector subset 'Zve32x'
requires fixed point arithmetic, making remaining non-general purpose
(fixed point arithmetic only) CSRs mandatory for such subsets.
So, those CSRs must be accessible from 'Zve32x', not just from 'V'.
This commit fixes this issue which caused CSR accessibility warnings.
gas/ChangeLog:
* config/tc-riscv.c (riscv_csr_address): Change vector CSR
requirement from 'V' to 'Zve32x'.
* testsuite/gas/riscv/csr-version-1p9p1.l: Change vector CSR
requirement from 'V' to 'Zve32x'.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
Carl Love [Thu, 8 Sep 2022 15:13:03 +0000 (15:13 +0000)]
Fix hardware watchpoint check in test gdb.base/watchpoint-reuse-slot.exp
This test generates 48 failures on Power 9 when testing with HW watchpoints
enabled. Note HW watchpoint support is disabled on Power 9 due to a HW bug.
The skip_hw_watchpoint_tests proc must be used to correctly determine
if the processor supports HW watchpoints.
This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests check.
This patch was tested on Power 9, Power 10 and X86-64 with no regressions.
Nick Clifton [Thu, 8 Sep 2022 11:43:33 +0000 (12:43 +0100)]
Gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)
PR 29559
* dwarf2dbg.c (out_debug_info): Place DW_TAG_unspecified_type at
the end of the list of children, not at the start of the CU
information.
* testsuite/gas/elf/dwarf-3-func.d: Update expected output.
* testsuite/gas/elf/dwarf-5-func-global.d: Likewise.
* testsuite/gas/elf/dwarf-5-func-local.d: Likewise.
* testsuite/gas/elf/dwarf-5-func.d: Likewise.
Tsukasa OI [Thu, 8 Sep 2022 02:54:15 +0000 (02:54 +0000)]
gdbsupport: Fix config.status dependency
Commit 171fba11ab27 ("Make GDBserver abort on internal error in development mode")
created a new substitution CONFIG_STATUS_DEPENDENCIES but this is used by
Makefile.in (which is not regenerated by that commit). After regenerating
it, it is found that CONFIG_STATUS_DEPENDENCIES value is not valid, making
gdbsupport fail to build.
Since the CONFIG_STATUS_DEPENDENCIES value is used in the Makefile, macro
substitution must have a Makefile format but commit 171fba11ab27 used shell
format "$srcdir/../bfd/development.sh".
This commit fixes this issue by substituting "$srcdir" (shell format) to
"$(srcdir)" (Makefile format). It preserves the dependency as Pedro
intended and fixes the build problem.
It also regenerates corresponding files with the maintainer mode.
Tom de Vries [Wed, 7 Sep 2022 17:14:17 +0000 (19:14 +0200)]
[gdb/testsuite] xfail gdb.ada/O2_float_param.exp for aarch64 and gcc 7.5.0
On aarch64-linux, with gcc 7.5.0, we run into:
...
(gdb) frame^M
#0 callee.increment (val=99.0, val@entry=9.18340949e-41, msg=...) at \
callee.adb:21^M
21 if Val > 200.0 then^M
(gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: frame
...
The problem is a GCC bug, filed as "PR98148 - [AArch64] Wrong location
expression for function entry values" (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148 ).
Tom de Vries [Wed, 7 Sep 2022 09:29:11 +0000 (11:29 +0200)]
[gdb/testsuite] Fix gdb.ada/access_tagged_param.exp for aarch64
On aarch64-linux, I run into:
...
Breakpoint 2, pck.inspect (obj=0x430eb0 \
<system.pool_global.global_pool_object>, <objL>=0) at pck.adb:17^M
17 procedure Inspect (Obj: access Top_T'Class) is^M
(gdb) FAIL: gdb.ada/access_tagged_param.exp: continue
...
while on x86_64-linux, I see:
...
Breakpoint 2, pck.inspect (obj=0x62b2a0, <objL>=2) at pck.adb:19^M
19 null;^M
(gdb) PASS: gdb.ada/access_tagged_param.exp: continue
...
Note the different line numbers, 17 vs 19.
The difference comes from the gdbarch_skip_prologue implementation.
The amd64_skip_prologue implementation doesn't use gcc line numbers, and falls
back to the architecture-specific prologue analyzer, which correctly skips
past the prologue, to address 0x4022f7:
... 00000000004022ec <pck__inspect>:
4022ec: 55 push %rbp
4022ed: 48 89 e5 mov %rsp,%rbp
4022f0: 48 89 7d f8 mov %rdi,-0x8(%rbp)
4022f4: 89 75 f4 mov %esi,-0xc(%rbp)
4022f7: 90 nop
4022f8: 90 nop
4022f9: 5d pop %rbp
4022fa: c3 ret
...
The aarch64_skip_prologue implementation does use gcc line numbers, which are:
...
File name Line number Starting address View Stmt
pck.adb 17 0x402580 x
pck.adb 17 0x402580 1 x
pck.adb 19 0x40258c x
pck.adb 20 0x402590 x
...
and which are represented like this internally in gdb:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
0 17 0x0000000000402580 Y
1 17 0x0000000000402580 Y
2 19 0x000000000040258c Y
3 20 0x0000000000402590 Y
4 END 0x00000000004025a0 Y
...
The second entry is interpreted as end-of-prologue, so 0x402580 is used, while
the actual end of the prologue is at 0x40258c:
... 0000000000402580 <pck__inspect>:
402580: d10043ff sub sp, sp, #0x10
402584: f90007e0 str x0, [sp, #8]
402588: b90007e1 str w1, [sp, #4]
40258c: d503201f nop
402590: d503201f nop
402594: 910043ff add sp, sp, #0x10
402598: d65f03c0 ret
40259c: d503201f nop
...
Note that the architecture-specific prologue analyzer would have gotten this
right:
...
(gdb) p /x aarch64_analyze_prologue (gdbarch, pc, pc + 128, 0)
$2 = 0x40258c
...
Fix the FAIL by making the test-case more robust against problems in prologue
skipping, by setting the breakpoint on line 19 instead.
Luis Machado [Wed, 3 Aug 2022 23:00:26 +0000 (00:00 +0100)]
Fix endianness handling for arm record self tests
v2:
- Add 32-bit Arm instruction selftest
- Refactored abstract memory reader into abstract instruction reader
- Adjusted code to use templated type and to use host endianness as
opposed to target endianness.
The arm record tests handle 16-bit and 32-bit thumb instructions, but the
code is laid out in a way that handles the 32-bit thumb instructions as
two 16-bit parts.
This is fine, but it is prone to host-endianness issues given how the two
16-bit parts are stored and how they are accessed later on. Arm is
little-endian by default, so running this test with a GDB built with
--enable-targets=all and on a big endian host will run into the following:
Running selftest arm-record.
Process record and replay target doesn't support syscall number -2036195
Process record does not support instruction 0x7f70ee1d at address 0x0.
Self test failed: self-test failed at ../../binutils-gdb/gdb/arm-tdep.c:14482
It turns out the abstract memory reader class is more generic than it needs to
be, and we can simplify the code a bit by assuming we have a simple instruction
reader that only reads up to 4 bytes, which is the length of a 32-bit
instruction.
Instead of returning a bool, we return instead the instruction that has been
read. This way we avoid having to deal with the endianness conversion, and use
the host endianness instead. The Arm selftests can be executed on non-Arm
hosts.
While at it, Tom suggested adding a 32-bit Arm instruction selftest to increase
the coverage of the selftests.
Tom de Vries [Wed, 7 Sep 2022 07:59:12 +0000 (09:59 +0200)]
[gdb/testsuite] Use prototype to call libc functions
On openSUSE Tumbleweed (using glibc 2.36), I run into:
...
(gdb) print /d (int) munmap (4198400, 4096)^M
Invalid cast.^M
(gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: \
get integer valueof "(int) munmap (4198400, 4096)"
...
The problem is that after starting the executable, the symbol has type
"void (*) (void)":
...
(gdb) p munmap
$1 = {<text variable, no debug info>} 0x401030 <munmap@plt>
(gdb) start
...
(gdb) p munmap
$2 = {void (void)} 0x7ffff7feb9a0 <__GI_munmap>
...
which causes the "Invalid cast" error.
Looking at the debug info for glibc for symbol __GI_munmap:
...
<0><189683>: Abbrev Number: 1 (DW_TAG_compile_unit)
<189691> DW_AT_name : ../sysdeps/unix/syscall-template.S
<189699> DW_AT_producer : GNU AS 2.39.0
<1><1896ae>: Abbrev Number: 2 (DW_TAG_subprogram)
<1896af> DW_AT_name : __GI___munmap
<1896b3> DW_AT_external : 1
<1896b4> DW_AT_low_pc : 0x10cad0
<1896bc> DW_AT_high_pc : 37
...
that's probably caused by this bit (or similar bits for other munmap aliases).
This is fixed in gas on trunk by commit 5578fbf672e ("GAS: Add a return type
tag to DWARF DIEs generated for function symbols").
Work around this (for say gas 2.39) by explicitly specifying the prototype for
munmap.
Likewise for getpid in a couple of other test-cases.
Currently objdump -S is not able to make use files downloaded from debuginfod.
This is due to bfd_find_nearest_line_discriminator being unable to locate any
separate debuginfo files in the debuginfod cache. Additionally objdump lacked
a call to debuginfod_find_source in order to download missing source files.
Fix this by using bfd_find_nearest_line_with_alt instead of
bfd_find_nearest_line_discriminator. Also add a call to
debuginfod_find_source in order to download missing source files.
bfd_find_nearest_line_with_alt functions like bfd_find_nearest_line with
the addition of a parameter for specifying the filename of a supplementary
debug file such as one referenced by .gnu_debugaltlink or .debug_sup.
This patch focuses on implementing bfd_find_nearest_line_with_alt
support for ELF/DWARF2 .gnu_debugaltlink. For other targets this
function simply sets the invalid_operation bfd_error.
Tsukasa OI [Tue, 30 Aug 2022 12:21:13 +0000 (12:21 +0000)]
gdb: Add non-enum disassembler options
This is paired with "opcodes: Add non-enum disassembler options".
There is a portable mechanism for disassembler options and used on some
architectures:
- ARC
- Arm
- MIPS
- PowerPC
- RISC-V
- S/390
However, it only supports following forms:
- [NAME]
- [NAME]=[ENUM_VALUE]
Valid values for [ENUM_VALUE] must be predefined in
disasm_option_arg_t.values. For instance, for -M cpu=[CPU] in ARC
architecture, opcodes/arc-dis.c builds valid CPU model list from
include/elf/arc-cpu.def.
Tom de Vries [Tue, 6 Sep 2022 08:15:01 +0000 (10:15 +0200)]
[gdb/symtab] Support .debug_names section with TUs in .debug_info
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.
Tom de Vries [Tue, 6 Sep 2022 08:15:00 +0000 (10:15 +0200)]
[gdb/testsuite] Add gdb.dwarf2/debug-names-tu.exp
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
...
Tsukasa OI [Tue, 30 Aug 2022 12:20:30 +0000 (12:20 +0000)]
opcodes: Add non-enum disassembler options
This is paired with "gdb: Add non-enum disassembler options".
There is a portable mechanism for disassembler options and used on some
architectures:
- ARC
- Arm
- MIPS
- PowerPC
- RISC-V
- S/390
However, it only supports following forms:
- [NAME]
- [NAME]=[ENUM_VALUE]
Valid values for [ENUM_VALUE] must be predefined in
disasm_option_arg_t.values. For instance, for -M cpu=[CPU] in ARC
architecture, opcodes/arc-dis.c builds valid CPU model list from
include/elf/arc-cpu.def.
changes were made to the simulator source to handle the new libopcodes
disassembler styling API.
Unfortunately, these changes broke building GDB with the erc32 (sparc)
simulator, like this:
../src/configure --target=sparc-linux
make all-gdb
....
/usr/bin/ld: ../sim/erc32/libsim.a(interf.o): in function `sim_open':
/tmp/build/sim/../../src/sim/erc32/interf.c:247: undefined reference to `fprintf_styled'
collect2: error: ld returned 1 exit status
The problem is that in commit 7b01c1cc1d11 the fprintf_styled function
was added into sis.c. This file is only used when building the 'run'
binary, that is, the standalone simulator, and is not included in the
libsim.a library.
Now, the obvious fix would be to move fprintf_styled into libsim.a,
however, that turns out to be tricky.
The erc32 simulator currently has two copies of the function run_sim,
one in sis.c, and one in interf.c, both of these copies are global.
Currently, the 'run' binary links fine, though I suspect this might be
pure luck. When I tried moving fprintf_styled into interf.c, I ran
into multiple-definition (of run_sim) errors. I suspect that by
requiring the linker to pull in fprintf_styled from libsim.a I was
changing the order in which symbols were loaded, and the linker was
now seeing both copies of run_sim, while currently we only see one
copy.
The ideal solution of course, would be to merge the two similar, but
slightly different copies of run_sim, and just use the one copy. Then
we could safely move fprintf_styled into interf.c too, and all would
be good.
But I don't have time right now to start debugging the erc32
simulator, so I wanted a solution that fixes the build without
introducing multiple definition errors.
The easiest solution I think is to just have two copies of
fprintf_styled, one in sis.c, and one in interf.c. Unlike run_sim,
these two copies are both static, so we will not run into multiple
definition issues with this function. The functions themselves are
not very big, so it's not a huge amount of duplicate code.
I am very aware that this is not an ideal solution, and I would
welcome anyone who wants to take on fixing the run_sim problem
properly, and then cleanup the fprintf_styled duplication.
Max Filippov [Tue, 23 Aug 2022 12:25:55 +0000 (05:25 -0700)]
xtensa: bfd: fix TLS relocations generated for PIE
When generating TLS dynamic relocations the existing xtensa BFD code
treats linking to a PIE exactly as linking to a shared object, resulting
in generation of wrong relocations for TLS entries. Fix that and add
tests.
bfd/
* elf32-xtensa.c (elf_xtensa_check_relocs): Use bfd_link_dll
instead of bfd_link_pic. Add elf_xtensa_dynamic_symbol_p test
when generating GOT entries.
(elf_xtensa_relocate_section): Use bfd_link_dll instead of
bfd_link_pic.
ld/
* testsuite/ld-xtensa/tlspie.dd: New file.
* testsuite/ld-xtensa/tlspie.rd: New file.
* testsuite/ld-xtensa/tlspie.sd: New file.
* testsuite/ld-xtensa/tlspie.td: New file.
* testsuite/ld-xtensa/xtensa-linux.exp (TLS PIE transitions):
New test.
Max Filippov [Thu, 18 Aug 2022 09:46:38 +0000 (02:46 -0700)]
xtensa: adjust expected output in ld TLS tests
objdump output for l32r opcode was changed in commit b3ea76397a07
("opcodes: xtensa: display loaded literal value"), but xtensa linker TLS
relaxation tests weren't adjusted accordingly.
readelf output was changed in commit 23356397449a ("Adjust readelf's
output so that section symbols without a name as shown with their
section name."), but xtensa linker TLS relaxation tests weren't adjusted
accordingly.
Fix expected output changes in xtensa ld TLS relaxation tests.
ld/
* testsuite/ld-xtensa/tlsbin.dd: Adjust expected output for l32r
opcodes.
* testsuite/ld-xtensa/tlsbin.rd: Adjust expected output to allow
for named section symbols.
* testsuite/ld-xtensa/tlspic.dd: Adjust expected output for l32r
opcodes.
* testsuite/ld-xtensa/tlspic.rd: Adjust expected output to allow
for named section symbols.
Tsukasa OI [Sat, 27 Aug 2022 00:11:01 +0000 (00:11 +0000)]
RISC-V: Print highest address (-1) on the disassembler
This patch makes possible to print the highest address (-1) and the addresses
related to gp which value is -1. This is particularly useful if the highest
address space is used for I/O registers and corresponding symbols are defined.
Besides, despite that it is very rare to have GP the highest address, it would
be nice because we enabled highest address printing on regular cases.
gas/ChangeLog:
* testsuite/gas/riscv/dis-addr-topaddr.s: New test for the top
address (-1) printing.
* testsuite/gas/riscv/dis-addr-topaddr-32.d: Likewise.
* testsuite/gas/riscv/dis-addr-topaddr-64.d: Likewise.
* testsuite/gas/riscv/dis-addr-topaddr-gp.s: New test for
GP-relative addressing when GP is the highest address (-1).
* testsuite/gas/riscv/dis-addr-topaddr-gp-32.d: Likewise.
* testsuite/gas/riscv/dis-addr-topaddr-gp-64.d: Likewise.
opcodes/ChangeLog:
* riscv-dis.c (struct riscv_private_data): Add `to_print_addr' to
enable printing the highest address.
(maybe_print_address): Utilize `to_print_addr'.
(riscv_disassemble_insn): Likewise.
If either the base register is `zero', `tp' or `gp' and XLEN is 32, an
incorrectly sign-extended address is produced when printing. This commit
fixes this by fitting an address into a 32-bit value on RV32.
Besides, H. Peter Anvin discovered that we have wrong address computation
for JALR instruction (the initial bug is back in 2018). This commit also
fixes that based on the idea of Palmer Dabbelt.
gas/
pr29342
* testsuite/gas/riscv/lla32.d: Reflect RV32 address computation fix.
* testsuite/gas/riscv/dis-addr-overflow.s: New testcase.
* testsuite/gas/riscv/dis-addr-overflow-32.d: Likewise.
* testsuite/gas/riscv/dis-addr-overflow-64.d: Likewise.
opcodes/
pr29342
* riscv-dis.c (maybe_print_address): Fit address into 32-bit on RV32.
(print_insn_args): Fix JALR address by adding EXTRACT_ITYPE_IMM.
Tsukasa OI [Sat, 27 Aug 2022 00:10:58 +0000 (00:10 +0000)]
RISC-V: Add address printer tests with ADDIW
Address sequences involving ADDIW/C.ADDIW instructions require special
handling to sign-extend lower 32-bits of the original result.
This commit tests whether this sign-extension works.
gas/ChangeLog:
* testsuite/gas/riscv/dis-addr-addiw.s: New to test the address
computation with sign extension as used in ADDIW/C.ADDIW.
* testsuite/gas/riscv/dis-addr-addiw-a.d: Test PC sign bit 0.
* testsuite/gas/riscv/dis-addr-addiw-b.d: Test PC sign bit 1.
gas/ChangeLog:
* testsuite/gas/riscv/dis-addr-addiw-a.d: New test.
* testsuite/gas/riscv/dis-addr-addiw-b.d: New test.
* testsuite/gas/riscv/dis-addr-addiw.s: New test.
Tsukasa OI [Sat, 27 Aug 2022 02:12:09 +0000 (02:12 +0000)]
sim: Update mailing list address
The commit bf1102165389 "* MAINTAINERS: Perform some obvious fixups."
back in 2009 changed the mailing list address gdb-patches@sources.redhat.com
to gdb-patches@sourceware.org.
When running the gdb/configure script on ubuntu 22.04 with
python-3.10.4, I see:
checking for python... no
checking for python3... /usr/bin/python3
[...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
from distutils import sysconfig
[...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
from distutils import sysconfig
[...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
from distutils import sysconfig
[...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
from distutils import sysconfig
[...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
from distutils import sysconfig
[...]/gdb/python/python-config.py:7: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
from distutils import sysconfig
checking for python... yes
The distutils module is deprecated as per the PEP 632[1] and will be
removed in python-3.12.
This patch migrates gdb/python/python-config.py from distutils.sysconfig
to the sysconfig module[2].
The sysconfig module has has been introduced in the standard library in
python 3.2. Given that support for python < 3.2 has been removed by edae3fd6600f: "gdb/python: remove Python 2 support", this patch does not
need to support both implementations for backward compatibility.
Tom Tromey [Fri, 12 Aug 2022 19:15:01 +0000 (13:15 -0600)]
Fix interpreter-exec crash
PR mi/10347 points out that using interpreter-exec inside of a
"define" command will crash gdb. The bug here is that
gdb_setup_readline doesn't check for the case where instream==nullptr.
Tom Tromey [Fri, 12 Aug 2022 19:50:35 +0000 (13:50 -0600)]
Fix "source" with interpreter-exec
PR mi/15811 points out that "source"ing a file that uses
interpreter-exec will put gdb in a weird state, where the CLI stops
working. The bug is that tui_interp::suspend does not unregister the
event file descriptor.
Tom Tromey [Thu, 11 Aug 2022 19:16:46 +0000 (13:16 -0600)]
Remove a ui-related memory leak
gdb_setup_readline makes new streams and assigns to the various stream
members of struct ui. However, these assignments cause the previous
values to leak. As far as I can, this code is simply unnecessary and
can be removed -- with the exception of the assignment to gdb_stdtarg,
which is not initialized anywhere else.
Tom Tromey [Thu, 11 Aug 2022 16:15:36 +0000 (10:15 -0600)]
Remove the "for moment" comments
A few spots setting some gdb output stream variables have a "for
moment" comment. These comments aren't useful and I think the moment
has passed -- these are permanent now.
Tom Tromey [Tue, 30 Aug 2022 17:30:13 +0000 (11:30 -0600)]
Let ui::input_fd be -1
This changes gdb so that, if ui::input_fd is set to -1, then it will
not be registered with the event loop. This is useful for the DAP
support code I wrote, but as it turns out to also be useful to
Insight, it seems best to check it in separately.
Andrew Burgess [Thu, 11 Aug 2022 17:38:53 +0000 (18:38 +0100)]
gdb/riscv: better support for fflags and frm registers
First, some background on the RISC-V registers fflags, frm, and fcsr.
These three registers all relate to the floating-point status and
control mechanism on RISC-V. The fcsr is the floatint-point control
status register, and consists of two parts, the flags (bits 0 to 4)
and the rounding-mode (bits 5 to 7).
The fcsr register is just one of many control/status registers (or
CSRs) available on RISC-V. The fflags and frm registers are also
CSRs. These CSRs are aliases for the relevant parts of the fcsr
register. So fflags is an alias for bits 0 to 4 of fcsr, and frm is
an alias for bits 5 to 7 of fcsr.
This means that a user can change the floating-point rounding mode
either, by writing a complete new value into fcsr, or by writing just
the rounding mode into frm.
How this impacts on GDB is like this: a target description could,
legitimately include all three registers, fcsr, fflags, and frm. The
QEMU target currently does this, and this makes sense. The target is
emulating the complete system, and has all three CSRs available, so
why not tell GDB about this.
In contrast, the RISC-V native Linux target only has access to the
fcsr. This is because the ptrace data structure that the kernel uses
for reading and writing floating point state only contains a copy of
the fcsr, after all, this one field really contains both the fflags
and frm fields, so why carry around duplicate data.
So, we might expect that the target description for the RISC-V native
Linux GDB would only contain the fcsr register. Unfortunately, this
is not the case. The RISC-V native Linux target uses GDB's builtin
target descriptions by calling riscv_lookup_target_description, this
will then add an fpu feature from gdb/features/riscv, either
32bit-fpu.xml or 64bit-fpu.xml. The problem, is that these features
include an entry for fcsr, fflags, and frm. This means that GDB
expects the target to handle reading and writing these registers. And
the RISC-V native Linux target currently doesn't.
In riscv_linux_nat_target::store_registers and
riscv_linux_nat_target::fetch_registers only the fcsr register is
handled, this means that, for RISC-V native Linux, the fflags and frm
registers always show up as <unavailable> - they are present in the
target description, but the target doesn't know how to access the
registers.
A final complication relating to these floating pointer CSRs is which
target description feature the registers appear in.
These registers are CSRs, so it would seem sensible that these
registers should appear in the CSR target description feature.
However, when I first added RISC-V target description support, I was
using a RISC-V simulator that didn't support any CSRs other than the
floating point related ones. This simulator bundled all the float
related CSRs into the fpu target feature. This didn't feel completely
unreasonable to me, and so I had GDB check for these registers in
either target feature.
In this commit I make some changes relating to how GDB handles the
three floating point CSR:
1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml. This
means that the default RISC-V target description (which RISC-V native
FreeBSD), and the target descriptions created for RISC-V native Linux,
will not include these registers. There's nothing stopping some other
target (e.g. QEMU) from continuing to include all three of these CSRs,
the code in riscv-tdep.c continues to check for all three of these
registers, and will handle them correctly if they are present.
2. If a target supplied fcsr, but does not supply fflags and/or frm,
then RISC-V GDB will now create two pseudo registers in order to
emulate the two missing CSRs. These new pseudo-registers do the
obvious thing of just reading and writing the fcsr register.
3. With the new pseudo-registers we can no longer make use of the GDB
register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM.
These will be the numbers used if the target supplies the registers in
its target description, but, if GDB falls back to using
pseudo-registers, then new, unique numbers will be used. To handle
this I've added riscv_gdbarch_tdep::fflags_regnum and
riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to
compare against these fields.
When adding the pseudo-register support, it is important that the
pseudo-register numbers are calculated after the call to
tdesc_use_registers. This is because we don't know the total number
of physical registers until after this call, and the psuedo-register
numbers must follow on from the real (target supplied) registers.
I've updated some tests to include more testing of the fflags and frm
registers, as well as adding a new test.
Andrew Burgess [Thu, 11 Aug 2022 11:43:08 +0000 (12:43 +0100)]
gdb: Add tdesc_found_register function to tdesc API
This commit adds a new function to the target description API within
GDB. This new function is not used in this commit, but will be used
in the next commit, I'm splitting it out into a separate patch for
easier review.
What I want to do in the next commit is check to see if a target
description supplied a particular register, however, the register in
question could appear in one of two possible features.
The new function allows me to ask the tdesc_arch_data whether a
register was found and assigned a particular GDB register number once
all of the features have been checked. I think this is a much simpler
solution than adding code such that, while checking each feature, I
spot if the register I'm processing is the one I care about.
No tests here as the new code is not used, but this code will be
exercised in the next commit.
Andrew Burgess [Sun, 14 Aug 2022 14:14:22 +0000 (15:14 +0100)]
gdb/riscv: improve (and fix) display of frm field in 'info registers'
On RISC-V the FCSR (float control/status register) is split into two
parts, FFLAGS (the flags) and FRM (the rounding mode). Both of these
two fields are part of the FCSR register, but can also be accessed as
separate registers in their own right. And so, we have three separate
registers, $fflags, $frm, and $fcsr, with the last of these being the
combination of the first two.
Here's how the bits of FCSR are split between FRM and FFLAGS:
Here's how GDB currently displays these registers:
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]
fcsr 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
Notice the 'RD' field which is present in both $fflags and $fcsr.
This field contains the value of the FRM field, which makes sense when
displaying the $fcsr, but makes no sense when displaying $fflags, as
the $fflags doesn't include the FRM field.
Additionally, the $fcsr already includes an FRM field, so the
information in 'RD' is duplicated. Consider this:
(gdb) set $frm = 0x3
(gdb) info registers $fflags $frm $fcsr │
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x3 FRM:3 [RUP (Round up towards +INF)]
fcsr 0x60 RD:3 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]
See how the 'RD' field in $fflags still displays 0, while the 'RD' and
'FRM' fields in $fcsr show the same information.
The first change I propose in this commit is to remove the 'RD'
field. After this change the output now looks like this:
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]
fcsr 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
Next, I spotted that the text that goes along with the 'FRM' field was
not wrapped in the i18n markers for internationalisation, so I added
those.
Next, I spotted that:
(gdb) set $frm=0x7
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x7 FRM:3 [RUP (Round up towards +INF)]
fcsr 0xe0 RD:7 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]
Notice that despite being a 3-bit field, FRM masks to 2-bits.
Checking the manual I can see that the FRM field is 3-bits, and is
defined for all 8 values. That GDB masks to 2-bits is just a bug I
think, so I've fixed this.
Finally, the 'FRM' text for value 0x7 is wrong. Currently we use the
text 'dynamic rounding mode' for value 0x7. However, this is not
really correct.
A RISC-V instruction can either encode the rounding mode within the
instruction, or a RISC-V instruction can choose to use a global,
dynamic rounding mode.
So, for the rounding-mode field of an _instruction_ the value 0x7
indicates "dynamic round mode", the instruction should defer to the
rounding mode held in the FRM field of the $fcsr.
But it makes no sense for the FRM of $fcsr to itself be set to
0x7 (dynamic rounding mode), and indeed, section 11.2, "Floating-Point
Control and Status Register" of the RISC-V manual, says that a value
of 0x7 in the $fcsr FRM field is invalid, and if an instruction has
_its_ round-mode set to dynamic, and the FRM field is also set to 0x7,
then an illegal instruction exception is raised.
And so, I propose changing the text for value 0x7 of the FRM field to
be "INVALID[7] (Dynamic rounding mode)". We already use the text
"INVALID[5]" and "INVALID[6]" for the two other invalid fields,
however, I think adding the extra "Dynamic round mode" hint might be
helpful.
I've added a new test that uses 'info registers' to check what GDB
prints for the three registers related to this patch. There is one
slight oddity with this test - for the fflags and frm registers, the
test accepts both the "normal" output (as described above), but also
allows these registers to be reported as '<unavailable>'.
The reason why I accept <unavailable> is that currently, the RISC-V,
native Linux target advertises these registers in its target
description, but then doesn't support reading or writing of these
registers, this results in the registers being reported as
unavailable.
A later patch in this series will address this issue, and will remove
this check for <unavailable>.
I will reiterate the problem a bit and give some more information here.
This patch closes the above mentioned bug.
The DWARF 5 standard 2.23 'Template Parameters' reads:
A template type parameter is represented by a debugging information
entry with the tag DW_TAG_template_type_parameter. A template value
parameter is represented by a debugging information entry with the tag
DW_TAG_template_value_parameter. The actual template parameter entries
appear in the same order as the corresponding template formal
parameter declarations in the source progam.
A type or value parameter entry may have a DW_AT_name attribute, whose
value is a null-terminated string containing the name of the
corresponding formal parameter.
So the DW_AT_name attribute for DW_TAG_template_type_parameter and
DW_TAG_template_value_parameter is optional.
Within GDB, creating a new symbol from some read DIE usually requires the
presence of a DW_AT_name for the DIE (an exception here is the case of
unnamed namespaces or the existence of a linkage name).
This patch makes the presence of the DW_AT_name for template value/type
tags optional, similar to the unnamed namespaces.
For unnamed namespaces dwarf2_name simply returns the constant string
CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'. For template tags a
case was added to the switch statement calling the
unnamed_template_tag_name helper. Within the scope of parent which
the template parameter is a child of, the helper counts the position
of the template tag within the unnamed template tags and returns
'<unnamedNUMBER>' where NUMBER is its position. This way we end up with
unique names within the respective scope of the function/class/struct
(these are the only currenltly supported template kinds within GDB and
usually the compilers) where we discovered the template tags in.
While I do not know of a way to bring GCC to emit template tags without
names there is one for clang/icpx. Consider the following example
template<typename A, typename B, typename C>
class Foo {};
template<typename, typename B, typename>
class Foo;
int main () {
Foo<double, int, float> f;
return 0;
}
The forward declaration for 'Foo' with the missing template type names
'A' and 'C' makes clang emit a bunch of template tags without names:
Befor this patch, GDB would not create any symbols for the read template
tag DIEs and thus lose knowledge about them. Breaking at the return
statement and printing f's type would read
(gdb) ptype f
type = class Foo<double, int, float> [with B = int] {
<no data fields>
}
After this patch GDB does generate symbols from the DWARF (with their
artificial names:
(gdb) ptype f
type = class Foo<double, int, float> [with <unnamed0> = double, B = int,
<unnamed1> = float] {
<no data fields>
}
The same principle theoretically applies to template functions. Also
here, GDB would not record unnamed template TAGs but I know of no visual
way to trigger and test this changed behavior. Template functions do
not emit a '[with...]' list and their name generation also does not
suffer from template tags without names. GDB does not check whether or
not a template tag has a name in 'dwarf2_compute_name' and thus, the
names of the template functions are created independently of whether or
not the template TAGs have a DW_TAT_name attribute. A testcase has
been added in the gdb.dwarf2 for template classes and structs.
gdb, testsuite: adapt function_range expected name
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:
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.
Aaron Merey [Wed, 31 Aug 2022 00:18:11 +0000 (20:18 -0400)]
gdb/elfread.c: Use bfd filename instead of objfile->original_name
The call to debuginfod_debuginfo_query in elf_symfile_read is given
objfile->original_name as the filename to print when downloading the
objfile's debuginfo.
In some cases original_name is prefixed with gdb's working directory
even though the objfile is not located in the working directory. This
causes debuginfod to display the wrong path of the objfile during a download.
Fix this by using the objfile's bfd filename instead.
Martin Storsjö [Tue, 23 Aug 2022 12:48:39 +0000 (15:48 +0300)]
ld: pe: Fix linking against Microsoft import libraries with multiple DLLs
Initially, since c6c37250e98f113755e0d787f7070e2ac80ce77e (in 1999),
in order to fix linking against Microsoft import libraries, ld did
internally rename members of such libraries. At that point, the
criteria for being considered a Microsoft import library was that
every archive member had the same name (no regard for exactly what
that name was).
This was later amended in 44dbf3639f127af46d569ad96b6242dfbc4c0a89
(in 2003) to allow for Microsoft import libraries with intermixed
static object files. At this point, the criteria were extended, so
that all members following the first member named *.dll either had
the exact same member name, or be named *.obj. (Curiously, this would
allow members with any name if it precedes the first one named *.dll.)
In practice, Microsoft style import libraries can contain
members for linking against more than one DLL (built by merging
multiple regular import libraries into one).
Instead of trying to do validation of the whole archive before
considering it a Microsoft style import library, relax the criteria
for doing the member renaming: If an archive member is named *.dll
and it contains .idata sections, assume that that member is a
Microsoft import file, and apply the renaming scheme.
This works for imports for any number of DLLs in the same library,
intermixed with other static object files (regardless of their
names), and vastly simplifies the code.
LLVM generates Microsoft style import libraries, and Rust builds
seem to bundle up multiple import libraries together with some
Rust specific static objects. This fixes linking directly against
them with ld.bfd.
Simon Marchi [Fri, 26 Aug 2022 15:57:54 +0000 (11:57 -0400)]
gdbsupport: add wrapper around result_of and invoke_result
When building with Clang 14 (using gcc 12 libstdc++ headers), I get:
CXX dwarf2/read.o
In file included from /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:94:
/home/simark/src/binutils-gdb/gdb/../gdbsupport/parallel-for.h:142:21: error: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' is deprecated: use 'std::invoke_result' instead [-Werror,-Wdeprecated-declarations]
= typename std::result_of<RangeFunction (RandomIt, RandomIt)>::type;
^
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7122:14: note: in instantiation of function template specialization 'gdb::parallel_for_each<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, (lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5)>' requested here
= gdb::parallel_for_each (1, per_bfd->all_comp_units.begin (),
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/type_traits:2597:9: note: 'result_of<(lambda at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7124:5) (__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter> *, std::__cxx1998::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>>, std::vector<std::unique_ptr<dwarf2_per_cu_data, dwarf2_per_cu_data_deleter>>, std::random_access_iterator_tag>)>' has been explicitly marked deprecated here
{ } _GLIBCXX17_DEPRECATED_SUGGEST("std::invoke_result");
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:120:45: note: expanded from macro '_GLIBCXX17_DEPRECATED_SUGGEST'
# define _GLIBCXX17_DEPRECATED_SUGGEST(ALT) _GLIBCXX_DEPRECATED_SUGGEST(ALT)
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../include/c++/12.1.1/x86_64-pc-linux-gnu/bits/c++config.h:96:19: note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST'
__attribute__ ((__deprecated__ ("use '" ALT "' instead")))
^
It complains about the use of std::result_of, which is deprecated in
C++17 and removed in C++20:
https://en.cppreference.com/w/cpp/types/result_of
Given we'll have to transition to std::invoke_result eventually, make a
GDB wrapper to mimimc std::invoke_result, which uses std::invoke_result
for C++ >= 17 and std::result_of otherwise. This way, it will be easy
to remove the wrapper in the future, just replace gdb:: with std::.
Tested by building with gcc 12 in -std=c++11 and -std=c++17 mode, and
clang in -std=c++17 mode (I did not test fully with clang in -std=c++11
mode because there are other unrelated issues).
Tom Tromey [Mon, 15 Aug 2022 18:45:43 +0000 (12:45 -0600)]
Fix flush for sys.stderr
GDB overwrites Python's sys.stdout and sys.stderr, but does not
properly implement the 'flush' method -- it only ever will flush
stdout. This patch fixes the bug. I couldn't find a straightforward
way to write a test for this.
Nick Clifton [Tue, 30 Aug 2022 15:01:20 +0000 (16:01 +0100)]
BFD library: Use entry 0 in directory and filename tables of DWARF-5 debug info.
PR 29529
* dwarf2.c (struct line_info_table): Add new field:
use_dir_and_file_0.
(concat_filename): Use new field to help select the correct table
slot.
(read_formatted_entries): Do not skip entry 0.
(decode_line_info): Set new field depending upon the version of
DWARF being parsed. Initialise filename based upon the setting of
the new field.
projects / thirdparty / binutils-gdb.git / log
