The 'PacketSize' attribute of the qSupported packet was
documented to be the maximum size of the packet including
the frame and checksum bytes, however this is not how it
was treated in the code. In reality, PacketSize is the
maximum size of the data in the RSP packets, not including
the framing or checksum bytes.
For instance, GDB's remote.c treats it as the maximum
number of data bytes. See remote_read_bytes_1, where the
size of the request is capped at PacketSize/2 (for
hex-encoding).
Also see gdbserver's server.cc, where the internal buffer
is sized as PBUFSIZ and PBUFSIZ-1 is used as PacketSize.
In gdbserver's case, the buffer is not used for any of the
framing or checksum characters. (I am not certain where the -1
comes from. I think it comes from back when there were no
binary packets, so packets were treated as strings with
null terminators).
It also seems like gdbservers in the wild treat it in
this way:
Handle two-linetable function in find_epilogue_using_linetable
Consider the following test-case:
...
$ cat hello.c
int main()
{
printf("hello ");
#include "world.inc"
$ cat world.inc
printf("world\n");
return 0;
}
$ gcc -g hello.c
...
The line table for the compilation unit, consisting just of
function main, is translated into these two gdb line tables, one for hello.c
and one for world.inc:
...
compunit_symtab: hello.c
symtab: hello.c
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 3 0x400557 0x400557 Y
1 4 0x40055b 0x40055b Y
2 END 0x40056a 0x40056a Y
compunit_symtab: hello.c
symtab: world.inc
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 1 0x40056a 0x40056a Y
1 2 0x400574 0x400574 Y
2 3 0x400579 0x400579 Y
3 END 0x40057b 0x40057b Y
...
The epilogue of main starts at 0x400579:
...
400579: 5d pop %rbp
40057a: c3 ret
...
Now, say we have an epilogue_begin marker in the line table at 0x400579.
We won't find it using find_epilogue_using_linetable, because it does:
...
const struct symtab_and_line sal = find_pc_line (start_pc, 0);
...
which gets us the line table for hello.c.
Fix this by using "find_pc_line (end_pc - 1, 0)" instead.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
PR symtab/31622
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622
Here the read happens below the first element of the line
table, and the test failure depends on the value that is
read from there.
It also happens that std::lower_bound returns a pointer exactly at the upper
bound of the line table, also here the read value is undefined, that happens
in this test:
Fixes: 528b729be1a2 ("gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table") Co-Authored-By: Tom de Vries <tdevries@suse.de>
PR symtab/31268
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31268
Tom de Vries [Wed, 24 Apr 2024 13:36:02 +0000 (15:36 +0200)]
[gdb/testsuite] Fix gdb.threads/threadcrash.exp for remote host
With test-case gdb.threads/threadcrash.exp using host board local-remote-host
and target board remote-gdbserver-on-localhost I run into:
...
(gdb) PASS: gdb.threads/threadcrash.exp: test_gcore: continue to crash
gcore $outputs/gdb.threads/threadcrash/threadcrash.gcore^M
Failed to open '$outputs/gdb.threads/threadcrash/threadcrash.gcore' for output.^M
(gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: saving gcore
UNSUPPORTED: gdb.threads/threadcrash.exp: test_gcore: couldn't generate gcore file
...
The problem is that the gcore command tries to save a file on a remote host,
but the filename is a location on build.
Tom de Vries [Wed, 24 Apr 2024 13:36:02 +0000 (15:36 +0200)]
[gdb/testsuite] Fix gdb.threads/threadcrash.exp with glibc debuginfo
After installing glibc debuginfo, I ran into:
...
FAIL: gdb.threads/threadcrash.exp: test_live_inferior: \
$thread_count == [llength $test_list]
...
This happens because the clause:
...
-re "^\r\n${hs}main$hs$eol" {
...
which is intended to match only:
...
#1 <hex> in main () at threadcrash.c:423^M
...
also matches "remaining" in:
...
#1 <hex> in __GI___nanosleep (requested_time=<hex>, remaining=<hex>) at \
nanosleep.c:27^M
...
H.J. Lu [Tue, 23 Apr 2024 14:07:51 +0000 (07:07 -0700)]
objcopy.c: Fix bfd_copy_private_symbol_data on 32-bit hosts
Use long with bfd_copy_private_symbol_data to fix
.../binutils/objcopy.c: In
function ‘copy_object’:
.../binutils/objcopy.c:3383:17: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘long int’ [-Werror=sign-compare]
3383 | for (i = 0; i < symcount; i++)
| ^
on 32-bit hosts.
PR binutils/14493
* objcopy.c (copy_object): Use long with
bfd_copy_private_symbol_data.
Simon Marchi [Tue, 23 Apr 2024 13:23:00 +0000 (09:23 -0400)]
gdb: move annotation_level declaration/definition to annotate.{h,c}
The declaration of annotation_level is currently in defs.h, while the
definition is in stack.c. I don't really understand why that variable
would live in stack.c, it seems completely unrelated. Move it to
annotate.c, and move the declaration to annotate.h.
Change-Id: I6cf8e9bd20e83959bdf5ad58dd008b6e1187d7d8 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Tue, 23 Apr 2024 13:22:59 +0000 (09:22 -0400)]
gdb: move a bunch of quit-related things to event-top.{c,h}
Move some declarations related to the "quit" machinery from defs.h to
event-top.h. Most of the definitions associated to these declarations
are in event-top.c. The exceptions are `quit()` and `maybe_quit()`,
that are defined in utils.c. For consistency, move these two
definitions to event-top.c.
Include "event-top.h" in many files that use these things.
Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378 Approved-By: Tom Tromey <tom@tromey.com>
The compiler seems right, there is not need to std::move the result of
`release_parent_map ()`, it's already going to be an rvalue. Remove the
std::move.
The issue isn't FreeBSD-specific, I see it on Linux as well when
building hwith clang, I just noticed it on a FreeBSD build first.
Change-Id: I7aa20a4db56c799f20d838ad08099a01653bba19 Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Mon, 22 Apr 2024 09:38:51 +0000 (19:08 +0930)]
PR31667, objcopy/strip corrupts solaris binaries
Using want_p_paddr_set_to_zero in commit 45d92439aebd was wrong. Even
solaris targets don't have want_p_paddr_set_to_zero, but we should
handle them at least somewhat reasonably.
PR 31667
* elf.c (IS_SECTION_IN_INPUT_SEGMENT): Remove bed arg, add
paddr_valid. Don't use bed->want_p_paddr_set_to_zero.
(INCLUDE_SECTION_IN_SEGMENT): Likewise.
(rewrite_elf_program_header): Adjust to suit.
Alan Modra [Sun, 21 Apr 2024 23:59:28 +0000 (09:29 +0930)]
ignore some symbols in elf.c:swap_out_syms
The reason behind this patch was noticing that generic ELF targets
fail to remove "bar" in the recently committed ld-elf/undefweak-1
test. (Despite that, those targets pass the test due to it being too
strict when matching symbols. "bar" gets turned into a local weak
defined absolute symbol.)
swap_out_syms currently drops local section syms that are defined in
discarded sections. Extend that to also drop other symbols in
discarded sections too, even global symbols. The linker goes to quite
a lot of effort to ensure globals in discarded section take a
definition from the kept linkonce or comdat group section. So the
global sym change should only affect cases where something is quite
wrong about the set of linkonce or comdat group sections. However
that change to elf_map_symbols meant we dropped _DYNAMIC_LINK /
_DYNAMIC_LINKING for mips, a global absolute symbol given STT_SECTION
type for some reason. That problem is fixed by reverting the pr14493
change which is no longer needed due to a) BSF_SECTION_SYM_USED on
x86, and b) fixing objcopy to use copy_private_symbol_data.
bfd/
PR 14493
* elf.c (ignore_sym): Rename from ignore_section_sym. Return
true for any symbol without a section or in a discarded section.
Revert pr14493 change.
(elf_map_symbols): Tidy. Use ignore_sym on all symbols.
(swap_out_syms): Tidy.
ld/
* testsuite/ld-elf/undefweak-1.rd: Match any "bar".
Alan Modra [Fri, 19 Apr 2024 23:24:07 +0000 (08:54 +0930)]
xfail undefweak-1 test for alpha
".set" has a different meaning on alpha. Changing it to ".equ" runs
into ".equ" having a different meaning on hppa, and changing it to "="
runs into trouble on bfin.
* testsuite/ld-elf/elf.exp (undefweak-1): xfail on alpha,
don't xfail for genelf.
Alan Modra [Mon, 22 Apr 2024 00:00:23 +0000 (09:30 +0930)]
copy_private_symbol_data
bfd_copy_private_symbol_data is a bfd function that appeared in
commit 89665c8562da a long time ago, but seemingly wasn't used
anywhere until Jan added it to gas/symbols.c in commit 6a2b6326c21e.
The function is used to modify ELF symbol st_shndx for symbols defined
in odd sections like .symtab, so that they get the corresponding
section st_shndx in an output file. This patch fixes some bitrot in
the function. After commit c03551323c04 which introduced
output_elf_obj_tdata, elf_strtab_sec and elf_shstrtab_sec will
segfault if used on an input bfd.
PR 14493
* elf.c (_bfd_elf_copy_private_symbol_data): Don't use
elf_strtab_sec and elf_shstrtab_sec.
Simon Marchi [Mon, 22 Apr 2024 20:10:17 +0000 (16:10 -0400)]
gdb: don't include gdbsupport/array-view.h in defs.h
Nothing in defs.h actually uses this. Everything that I (and the
buildbot) can compile still compiles, so I guess that all users of
array_view already include it one way or another. Worst case, if this
causes some build failure, the fix will be one #include away.
Change-Id: I981be98b0653cc18c929d85e9afd8732332efd15 Approved-By: John Baldwin <jhb@FreeBSD.org>
Simon Marchi [Mon, 22 Apr 2024 20:10:16 +0000 (16:10 -0400)]
gdb: don't include hashtab.h in defs.h
Nothing in defs.h actually uses this.
Add some includes for some spots using things from hashtab.h. Note that
if the GDB build doesn't use libxxhash, hashtab.h is included by
gdbsupport/common-utils.h, so all files still see hashtab.h. It puzzled
me for some time why I didn't see build failures in my build (which
didn't use libxxhash) but the buildbot gave build failures (it uses
libxxhash).
Change-Id: I8efd68decdaf579f048941c7537cd689885caa2a Approved-By: John Baldwin <jhb@FreeBSD.org>
gdb/testsuite: Use default gdb_expect timeout in runto
runto uses a hard-coded timeout of 30s in its invocation of gdb_expect.
This is normally fine, but for very a slow system (e.g., an emulator) it
may not be enough time for GDB to reach the intended breakpoint.
gdb_expect can obtain a timeout value from user-configurable variables
when it's not given one explicitly, so use that mechanism instead since
the user will have already adjusted the timeout variable to account for
the slow system.
Tom Tromey [Sat, 6 Apr 2024 18:37:37 +0000 (12:37 -0600)]
Use std::vector in event-loop.cc
In my occasional and continuing campaign against realloc, this patch
changes event-loop.cc to use std::vector to keep track of pollfd
objects. Regression tested on x86-64 Fedora 38.
Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: John Baldwin <jhb@FreeBSD.org>
Tom Tromey [Wed, 17 Apr 2024 22:17:33 +0000 (16:17 -0600)]
Remove some alloca uses
A few spots (mostly in the parsers) use alloca to ensure that a string
is terminated before passing it to a printf-like function (mostly
'error'). However, this isn't needed as the "%.*s" format can be used
instead.
This patch makes this change.
In one spot the alloca is dead code and is simply removed.
Ignore .align at the start of a section may result in misalignment when
partial linking. Manually add -mignore-start-align option without partial
linking.
Gcc -falign-functions add .align 5 to the start of a section, it causes some
error message mismatch. Set these testcases to xfail on LoongArch target.
Simon Marchi [Fri, 19 Apr 2024 19:46:54 +0000 (15:46 -0400)]
gdb: add target_debug_printf and target_debug_printf_nofunc
Add the `target_debug_printf` and `target_debug_printf_nofunc` macros
and use them when outputting debug messages depending on `targetdebug`.
I opted for `target_debug_printf_nofunc` to follow the current style
where the function name is already printed, along with the arguments.
Modify the debug printfs in the `debug_target` methods (generated by
`make-target-delegates.py`) to use `target_debug_printf_nofunc` as well.
This makes the "target" debug prints integrate nicely with the other
debug prints that use the "new" debug print system:
Simon Marchi [Fri, 19 Apr 2024 19:46:51 +0000 (15:46 -0400)]
gdb: make target debug functions return std::string
Change the functions in target-debug.h to return string representations
in an std::string, such that they don't need to know how the printing
part is done. This also helps the following patch that makes the debug
prints in debug_target one-liners.
Update target-delegates.c (through make-target-delegates.py) to do the
printing.
Add an overload of gdb_puts to avoid using `.c_str ()`.
Change-Id: I55cbff1c1b03a3b24a81740e34c6ad41ac4f8453 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 19 Apr 2024 20:04:32 +0000 (16:04 -0400)]
gdb: fix include for gdb_signal in target/waitstatus.h
clangd tells me that the gdb_signals.h include in target/waitstatus.h is
unused. This include was probably to give access to `enum gdb_signal`,
but this is in fact defined in gdb/signals.h. Change the include to
gdb/signals.h. Include gdbsupport/gdb_signals.h in some files that were
relying on the transitive include.
Nick Alcock [Wed, 17 Apr 2024 18:06:17 +0000 (19:06 +0100)]
libctf: do not include undefined functions in libctf.ver
libctf's version script is applied to two libraries: libctf.so,
and libctf-nobfd.so. The latter library is a subset of the former
which does not link to libbfd and does not include a few public
entry points that use it (found in libctf-open-bfd.c). This means
that some of the symbols in this version script only exist in one
of the libraries it's applied to.
A number of linkers dislike this: before now, only Solaris's linker
caused serious problems, introducing NOTYPE-typed symbols when such
things were found, but now LLD has started to complain as well:
ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_arc_open' failed: symbol not defined
ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_fdopen' failed: symbol not defined
ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_open' failed: symbol not defined
ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen' failed: symbol not defined
ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen_ctfsect' failed: symbol not defined
Rather than adding more and more whack-a-mole fixes for every
linker we encounter that does this, simply exclude such symbols
unconditionally, using the same trick we used to use for Solaris.
(Well, unconditionally if we can use version scripts with this
linker at all, which is not always the case.)
Thanks to Nicholas Vinson for the original report and a fix very
similar to this one (but not quite identical).
libctf/
* configure.ac: Always exclude libctf symbols from
libctf-nobfd's version script.
* configure: Regenerated.
Nicholas Vinson [Wed, 17 Apr 2024 17:52:45 +0000 (18:52 +0100)]
libctf: Remove undefined functions from ver. map
Starting with ld.lld-17, ld.lld is invoked with the option
--no-undefined-version enabled by default. Furthermore, The functions
ctf_label_set() and ctf_label_get() are not defined. Their inclusion in
libctf/libctf.ver causes ld.lld-17 to fail emitting the following error
messages:
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_set' failed: symbol not defined
ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_get' failed: symbol not defined
This patch fixes the issue by removing the symbol names from
libctf/libctf.ver.
[nca: fused in later commit that marked ctf_arc_open as libctf
only as well. Added ChangeLog entry.]
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
libctf/
* libctf.ver: drop nonexistent label functions: mark
ctf_arc_open as libctf-only.
Nick Alcock [Fri, 12 Apr 2024 13:46:00 +0000 (14:46 +0100)]
libctf: don't pass errno into ctf_err_warn so often
The libctf-internal warning function ctf_err_warn() can be passed a libctf
errno as a parameter, and will add its textual errmsg form to the passed-in
error message. But if there is an error on the fp already, and this is
specifically an error and not a warning, ctf_err_warn() will print the error
out regardless: there's no need to pass in anything but 0.
I've left all of those alone, because fixing it makes the code a bit longer:
but fixing the cases where no return is involved and the error has just been
set on the fp itself costs nothing and reduces redundancy a bit.
Nick Alcock [Tue, 2 Apr 2024 15:13:46 +0000 (16:13 +0100)]
libctf: add rewriting tests
Now there's a chance of it actually working, we can add more tests for
the long-broken dict read-and-rewrite cases. This is the first ever
test for the (rarely-used, unpleasant, and until recently completely
broken) ctf_gzwrite function.
libctf/
* testsuite/libctf-regression/gzrewrite*: New test.
* testsuite/libctf-regression/zrewrite*: Likewise.
Nick Alcock [Tue, 2 Apr 2024 15:06:50 +0000 (16:06 +0100)]
libctf: make ctf_lookup of symbols by name work in more cases
In particular, we don't need a symbol table if we're looking up a
symbol by name and that type of symbol has an indexed symtypetab,
since in that case we get the name from the symtypetab index, not
from the symbol table.
This lets you do symbol lookups in unlinked object files and unlinked
dicts written out via libctf's writeout functions.
libctf/
* ctf-lookup.c (ctf_lookup_by_sym_or_name): Allow lookups
by index even when there is no symtab.
Nick Alcock [Tue, 2 Apr 2024 12:48:13 +0000 (13:48 +0100)]
libctf: improve handling of type dumping errors
When dumping a type fails with an error, we want to emit a warning noting
this: a warning because it's not fatal and we can continue. But warnings
don't automatically print out the ctf_errno (because not all cases causing
warnings set the errno at all), so we must do it at warning-emission time or
lose track of what's gone wrong.
libctf/
* ctf-dump.c (ctf_dump_format_type): Dump the underlying error on
type dump failure.
Nick Alcock [Tue, 26 Mar 2024 13:04:20 +0000 (13:04 +0000)]
libctf: make ctf_serialize() actually serialize
ctf_serialize() evolved from the old ctf_update(), which mutated the
in-memory CTF dict to make all the dynamic in-memory types into static,
unchanging written-to-the-dict types (by deserializing and reserializing
it): back in the days when you could only do type lookups on static types,
this meant you could see all the types you added recently, at the small,
small cost of making it impossible to change those older types ever again
and inducing an amortized O(n^2) cost if you actually wanted to add
references to types you added at arbitrary times to later types.
It also reset things so that ctf_discard() would throw away only types you
added after the most recent ctf_update() call.
Some time ago this was all changed so that you could look up dynamic types
just as easily as static types: ctf_update() changed so that only its
visible side-effect of affecting ctf_discard() remained: the old
ctf_update() was renamed to ctf_serialize(), made internal to libctf, and
called from the various functions that wrote files out.
... but it was still working by serializing and deserializing the entire
dict, swapping out its guts with the newly-serialized copy in an invasive
and horrible fashion that coupled ctf_serialize() to almost every field in
the ctf_dict_t. This is totally useless, and fixing it is easy: just rip
all that code out and have ctf_serialize return a serialized representation,
and let everything use that directly. This simplifies most of its callers
significantly.
(It also points up another bug: ctf_gzwrite() failed to call ctf_serialize()
at all, so it would only ever work for a dict you just ctf_write_mem()ed
yourself, just for its invisible side-effect of serializing the dict!)
This lets us simplify away a bunch of internal-only open-side functionality
for overriding the syn_ext_strtab and some just-added functionality for
forcing in an existing atoms table, without loss of functionality, and lets
us lift the restriction on reserializing a dict that was ctf_open()ed rather
than being ctf_create()d: it's now perfectly OK to open a dict, modify it
(except for adding members to existing structs, unions, or enums, which
fails with -ECTF_RDONLY), and write it out again, just as one would expect.
libctf/
* ctf-serialize.c (ctf_symtypetab_sect_sizes): Fix typos.
(ctf_type_sect_size): Add static type sizes too.
(ctf_serialize): Return the new dict rather than updating the
existing dict. No longer fail for dicts with static types;
copy them onto the start of the new types table.
(ctf_gzwrite): Actually serialize before gzwriting.
(ctf_write_mem): Improve forced (test-mode) endian-flipping:
flip dicts even if they are too small to be compressed.
Improve confusing variable naming.
* ctf-archive.c (arc_write_one_ctf): Don't bother to call
ctf_serialize: both the functions we call do so.
* ctf-string.c (ctf_str_create_atoms): Drop serializing case
(atoms arg).
* ctf-open.c (ctf_simple_open): Call ctf_bufopen directly.
(ctf_simple_open_internal): Delete.
(ctf_bufopen_internal): Delete/rename to ctf_bufopen: no
longer bother with syn_ext_strtab or forced atoms table,
serialization no longer needs them.
* ctf-create.c (ctf_create): Call ctf_bufopen directly.
* ctf-impl.h (ctf_str_create_atoms): Drop atoms arg.
(ctf_simple_open_internal): Delete.
(ctf_bufopen_internal): Likewise.
(ctf_serialize): Adjust.
* testsuite/libctf-lookup/add-to-opened.c: Adjust now that
this is supposed to work.
Nick Alcock [Mon, 25 Mar 2024 19:07:43 +0000 (19:07 +0000)]
libctf: rethink strtab writeout
This commit finally adjusts strtab writeout so that repeated writeouts, or
writeouts of a dict that was read in earlier, only sorts the portion of the
strtab that was newly added.
There are three intertwined changes here:
- pull the contents of strtabs from newly ctf_bufopened dicts into the
atoms table, so that future additions will reuse the existing offset etc
rather than adding new identical strings
- allow the internal ctf_bufopen done by serialization to contribute its
existing atoms table, so that existing atoms can be used for the
remainder of the open process (like name table construction): this atoms
table currente gets thrown away in the mass reassignment done later in
ctf_serialize in any case, but it needs to be there during the open.
- rewrite ctf_str_write_strtab so that a) it uses iterators rather than
ctf_*_iter, reducing pointless structures which serve no other purpose
than to implement ordinary variable scope, but more clunkily, and b)
retains the existing strtab on the front of the new one, with its sort
retained, rather than resorting, so all existing already-written strtab
offsets remain valid across the call.
This latter change finally permits repeated serializations, and
reserializations of ctf_open()ed dicts, to work, but for now we keep the
code that prevents that because serialization is about to change again in a
way that will make it more obvious that doing such things is safe, and we
can take it out then.
(There are also some smaller changes like moving the purge of the refs table
into ctf_str_write_strtab(), since that's where the changes happen that
invalidate it, rather than doing it in ctf_serialize(). We also prohibit
something that has never worked, opening a dict and then reporting symbols
to it via ctf_link_add_strtab() et al: you must do that to newly-created
dicts which have had stuff ctf_link()ed into them. This is very unlikely
ever to be a problem in practice: linkers just don't do that sort of thing.)
libctf/
* ctf-create.c (ctf_create): Add (temporary) atoms arg.
* ctf-impl.h (struct ctf_dict.ctf_dynstrtab): New.
(ctf_str_create_atoms): Adjust.
(ctf_str_write_strtab): Likewise.
(ctf_simple_open_internal): Likewise.
* ctf-open.c (ctf_simple_open_internal): Add atoms arg.
(ctf_bufopen): Likewise.
(ctf_bufopen_internal): Initialize just enough of an
atoms table: pre-init from the atoms arg if supplied.
(ctf_simple_open): Adjust.
* ctf-serialize.c (ctf_serialize): Constify the strtab.
Move ref list purging into ctf_str_write_strtab.
Initialize the new dict with the old dict's atoms table.
Accept the new strtab from ctf_str_write_strtab.
Adjust for addition of ctf_dynstrtab.
* ctf-string.c (ctf_strraw_explicit): Improve comments.
(ctf_str_create_atoms): Prepopulate from an existing atoms table,
or alternatively pull in all strings from the strtab and turn
them into atoms.
(ctf_str_free_atoms): Free the dynstrtab and its strtab.
(struct ctf_strtab_write_state): Remove.
(ctf_str_count_strtab): Fold this...
(ctf_str_populate_sorttab): ... and this...
(ctf_str_write_strtab): ... into this. Prepend existing strings
to the strtab rather than resorting them (and wrecking their
offsets). Keep the dynstrtab updated. Update refs for all
atoms with refs, whether or not they are strings newly added
to the strtab.
Nick Alcock [Mon, 25 Mar 2024 16:39:02 +0000 (16:39 +0000)]
libctf: replace 'pending refs' abstraction
A few years ago we introduced a 'pending refs' abstraction to fix one
problem: serializing a dict, then changing it would tend to corrupt the dict
because the strtab sort we do on strtab writeout (to improve compression
efficiency) would modify the offset of any strings that sorted
lexicographically earlier in the strtab: so we added a new restriction that
all strings are added only at serialization time, and maintained a set of
'pending' refs that were added earlier, whose offsets we could update (like
other refs) at writeout time.
This was in hindsight seriously problematic for maintenance (because
serialization has to traverse all strings in all datatypes in the entire
dict), and has become impossible to sustain now that we can read in existing
dicts, modify them, and reserialize them again. We really don't want to
have to dig through the entire dict we jut read in just in order to dig out
all its strtab offsets, then *change* it, just for the sake of a sort that
adds a frankly trivial amount of compression efficiency.
Sorting *is* still worthwhile -- but it sacrifices very little to only sort
newly-added portions of the strtab, reusing older portions as necessary.
As a first stage in this, discard the whole "pending refs" abstraction and
replace it with "movable" refs, which are exactly like all other refs
(addresses containing the strtab offset of some string, which are updated
wiht the final strtab offset on serialization) except that we track them in
a reverse dict so that we can move the refs around (which we do whenever we
realloc() a buffer containing a bunch of structure members or something when
we add members to the structure).
libctf/
* ctf-create.c (ctf_add_enumerator): Call ctf_str_move_refs; add
a movable ref.
(ctf_add_member_offset): Likewise.
* ctf-util.c (ctf_realloc): Delete.
* ctf-serialize.c (ctf_serialize): No longer use it. Adjust to
new fields.
* ctf-string.c (ctf_str_purge_atom_refs): Purge movable refs.
(ctf_str_free_atom): Free freeable atoms' strings.
(ctf_str_create_atoms): Create the movable refs dynhash if needed.
(ctf_str_free_atoms): Destroy it.
(CTF_STR_MOVABLE): Switch (back) from ints to flags (see previous
reversion). Add new flag.
(aref_create): New, populate movable refs if need be.
(ctf_str_add_ref_internal): Switch back to flags, update refs
directly for nonprovisional strings (with already-known fixed offsets);
create refs via aref_create. Allocate strings only if not within an
mmapped strtab.
(ctf_str_add_movable_ref): New.
(ctf_str_add): Adjust to CTF_STR_* reintroduction.
(ctf_str_add_external): LIkewise.
(ctf_str_move_refs): New, move refs via ctf_str_movable_refs
backpointer.
(ctf_str_purge_refs): Drop ctf_str_num_refs.
(ctf_str_update_refs): Fix indentation.
* ctf-impl.h (struct ctf_str_atom_movable): New.
(struct ctf_dict.ctf_str_num_refs): Drop.
(struct ctf_dict.ctf_str_movable_refs): New.
(ctf_str_add_movable_ref): Declare.
(ctf_str_move_refs): Likewise.
(ctf_realloc): Drop.
Nick Alcock [Fri, 5 Jan 2024 12:17:27 +0000 (12:17 +0000)]
libctf: rename ctf_dict.ctf_{symtab,strtab}
These two fields are constantly confusing because CTF dicts contain both
a symtypetab and strtab, but these fields are not that: they are the
symtab and strtab from the ELF file. We have enough string tables now
(internal, external, synthetic external, dynamic) that we need to at
least name them better than this to avoid getting totally confused.
Rename them to ctf_ext_symtab and ctf_ext_strtab.
Nick Alcock [Fri, 5 Jan 2024 11:09:01 +0000 (11:09 +0000)]
libctf: delete LCTF_DIRTY
This flag was meant as an optimization to avoid reserializing dicts
unnecessarily. It was critically necessary back when serialization was
done by ctf_update() and you had to call that every time you wanted any
new modifications to the type table to be usable by other types, but
that has been unnecessary for years now, and serialization is only done
once when writing out, which one would naturally assume would always
serialize the dict. Worse, it never really worked: it only tracked
newly-added types, not things like added symbols which might equally
well require reserialization, and it gets in the way of an upcoming
change. Delete entirely.
Nick Alcock [Tue, 19 Dec 2023 16:58:19 +0000 (16:58 +0000)]
libctf: support addition of types to dicts read via ctf_open()
libctf has long declared deserialized dictionaries (out of files or ELF
sections or memory buffers or whatever) to be read-only: back in the
furthest prehistory this was not the case, in that you could add a
few sorts of type to such dicts, but attempting to do so often caused
horrible memory corruption, so I banned the lot.
But it turns out real consumers want it (notably DTrace, which
synthesises pointers to types that don't have them and adds them to the
ctf_open()ed dicts if it needs them). Let's bring it back again, but
without the memory corruption and without the massive code duplication
required in days of yore to distinguish between static and dynamic
types: the representation of both types has been identical for a few
years, with the only difference being that types as a whole are stored in
a big buffer for types read in via ctf_open and per-type hashtables for
newly-added types.
So we discard the internally-visible concept of "readonly dictionaries"
in favour of declaring the *range of types* that were already present
when the dict was read in to be read-only: you can't modify them (say,
by adding members to them if they're structs, or calling ctf_set_array
on them), but you can add more types and point to them. (The API
remains the same, with calls sometimes returning ECTF_RDONLY, but now
they do so less often.)
This is a fairly invasive change, mostly because code written since the
ban was introduced didn't take the possibility of a static/dynamic split
into account. Some of these irregularities were hard to define as
anything but bugs.
Notably:
- The symbol handling was assuming that symbols only needed to be
looked for in dynamic hashtabs or static linker-laid-out indexed/
nonindexed layouts, but now we want to check both in case people
added more symbols to a dict they opened.
- The code that handles type additions wasn't checking to see if types
with the same name existed *at all* (so you could do
ctf_add_typedef (fp, "foo", bar) repeatedly without error). This
seems reasonable for types you just added, but we probably *do* want
to ban addition of types with names that override names we already
used in the ctf_open()ed portion, since that would probably corrupt
existing type relationships. (Doing things this way also avoids
causing new errors for any existing code that was doing this sort of
thing.)
- ctf_lookup_variable entirely failed to work for variables just added
by ctf_add_variable: you had to write the dict out and read it back
in again before they appeared.
- The symbol handling remembered what symbols you looked up but didn't
remember their types, so you could look up an object symbol and then
find it popping up when you asked for function symbols, which seems
less than ideal. Since we had to rejig things enough to be able to
distinguish function and object symbols internally anyway (in order
to give suitable errors if you try to add a symbol with a name that
already existed in the ctf_open()ed dict), this bug suddenly became
more visible and was easily fixed.
We do not (yet) support writing out dicts that have been previously read
in via ctf_open() or other deserializer (you can look things up in them,
but not write them out a second time). This never worked, so there is
no incompatibility; if it is needed at a later date, the serializer is a
little bit closer to having it work now (the only table we don't deal
with is the types table, and that's because the upcoming CTFv4 changes
are likely to make major changes to the way that table is represented
internally, so adding more code that depends on its current form seems
like a bad idea).
There is a new testcase that tests much of this, in particular that
modification of existing types is still banned and that you can add new
ones and chase them without error.
libctf/
* ctf-impl.h (struct ctf_dict.ctf_symhash): Split into...
(ctf_dict.ctf_symhash_func): ... this and...
(ctf_dict.ctf_symhash_objt): ... this.
(ctf_dict.ctf_stypes): New, counts static types.
(LCTF_INDEX_TO_TYPEPTR): Use it instead of CTF_RDWR.
(LCTF_RDWR): Deleted.
(LCTF_DIRTY): Renumbered.
(LCTF_LINKING): Likewise.
(ctf_lookup_variable_here): New.
(ctf_lookup_by_sym_or_name): Likewise.
(ctf_symbol_next_static): Likewise.
(ctf_add_variable_forced): Likewise.
(ctf_add_funcobjt_sym_forced): Likewise.
(ctf_simple_open_internal): Adjust.
(ctf_bufopen_internal): Likewise.
* ctf-create.c (ctf_grow_ptrtab): Adjust a lot to start with.
(ctf_create): Migrate a bunch of initializations into bufopen.
Force recreation of name tables. Do not forcibly override the
model, let ctf_bufopen do it.
(ctf_static_type): New.
(ctf_update): Drop LCTF_RDWR check.
(ctf_dynamic_type): Likewise.
(ctf_add_function): Likewise.
(ctf_add_type_internal): Likewise.
(ctf_rollback): Check ctf_stypes, not LCTF_RDWR.
(ctf_set_array): Likewise.
(ctf_add_struct_sized): Likewise.
(ctf_add_union_sized): Likewise.
(ctf_add_enum): Likewise.
(ctf_add_enumerator): Likewise (only on the target dict).
(ctf_add_member_offset): Likewise.
(ctf_add_generic): Drop LCTF_RDWR check. Ban addition of types
with colliding names.
(ctf_add_forward): Note safety under the new rules.
(ctf_add_variable): Split all but the existence check into...
(ctf_add_variable_forced): ... this new function.
(ctf_add_funcobjt_sym): Likewise...
(ctf_add_funcobjt_sym_forced): ... for this new function.
* ctf-link.c (ctf_link_add_linker_symbol): Ban calling on dicts
with any stypes.
(ctf_link_add_strtab): Likewise.
(ctf_link_shuffle_syms): Likewise.
(ctf_link_intern_extern_string): Note pre-existing prohibition.
* ctf-lookup.c (ctf_lookup_by_id): Drop LCTF_RDWR check.
(ctf_lookup_variable): Split out looking in a dict but not
its parent into...
(ctf_lookup_variable_here): ... this new function.
(ctf_lookup_symbol_idx): Track whether looking up a function or
object: cache them separately.
(ctf_symbol_next): Split out looking in non-dynamic symtypetab
entries to...
(ctf_symbol_next_static): ... this new function. Don't get confused
by the simultaneous presence of static and dynamic symtypetab entries.
(ctf_try_lookup_indexed): Don't waste time looking up symbols by
index before there can be any idea how symbols are numbered.
(ctf_lookup_by_sym_or_name): Distinguish between function and
data object lookups. Drop LCTF_RDWR.
(ctf_lookup_by_symbol): Adjust.
(ctf_lookup_by_symbol_name): Likewise.
* ctf-open.c (init_types): Rename to...
(init_static_types): ... this. Drop LCTF_RDWR. Populate ctf_stypes.
(ctf_simple_open): Drop writable arg.
(ctf_simple_open_internal): Likewise.
(ctf_bufopen): Likewise.
(ctf_bufopen_internal): Populate fields only used for writable dicts.
Drop LCTF_RDWR.
(ctf_dict_close): Cater for symhash cache split.
* ctf-serialize.c (ctf_serialize): Use ctf_stypes, not LCTF_RDWR.
* ctf-types.c (ctf_variable_next): Drop LCTF_RDWR.
* testsuite/libctf-lookup/add-to-opened*: New test.
Nick Alcock [Mon, 18 Dec 2023 18:27:44 +0000 (18:27 +0000)]
libctf: fix name lookup in dicts containing base-type bitfields
The intent of the name lookup code was for lookups to yield non-bitfield
basic types except if none existed with a given name, and only then
return bitfield types with that name. Unfortunately, the code as
written only does this if the base type has a type ID higher than all
bitfield types, which is most unlikely (the opposite is almost always
the case).
Adjust it so that what ends up in the name table is the highest-width
zero-offset type with a given name, if any such exist, and failing that
the first type with that name we see, no matter its offset. (We don't
define *which* bitfield type you get, after all, so we might as well
just stuff in the first we find.)
Reported by Stephen Brennan <stephen.brennan@oracle.com>.
libctf/
* ctf-open.c (init_types): Modify to allow some lookups during open;
detect bitfield name reuse and prefer less bitfieldy types.
* testsuite/libctf-writable/libctf-bitfield-name-lookup.*: New test.
Nick Alcock [Mon, 18 Dec 2023 17:47:48 +0000 (17:47 +0000)]
libctf: remove static/dynamic name lookup distinction
libctf internally maintains a set of hash tables for type name lookups,
one for each valid C type namespace (struct, union, enum, and everything
else).
Or, rather, it maintains *two* sets of hash tables: one, a ctf_hash *,
is meant for lookups in ctf_(buf)open()ed dicts with fixed content; the
other, a ctf_dynhash *, is meant for lookups in ctf_create()d dicts.
This distinction was somewhat valuable in the far pre-binutils past when
two different hashtable implementations were used (one expanding, the
other fixed-size), but those days are long gone: the hash table
implementations are almost identical, both wrappers around the libiberty
hashtab. The ctf_dynhash has many more capabilities than the ctf_hash
(iteration, deletion, etc etc) and has no downsides other than starting
at a fixed, arbitrary small size.
That limitation is easy to lift (via a new ctf_dynhash_create_sized()),
following which we can throw away nearly all the ctf_hash
implementation, and all the code to choose between readable and writable
hashtabs; the few convenience functions that are still useful (for
insertion of name -> type mappings) can also be generalized a bit so
that the extra string verification they do is potentially available to
other string lookups as well.
(libctf still has two hashtable implementations, ctf_dynhash, above,
and ctf_dynset, which is a key-only hashtab that can avoid a great many
malloc()s, used for high-volume applications in the deduplicator.)
Nick Alcock [Wed, 13 Dec 2023 12:24:57 +0000 (12:24 +0000)]
libctf: don't leak the symbol name in the name->type cache
This cache replaced a cache of symbol index->ctf_id_t. That cache was
just an array, so it could get away with just being free()d, but the
ctfi_symnamedicts cache that replaced it is a full dynhash with a
dynamically-allocated string as the key. As such, it needs freeing with
ctf_dynhash_destroy(), not just free(), or we leak parts of the
underlying hashtab, and all the keys.
Nick Alcock [Mon, 2 Oct 2023 14:37:17 +0000 (15:37 +0100)]
binutils, objdump: Add --ctf-parent-section
This lets you examine CTF where the parent and child dicts are in entirely
different sections, rather than in a CTF archive with members with different
names. The linker doesn't emit ELF objects structured like this, but some
third-party linkers may; it's also useful for objcopy-constructed files
in some cases.
(This is what the objdump --ctf-parent option used to do before commit 80b56fad5c99a8c9 in 2021. The new semantics of that option are much more
useful, but that doesn't mean the old ones are never useful at all, so let's
bring them back.)
(I was specifically driven to add this by DTrace's obscure "ctypes" and
"dtypes" options, which dump its internal, dynamically-generated dicts out
to files for debugging purposes: there are two, one the parent of the other.
Since they're in two separate files rather than a CTF archive and we have no
tools that paste files together into archives, objdump wouldn't show them --
and even pasting them together into an ELF executable with objcopy didn't
help, since objdump had no options that could be used to look in specific
sections for the parent dict. With --ctf-parent-section, this sort of
obscure use case becomes possible again. You'll never need it for the
output of the normal linker.)
This commit adds a new packet, qIsAddressTagged, allowing GDB remote
targets to use it to query the stub if a given address is tagged.
Currently, the memory tagging address check is done via a read query,
where the contents of /proc/<PID>/smaps is read and the flags are
inspected for memory tagging-related flags that indicate the address is
in a memory tagged region.
This is not ideal, for example, for QEMU stub and other cases, such as
on bare-metal, where there is no notion of an OS file like 'smaps.'
Hence, the introduction of qIsAddressTagged packet allows checking
if an address is tagged in an agnostic way.
The is_address_tagged target hook in remote.c attempts to use the
qIsAddressTagged packet first for checking if an address is tagged and
if the stub does not support such a packet (reply is empty) it falls
back to using the current mechanism that reads the contents of
/proc/<PID>/smaps via vFile requests.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
This commit introduces a new target hook, target_is_address_tagged,
which is used instead of the gdbarch_tagged_address_p gdbarch hook in
the upper layer (printcmd.c).
This change enables easy specialization of memory tagging address
check per target in the future. As target_is_address_tagged continues
to utilize the gdbarch_tagged_address_p hook, there is no change in
behavior for all the targets that use the new target hook (i.e., the
remote.c, aarch64-linux-nat.c, and corelow.c targets).
Just the gdbarch_tagged_address_p signature is changed for convenience,
since target_is_address_tagged takes the address to be checked as a
CORE_ADDR type.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
gdb: Use passed gdbarch instead of calling current_inferior
In do_examine function, use passed gdbarch when checking if an address
is tagged instead of calling current_inferior()->arch() to make the code
more localized and help modularity by not calling a current_* function,
which disguises the use of a global state/variable. There is no change
in the code behavior.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Suggested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
gdb: aarch64: Remove MTE address checking from memtag_matches_p
This commit removes aarch64_linux_tagged_address_p from
aarch64_linux_memtag_matches_p. aarch64_linux_tagged_address_p checks if
an address is tagged (MTE) or not.
The check is redundant because aarch64_linux_memtag_matches_p is always
called from the upper layers (i.e. from printcmd.c via gdbarch hook
gdbarch_memtag_matches_p) after either gdbarch_tagged_address_p (that
already points to aarch64_linux_tagged_address_p) has been called or
after should_validate_memtags (that calls gdbarch_tagged_address_p at
the end) has been called, so the address is already checked. Hence:
a) in print_command_1, gdbarch_memtag_matches_p is called only after
should_validate_memtags is called, which checks the address at its end;
b) in memory_tag_check_command, gdbarch_memtag_matches_p is called only
after gdbarch_tagged_address_p is called directly.
Also, because after this change the address checking only happens at the
upper layer it now allows the address checking to be specialized easily
per target, via a target hook.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
gdb: aarch64: Move MTE address check out of set_memtag
Remove check in parse_set_allocation_tag_input as it is redundant:
currently the check happens at the end of parse_set_allocation_tag_input
and also in set_memtag (called after parse_set_allocation_tag_input).
After it, move MTE address check out of set_memtag and add this check to
the upper layer, before set_memtag is called.
This is a preparation for using a target hook instead of a gdbarch hook
on MTE address checks.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com>
gdb: aarch64: Remove MTE address checking from get_memtag
This commit removes aarch64_linux_tagged_address_p from
aarch64_linux_get_memtag. aarch64_linux_tagged_address_p checks if an
address is tagged (MTE) or not.
The check is redundant because aarch64_linux_get_memtag is always called
from the upper layers (i.e. from printcmd.c via gdbarch hook
gdbarch_get_memtag) after either gdbarch_tagged_address_p (that already
points to aarch64_linux_tagged_address_p) has been called or
after should_validate_memtags (that calls gdbarch_tagged_address_p at
the end) has been called, so the address is already checked. Hence:
a) in print_command_1, aarch64_linux_get_memtag (via gdbarch_get_memtag
hook) is called but only after should_validate_memtags, which calls
gdbarch_tagged_address_p;
b) in do_examine, aarch64_linux_get_memtag is also called only after
gdbarch_tagged_address_p is directly called;
c) in memory_tag_check_command, gdbarch_get_memtag is called -- tags
matching or not -- after the initial check via direct call to
gdbarch_tagged_address_p;
d) in memory_tag_print_tag_command, address is checked directly via
gdbarch_tagged_address_p before gdbarch_get_memtag is called.
Also, because after this change the address checking only happens at the
upper layer it now allows the address checking to be specialized easily
per target, via a target hook.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
H.J. Lu [Thu, 18 Apr 2024 12:28:56 +0000 (05:28 -0700)]
elf: Strip unreferenced weak undefined symbols
Linker will resolve an undefined symbol only if it is referenced by
relocation. Unreferenced weak undefined symbols serve no purpose.
Weak undefined symbols appear in the dynamic symbol table only when they
are referenced by dynamic relocation. Mark symbols with relocation and
strip undefined weak symbols if they don't have relocation and aren't
in the dynamic symbol table.
bfd/
PR ld/31652
* elf-bfd.h (elf_link_hash_entry): Add has_reloc.
* elf-vxworks.c (elf_vxworks_emit_relocs): Set has_reloc.
* elflink.c (_bfd_elf_link_output_relocs): Likewise.
(elf_link_output_extsym): Strip undefined weak symbols if they
don't have relocation and aren't in the dynamic symbol table.
Alan Modra [Thu, 18 Apr 2024 23:34:16 +0000 (09:04 +0930)]
mmix disassemble memory leak
It's a once-off and of no consequence, but fix it anyway. The mmix
caonoicalize_syms array is an array of pointers. Freeing it won't
lose symbol names.
Tom de Vries [Thu, 18 Apr 2024 15:02:13 +0000 (17:02 +0200)]
[gdb/testsuite] Use find_gnatmake instead of gdb_find_gnatmake
On SLE-11, with an older dejagnu version, I ran into:
...
Running gdb.ada/mi_prot.exp ...
UNRESOLVED: gdb.ada/mi_prot.exp: \
testcase aborted due to invalid command name: gdb_find_gnatmake
ERROR: tcl error sourcing gdb.ada/mi_prot.exp.
ERROR: invalid command name "gdb_find_gnatmake"
while executing
"::gdb_tcl_unknown gdb_find_gnatmake"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::gdb_tcl_unknown $args"
(procedure "::unknown" line 5)
invoked from within
"gdb_find_gnatmake"
(procedure "gnatmake_version_at_least" line 2)
invoked from within
...
Proc gdb_find_gnatmake is actually a backup for find_gnatmake:
...
if {[info procs find_gnatmake] == ""} {
rename gdb_find_gnatmake find_gnatmake
...
so gnatmake_version_at_least should use find_gnatmake instead.
For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we
don't run into this error.
For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to
find_gnatmake, and we do run into the error.
It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it
seems something legitimate to use. Maybe we should use future_ or gdb_future_
prefix instead to make this more clear, but I've left that alone for now.
Fix this by:
- triggering the same error with a recent dejagnu by removing
gdb_find_gnatmake unless used (and likewise for other procs in future.exp),
and
- using find_gnatmake in gnatmake_version_at_least.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31647
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647
Tom de Vries [Thu, 18 Apr 2024 15:01:09 +0000 (17:01 +0200)]
[gdb/testsuite] Use allocator_may_return_null=1 in two test-cases
Simon reported [1] that recent commit 06e967dbc9b ("[gdb/python] Throw
MemoryError in inferior.read_memory if malloc fails") introduced
AddressSanitizer allocation-size-too-big errors in the two test-cases
affected by this commit.
Fix this by suppressing the error in the two test-cases using
allocator_may_return_null=1.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html
Will Hawkins [Thu, 18 Apr 2024 11:28:52 +0000 (13:28 +0200)]
Add DW_TAG_compile_unit DIE to Dummy CUs
Dummy CUs help detect errors and are very helpful. However, the DWARF
spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to
the header. This patch adds that.
Alan Modra [Wed, 17 Apr 2024 08:59:19 +0000 (18:29 +0930)]
alpha_vms_get_section_contents vs. fuzzed files
This patch is in response to an oss-fuzz report regarding
use-of-uninitialized-value in bfd_is_section_compressed_info from
section contents provided by alpha_vms_get_section_contents. That
hole is covered by using bfd_zalloc rather than bfd_alloc.
The rest of the patch is mostly a tidy. In a function returning
section contents, I tend to prefer a test on the section properties
over a test on file properties. That's why I've changed the file
flags test to one on section filepos and flags before calling
_bfd_generic_get_section_contents. Also, fuzzed objects can easily
have sections with file backing in relocatable objects, or sections
without file backing in images. Possible confusion is avoided by
testing each section.
Note that we are always going to run into out-of-memory with fuzzed
alpha-vms object files due to sections with contents via ETIR records.
eg. ETIR__C_STO_IMMR stores a number of bytes repeatedly, with a
32-bit repeat count. So section contents can be very large from a
relatively small file. I'm inclined to think that an out-of-memory
error is fine for such files.
* vms-alpha.c (alpha_vms_get_section_contents): Handle sections
with non-zero filepos or without SEC_HAS_CONTENTS via
_bfd_generic_get_section_contents. Zero memory allocated for
sections filled by ETIR records.
projects / thirdparty / binutils-gdb.git / log
