windres code has the habit of exiting on any error. That's not so
bad, but it does make oss-fuzz ineffective when testing windres. Fix
many places that print errors and exit to instead print the error and
pass status up the call chain. In the process of doing this, I
noticed write_res_file was calling bfd_close without checking return
status. Fixing that resulted in lots of testsuite failures. The
problem was a lack of bfd_set_format in windres_open_as_binary, which
leaves the output file as bfd_unknown format. As it happens this
doesn't make any difference in writing the output binary file, except
for the bfd_close return status.
oss-fuzz testcase manages to hit a buffer overflow. Sanity check
by passing the buffer length to bin_to_res_toolbar and ensuring reads
don't go off the end of the buffer.
There's currently no test for unwinding the SVE registers from a signal
frame, so add one.
Tested on aarch64-linux-gnu native.
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com>
While commit ef6379e16d ("Set the default DLL chracteristics to 0 for
Cygwin based targets") tried to undo the too broad earlier 514b4e191d
("Change the default characteristics of DLLs built by the linker to more
secure settings"), it didn't go quite far enough. Apparently the
assumption was that if it's not MinGW, it must be Cygwin. Whether it
really is okay to default three of the flags to non-zero on MinGW also
remains unclear - sadly neither of the commits came with any description
whatsoever. (Documentation also wasn't updated to indicate the restored
default.)
Setting effectively any of the DLL characteristics flags depends on
properties of the binary being linked. While defaulting to "more secure"
is a fair goal, it's only the programmer who can know whether their code
is actually compatible with the respective settings. On the assumption
that the change of defaults was indeed deliberate (and justifiable) for
MinGW, limit them to just that. In particular, don't default any of the
flags to set also for non-MinGW, non-Cygwin targets, like e.g. UEFI. At
least the mere applicability of the high-entropy-VA bit is pretty
questionable there in the first place - UEFI applications, after all,
run in "physical mode", i.e. either unpaged or (where paging is a
requirement, like for x86-64) direct-mapped.
The situation is particularly problematic with NX-compat: Many UEFI
implementations respect the "physical mode" property, where permissions
can't be enforced anyway. Some, like reportedly OVMF, even have a build
option to behave either way. Hence successfully testing a UEFI binary on
any number of systems does not guarantee it won't crash elsewhere if the
flag is wrongly set.
Get rid of excess semicolons as well.
There's no reason not to do as the comment says, just like all other
architectures do when they need custom field: Call the allocation method
of the "superclass". Which is the ELF one, of which in turn the BFD one
is the "superclass", dealt with accordingly by
_bfd_elf_link_hash_newfunc().
The need for this has disappeared with c65c21e1ff ("various i386-aout
and i386-coff target removal"), with a few other users having got
removed just a few days earlier; avoid the unnecessary indirection.
While COFF, unlike ELF, doesn't have a generic way to express symbol
size, there is a means to do so for functions. When inputs are ELF,
propagate function sizes, including the fact that a symbol denotes a
function, to the output's symbol table.
Note that this requires hackery (cross-object-format processing) in two
places - when linking, global symbols are entered into a global hash
table, and hence relevant information needs to be updated there in that
case, while otherwise the original symbol structures can be consulted.
For the setting of ->u.syment.n_type the later writing of the field to
literal 0 needs to be dropped from coff_write_alien_symbol(). It was
redundant anyway with an earlier write of the field using C_NUL.
... to be all in one group. This helps code generation for code like
|| is_cpu (&i.tm, CpuPadLock)
|| is_cpu (&i.tm, CpuPadLockRNG2)
|| is_cpu (&i.tm, CpuPadLockPHE2)
|| is_cpu (&i.tm, CpuPadLockXMODX)
that we have (effectively) twice.
With the command before the change, gdb crashes with message:
(gdb) p 1 == { }
Fatal signal: Segmentation fault
After the fix in this commit, gdb shows following message:
(gdb) p 1 == { }
size of the array element must not be zero
Add new test cases to file gdb.base/printcmds.exp to test this change
Approved-By: Tom Tromey <tom@tromey.com>
The cmd_list_element::doc variable must be non-nullptr, otherwise, in
`help_cmd` (cli/cli-decode.c), we will trigger an assert when we run
one of these lines:
gdb_puts (c->doc, stream);
or,
gdb_puts (alias->doc, stream);
as gdb_puts requires that the first argument (the doc string) be
non-nullptr.
Better, I think, to assert when the cmd_list_element is created,
rather than catching an assert later when 'help CMD' is used.
I only ran into this case when messing with the Python API command
creation code, I accidentally created a command with a nullptr doc
string, and only found out when I ran 'help CMD' and got an
assertion.
While I'm adding this assertion, I figure I should also assert that
the command name is not nullptr too. Looking through cli-decode.c,
there seems to be plenty of places where we assume a non-nullptr name.
Built and tested on x86-64 GNU/Linux with an all-targets build; I
don't see any regressions, so (I hope) there are no commands that
currently violate this assertion.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
These LA32R instructions are in fact special cases of the LA32S/LA64
rdtime{l,h}.w (with only one output operand instead of two, the other
one being forced to $zero), but are named differently in the LA32R
ISA manual nevertheless.
As the LA32R names are more memorable to a degree (especially for those
having difficulties remembering which operand corresponds to the node
ID), support them by making them aliases of the corresponding LA32S/LA64
instruction respectively, and make them render as such in disassembly.
Signed-off-by: WANG Xuerui <git@xen0n.name>
But PR gdb/20126 highlights a case where GDB emits a large number of
warnings like:
warning: Can't open file /anon_hugepage (deleted) during file-backed mapping note processing
warning: Can't open file /dev/shm/PostgreSQL.1150234652 during file-backed mapping note processing
warning: Can't open file /dev/shm/PostgreSQL.535700290 during file-backed mapping note processing
warning: Can't open file /SYSV604b7d00 (deleted) during file-backed mapping note processing
... etc ...
when opening a core file. This commit aims to avoid at least some of
these warnings.
What we know is that, for at least some of these cases, (e.g. the
'(deleted)' mappings), the content of the mapping will have been
written into the core file itself. As such, the fact that the file
isn't available ('/SYSV604b7d00' at least is a shared memory mapping),
isn't really relevant, GDB can still provide access to the mapping, by
reading the content from the core file itself.
What I propose is that, when processing the file backed mappings, if
all of the mappings for a file are covered by segments within the core
file itself, then there is no need to warn the user that the file
can't be opened again. The debug experience should be unchanged, as
GDB would have read from the in-core mapping anyway.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30126
Editing maint.h with clangd shows some errors about obj_section and
objfile being unknown. Add some forward declarations for them.
Change-Id: Ic4dd12a371198fdf740892254a8f2c1fae2846b9
In PR gdb/31846 the user reported an issue where GDB is unable to find
the build-id within an ELF, despite the build-id being
present (confirmed using readelf).
The user was able to try several different builds of GDB, and in one
build they observed the warning:
warning: BFD: FILENAME: unable to decompress section .debug_info
But in may other builds of GDB this warning was missing.
There are, I think, a couple of issues that the user is running into,
but this patch is about why the above warning is often missing from
GDB's output.
I wasn't able to reproduce a corrupted .debug_info section such that
the above warning would be triggered, but it is pretty easy to patch
the _bfd_elf_make_section_from_shdr function (in bfd/elf.c) such that
the call to bfd_init_section_decompress_status is reported as a
failure, thus triggering the warning. There is a patch that achieves
this in the bug report.
I did this, and can confirm that on my build of GDB, I don't see the
above warning, even though I can confirm that the _bfd_error_handler
call (in _bfd_elf_make_section_from_shdr) is being reached.
The problem is back in format.c, in bfd_check_format_matches. This
function intercepts all the warnings and places them into a
per_xvec_messages structure. These warnings are then printed with a
call to print_and_clear_messages.
If bfd_check_format_matches finds a single matching format, then
print_and_clear_messages, will print all warnings associated with that
single format.
But if no format matches, print_and_clear_messages will print all the
warnings, so long as all targets have emitted the same set of
warnings, and unfortunately, that is not the case for me.
The warnings are collected by iterating over bfd_target_vector and
trying each target. My target happens to be x86_64_elf64_vec, and, as
expected this target appears in bfd_target_vector.
However, bfd_target_vector also includes DEFAULT_VECTOR near the top.
And in my build, DEFAULT_VECTOR is x86_64_elf64_vec. Thus, for me,
the x86_64_elf64_vec entry appears twice in bfd_target_vector, this
means that x86_64_elf64_vec ends up being tried twice, and, as each
try generates one warning, the x86_64_elf64_vec entry in the
per_xvec_messages structure, has two warnings, while the other
per_xvec_messages entries only have one copy of the warning.
Because of this difference, print_and_clear_messages decides not to
print any of the warnings, which is not very helpful.
I considered a few different approaches to fix this issue:
We could de-duplicate warnings in the per_xvec_messages structure as
new entries are added. So for any particular xvec, each time a new
warning arrives, if the new warning is identical to an existing
warning, then don't record it. This might be an interesting change in
the future, but for now I rejected this solution as it felt like a
bodge, the duplicate warnings aren't really from a single attempt at
an xvec, but are from two distinct attempts at the same xvec. And so:
I wondered if we could remove the duplicate entries from
bfd_target_vector. Or if we could avoid processing the same xvec
twice maybe? For the single DEFAULT_VECTOR this wouldn't be too hard
to do, but bfd_target_vector also includes SELECT_VECS, which I think
could contain more duplicates. Changing bfd_check_format_matches to
avoid attempting any duplicate vectors would now require more
complexity than a single flag, and I felt there was an easier
solution, which was:
I propose that within bfd_check_format_matches, within the loop that
tries each entry from bfd_target_vector, as we switch to each vector
in turn, we should delete any existing warnings within the
per_xvec_messages structure for the target vector we are about to try.
This means that, if we repeat a target, only the last set of warnings
will survive.
With this change in place, print_and_clear_messages now sees the same
set of warnings for each target, and so prints out the warning
message.
Additionally, while I was investigating this issue I managed to call
print_and_clear_messages twice. This caused a crash because the first
call to print_and_clear_messages frees all the associated memory, but
leaves the per_xvec_messages::next field pointing to the now
deallocated object. I'd like to propose that we set the next field to
NULL in print_and_clear_messages. This clearly isn't needed so long
as print_and_clear_messages is only called once, but (personally) I
like to set pointers back to NULL if the object they are pointing to
is free and the parent object is going to live for some additional
time. I can drop this extra change if people don't like it.
This change doesn't really "fix" PR gdb/31846, but it does mean that
the warning about being unable to decompress .debug_info should now be
printed consistently, which is a good thing.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31846
Reviewed-By: Alan Modra <amodra@gmail.com>
The recently included gdb.base/dlmopen-ns-ids.exp test can sometimes
fail the call to get_integer_valueof when trying to check the namespace
ID of the fourth dlopened SO, for apparently no reason.
What's happening is that the call to get_first_so_ns doesn't necessarily
consume the GDB prompt, and so get_integer_valueof will see the prompt
immediately and not find the value the test is looking for.
To fix this, the test was changed so that we consume all of the output
of the command "info sharedlibrary", but only set the namespace ID for
the first occurrence of the SO we're looking for. The command now also
gets the solib name as a parameter, to reduce the amount of output.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom de Vries <tdevries@suse.de>
commit 2707d55e53
Author: Michael Matz <matz@suse.de>
Date: Mon Mar 31 15:57:08 2025 +0200
skipped the LTO archive member even when the earlier item is also an
archive. Instead, skip the LTO archive member only if the earlier item
is a shared library.
bfd/
PR ld/32846
PR ld/32854
* elflink.c (elf_link_add_archive_symbols): Skip the LTO archive
member only if the earlier item is a shared library.
ld/
PR ld/32846
PR ld/32854
* testsuite/ld-plugin/lto.exp: Run ld/32846 test.
* testsuite/ld-plugin/pr32846a.c: New file.
* testsuite/ld-plugin/pr32846b.c: Likewise.
* testsuite/ld-plugin/pr32846c.c: Likewise.
* testsuite/ld-plugin/pr32846d.c: Likewise.
* testsuite/ld-plugin/pr32846e.c: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Ignore the following spellcheck warning:
...
$ codespell --config gdb/contrib/setup.cfg gdb/unittests
gdb/unittests/rsp-low-selftests.c:54: fo ==> of, for, to, do, go
...
and add gdb/unittests to the pre-commit codespell configuration.
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.dwarf2/fission-with-type-unit.exp with a remote
host configuration, say host board local-remote-host and target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) maint expand-symtabs^M
During symbol reading: Could not find DWO CU \
fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0x2d7 \
[in module /home/remote-host/fission-with-type-unit]^M
warning: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced \
by CU at offset 0x2d7 [in module /home/remote-host/fission-with-type-unit]^M
(gdb) FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs
...
Fix this by adding the missing download to remote host of the .dwo file.
Tested by running make-check-all.sh on x86_64-linux.
When writing the test, I copied these copyright entries from another
file but forgot to adjust the dates, do that now.
Change-Id: Ie458ad4ec81062b5ef24f78334f3d0920c99b318
Commit d01e823438 ("Update copyright dates to include 2025") incorrectly
changed the dates in Makefile.in. Re-run `autoreconf` in the gdbsupport
directory to fix that up.
Change-Id: Ifcdb6f2257e7a456439dfc3e7848db934a4b16b4
Commit d01e823438 ("Update copyright dates to include 2025") incorrectly
changed the dates in Makefile.in. Re-run `autoreconf` in the sim
directory to fix that up.
Change-Id: Ia02a54e5330d77b490cc7745eee3d281c7888eec
Commit d01e823438 ("Update copyright dates to include 2025") changed the
dates in the gnulib imported source files, it probably shouldn't have.
Re-run update-gnulib.sh to restore those files.
gnulib/Makefile.in was also incorrectly modified, running the script
fixes that too.
Change-Id: I5d081f3438b9480130a92f59fd9fede33c121f9c
With a gdb 15.2 based package and test-case
gdb.threads/infcall-from-bp-cond-simple.exp, I ran into:
...
Thread 2 "infcall-from-bp" hit Breakpoint 3, function_with_breakpoint () at \
infcall-from-bp-cond-simple.c:51
51 return 1; /* Nested breakpoint. */
Error in testing condition for breakpoint 2:
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(function_with_breakpoint) will be abandoned.
When the function is done executing, GDB will silently stop.
[Thread 0x7ffff73fe6c0 (LWP 951822) exited]
(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
run_bp_cond_hits_breakpoint: continue
...
The test fails because it doesn't expect the "[Thread ... exited]" message.
I have tried to reproduce this test failure, both using 15.2 and current
trunk, but haven't managed.
Regardless, I think the message is harmless, so allow it to occur, both in
run_bp_cond_segfaults and run_bp_cond_hits_breakpoint.
Tested on x86_64-linux.
PR testsuite/32785
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32785
On riscv64-linux, with test-case gdb.base/vla-optimized-out.exp I ran into:
...
(gdb) p sizeof (a)^M
$2 = <optimized out>^M
(gdb) FAIL: $exp: o1: printed size of optimized out vla
...
The variable a has type 0xbf:
...
<1><bf>: Abbrev Number: 12 (DW_TAG_array_type)
<c0> DW_AT_type : <0xe3>
<c4> DW_AT_sibling : <0xdc>
<2><c8>: Abbrev Number: 13 (DW_TAG_subrange_type)
<c9> DW_AT_type : <0xdc>
<cd> DW_AT_upper_bound : 13 byte block:
a3 1 5a 23 1 8 20 24 8 20 26 31 1c
(DW_OP_entry_value: (DW_OP_reg10 (a0));
DW_OP_plus_uconst: 1; DW_OP_const1u: 32;
DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra;
DW_OP_lit1; DW_OP_minus)
...
which has an upper bound using a DW_OP_entry_value, and since the
corresponding call site contains no information to resolve the value of a0 at
function entry:
...
<2><6b>: Abbrev Number: 6 (DW_TAG_call_site)
<6c> DW_AT_call_return_pc: 0x638
<74> DW_AT_call_origin : <0x85>
...
evaluting the dwarf expression fails, and we get <optimized out>.
My first thought was to try breaking at *f1 instead of f1 to see if that would
help, but actually the breakpoint resolved to the same address.
In other words, the inferior is stopped at function entry.
Fix this by resolving DW_OP_entry_value when stopped at function entry by
simply evaluating the expression.
This handles these two cases (x86_64, using reg rdi):
- DW_OP_entry_value: (DW_OP_regx: 5 (rdi))
- DW_OP_entry_value: (DW_OP_bregx: 5 (rdi) 0; DW_OP_deref_size: 4)
Tested on x86_64-linux.
Tested gdb.base/vla-optimized-out.exp on riscv64-linux.
Tested an earlier version of gdb.dwarf2/dw2-entry-value-2.exp on
riscv64-linux, but atm I'm running into trouble on that machine (cfarm92) so
I haven't tested the current version there.
So far IBM z17 was identified as arch15. Add the real name, as it has
been announced. [1]
[1]: IBM z17 announcement letter, AD25-0015,
https://www.ibm.com/docs/en/announcements/z17-makes-more-possible
gas/
* config/tc-s390.c (s390_parse_cpu): Add z17 as alternate CPU
name for arch15.
* doc/c-s390.texi: Likewise.
* doc/as.texi: Likewise.
opcodes/
* s390-mkopc.c (main): Add z17 as alternate CPU name for arch15.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
The Linaro CI reported a regression [1] in test-case
gdb.base/step-over-syscall.exp due to commit 674d485673 ("[gdb/testsuite] Fix
gdb.base/step-over-syscall.exp with glibc 2.41").
Investigation shows that it's a progression in the sense that the test-case
fails at a later point than before.
The cause for the test-case failure is that an atomic sequence
ldaex/adds/strex is not skipped over when instruction stepping, leading to a
hang (in the sense of not being able to instruction-step out of the loop
containing the atomic sequence).
The arm target does have support for recognizing atomic sequences, but it
fails because it doesn't recognize the ldaex insn.
Fix this by:
- adding a new function ldaex_p which recognizes ldaex instructions, based
on information found in opcodes/arm-dis.c, and
- using ldaex_p in thumb_deal_with_atomic_sequence_raw.
I was not able to reproduce the failure in its original setting, but I
was able to do so using a test.c:
...
static void exit (int status) {
while (1)
;
}
void _start (void) {
int a = 0;
__atomic_fetch_add (&a, 1, __ATOMIC_ACQUIRE);
exit (0);
}
...
compiled like this:
...
$ gcc test.c -march=armv8-a -mfloat-abi=soft -nostdlib -static
...
giving this atomic sequence of 32-bit Thumb-2 instructions:
...
100ce: e8d3 1fef ldaex r1, [r3]
100d2: f101 0101 add.w r1, r1, #1
100d6: e843 1200 strex r2, r1, [r3]
...
Without the fix, after 100 stepi's we're still in _start (and likewise with
10.000 stepi's):
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
...
0x000100dc in _start ()
1: x/i $pc
=> 0x100dc <_start+26>: bne.n 0x100ce <_start+12>
...
but with the fix we've managed to progress to exit:
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
...
0x000100c0 in exit ()
1: x/i $pc
=> 0x100c0 <exit+8>: b.n 0x100c0 <exit+8>
...
Having addressed the "-mthumb" case, do we need a similar fix for "-marm"?
Adding "-marm" in the compilation line mentioned above gives the following
atomic sequence:
...
100e4: e1931e9f ldaex r1, [r3]
100e8: e2811001 add r1, r1, #1
100ec: e1832f91 strex r2, r1, [r3]
...
and gdb already recognizes it as such because of this statement:
...
if ((insn & 0xff9000f0) != 0xe1900090)
return {};
...
The trouble with this statement is that it requires knowledge of arm
instruction encoding to understand which cases it does and doesn't cover.
Note that the corresponding comment only mentions ldrex:
...
/* Assume all atomic sequences start with a ldrex{,b,h,d} instruction. ... */
...
but evidently at least some forms of ldaex are also detected.
So, also use ldaex_p in arm_deal_with_atomic_sequence_raw. This may or may
not be redundant, but at least ldaex_p is explicit and precise about what it
supports.
Likewise for stlex (generated when using __ATOMIC_RELEASE instead of
__ATOMIC_ACQUIRE in the example above).
Tested in arm-linux chroot on aarch64-linux.
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Co-Authored-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/32796
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32796
[1] https://linaro.atlassian.net/browse/GNU-1541
print_doc_line uses a static buffer and manually manages memory. I
think neither of these is really needed, so this patch rewrites the
function to use std::string. The new implementation tries to avoid
copying when possible.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Commit 71a4875266 ("gdb/dwarf: remove create_dwo_cu_reader")
introduced a regression when handling files compiled with "-gsplit-dwarf
-fdebug-types-section" (at least with clang):
$ cat test.cpp
#include <vector>
int main()
{
std::vector<int> v;
return v.size ();
}
$ clang++ -O0 test.cpp -g -gdwarf-5 -gsplit-dwarf -fdebug-types-section -o test
$ ./gdb -nx -q --data-directory=data-directory ./test -ex "maint expand-symtabs"
Reading symbols from ./test...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6159: internal-error: setup_type_unit_groups: Assertion `per_cu->is_debug_types' failed.
In the main file, we have a skeleton CU with a certain DWO ID:
0x00000000: Compile Unit: ..., unit_type = DW_UT_skeleton, ..., DWO_id = 0x146eaa4daf5deef2, ...
In the .dwo file, the first unit is a type unit with a certain type
signature:
0x00000000: Type Unit: ..., unit_type = DW_UT_split_type, ..., type_signature = 0xb499dcf29e2928c4, ...
and the split compile unit matching the DWO ID from the skeleton from
the main file comes later:
0x0000117f: Compile Unit: ..., unit_type = DW_UT_split_compile, ..., DWO_id = 0x146eaa4daf5deef2, ...
The problem introduced by the aforementioned commit is that when
creating a dwo_unit structure representing the type unit, we use the
signature (DWO id) from the skeleton, instead of the signature from the
type unit's header. As a result, all dwo_units get created with the
same signature (the DWO id) and only the first unit gets inserted in the
hash table. When looking up the comp unit by DWO ID later on, we
wrongly find the type unit, and try to expand a type unit as a comp
unit, hitting the assert.
Before that commit, we passed `reader.cu ()` to lookup_dwo_id, which
yields a dwarf2_cu built from parsing the type unit's header. This
dwarf2_cu contains the comp_unit_header with the correct signature. Fix
the code to use `reader.cu ()` again.
Another thing that enables this bug is the fact that since DWARF 5, type
and compile units are all in .debug_info, and therefore read by
create_cus_hash_table, so they both end up in dwo_file::cus. Type units
should end up in dwo_file::tus, otherwise they won't be found by
lookup_dwo_cutu. This bug hasn't given me trouble so far, so I'm not
fixing it right now, but it's on my todo list.
The problem can be seen with some tests, when using the
dwarf5-fission-debug-types board:
$ make check TESTS="gdb.cp/expand-sals.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.cp/expand-sals.exp ...
FAIL: gdb.cp/expand-sals.exp: gdb_breakpoint: set breakpoint at main (GDB internal error)
But this patch also adds a DWARF assembler-based test that triggers the
internal error.
Note that the new test does not use the build_executable_and_dwo_files
proc, because I found that it is subtly broken and doesn't work to put
multiple units in a single .dwo file. The debug abbrev offset field in
the second unit's header would be 0, when it should have been something
else. The problem is that no linking is ever done to generate the .dwo
file, so the relocation that would apply for this field is never
applied. Instead, I generate two DWARF debug infos separately and link
the .dwo file using gdb_compile, it seems to work fine.
Change-Id: I96f809c56f703e25f72b8622c32e6bb91de20d6a
Approved-By: Tom Tromey <tom@tromey.com>
Fix what looks like a copy paste error resulting in the wrong abbrev
section name. The resulting section name in my test was
".debug_info.dwo.dwo", when it should have been ".debug_abbrev.dwo".
Change-Id: I82166d8ac6eaf3c3abc15d2d2949d00c31fe79f4
Approved-By: Tom Tromey <tom@tromey.com>
Add support to the DWARF assembler to generate DWARF 5 split compile
units. The assembler knows how to generate DWARF < 5 split compile
units (fission), DWARF 5 compile units, but not DWARF 5 split compile
units. What's missing is:
- using the right unit type in the header: skeleton for the unit in the
main file and split_compile for the unit in the DWO file
- have a way for the caller to specify the DWO ID that will end up in
the unit header
Add a dwo_id parameter to the cu proc. In addition to specifying the
DWO ID, the presence of this parameter tells the assembler to use the
skeleton or split_compile unit type.
This is used in a subsequent patch.
Change-Id: I05d9b189a0843ea6c2771b1d5e5a91762426dea9
Approved-By: Tom Tromey <tom@tromey.com>
I'm currently fixing bugs and performance issues when GDB encounters
this particular configuration. Since split DWARF + type units makes GDB
take some code paths not taken by any other board files, I think it
deserves to be its own board file. One particularity is that the
produced .dwo files have a .debug_info.dwo section that contains some
ype units, in addition to the compile unit.
Add that board to make-check-all.sh.
Change-Id: I245e6f600055a27e0c31f1a4a9af1f68292fe18c
Approved-By: Tom Tromey <tom@tromey.com>
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
and move it from gdb.base to gdb.arch as it's a target specific test.
Reviewed-by: Maciej W. Rozycki <macro@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
The GNU Assembler User Guide says that the right shift operator ">>"
in an expression is the same as the C operator.
On LoongArch the assembler directives and instructions do not treat
negative numbers ">>" the same way. The directives treats negative
numbers ">>" as logical right shifts while the instructions treats them
as arithmetic right shifts.
The right shift of negative numbers in the instructions may be changed
from an arithmetic right shift to a logical right shift in the future,
and a warning is issued for this.
Consider the following scenario:
...
$ cat hello
int
main (void)
{
printf ("hello\n");
return 0;
}
$ gcc -x c hello -g
$ gdb -q -iex "maint set gnu-source-highlight enabled off" a.out
Reading symbols from a.out...
(gdb) start
Temporary breakpoint 1 at 0x4005db: file hello, line 6.
Starting program: /data/vries/gdb/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Temporary breakpoint 1, main () at hello:6
6 printf ("hello\n");
...
This doesn't produce highlighting for line 6, because:
- pygments is used for highlighting instead of source-highlight, and
- pygments guesses the language for highlighting only based on the filename,
which in this case doesn't give a clue.
Fix this by:
- adding a language parameter to the extension_language_ops.colorize interface,
- passing the language as found in the debug info, and
- using it in gdb.styling.colorize to pick the pygments lexer.
The new test-case gdb.python/py-source-styling-2.exp excercises a slightly
different scenario: it compiles a c++ file with a .c extension, and checks
that c++ highlighting is done instead of c highlighting.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/30966
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966
I noticed that if deferred curses initialization fails, for instance when
using TERM=dumb, and we try the same again, we run into the same error:
...
$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
...
I think it's better to try deferred curses initialization only once.
Fix this by changing bool tui_finish_init into a tribool, and using
TRIBOOL_UNKNOWN to represent the "initialization failed" state, such that we
get instead:
...
$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
Cannot enable the TUI
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
