The py-missing-objfile.exp test attempts to load a core file with
missing debug info and counts the number of times a python missing
objfile handler is called.
In one test case, the number of expected calls to the missing objfile
handler is two, but the test case misleadingly says three. This commit
fixes this typo.
Change-Id: I421143ebed392227f14918ea529eb0e9cbd98dda
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Consider function dw2_get_file_names:
...
static struct quick_file_names *
dw2_get_file_names (dwarf2_per_cu *this_cu, dwarf2_per_objfile *per_objfile)
{
/* This should never be called for TUs. */
gdb_assert (!this_cu->is_debug_types ());
if (this_cu->files_read)
return this_cu->file_names;
cutu_reader reader (*this_cu, *per_objfile, nullptr,
per_objfile->get_cu (this_cu), true, language_minimal,
nullptr);
if (!reader.is_dummy ())
dw2_get_file_names_reader (reader.cu (), reader.top_level_die ());
return this_cu->file_names;
}
...
If dw2_get_file_names_reader is called, the result is cached in
this_cu->file_names, and this fact is tracked in this_cu->files_read, allowing
subsequent calls to access the cached value.
But for dummy CUs, while the result (nullptr) is cached in
this_cu->file_names, this is not noted in this_cu->files_read, and
consequently subsequent calls will read the top-level DIE in the CU again.
Fix this by setting this_cu->files_read also for dummy CUs.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33777
This changes the DAP code so that constants will now be returned by a
DAP scopes request. This is perhaps slightly strange with Ada
enumerators, but on the other hand this is consistent with what the
CLI does.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
A co-worker reported that certain symbols weren't appearing in the DAP
'scopes' response. In particular, symbols with non-ASCII names didn't
appear; though further research showed that this was in fact a result
of the variable in question actually being a constant.
Unfortunately Ada still requires the user to set the Ada source
character set in order to properly display symbol names. For DAP, it
seemed to make sense to allow this as a launch parameter. This patch
implements this.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
This changes some DAP code to explicitly use a symbol's print name.
Some places were using '.name'; and while 'str' does use the print
name, it seems better to be both consistent and explicit.
This commit adds new "quick" symbol functions, expanded_symbols_functions,
that work purely on examining objfile's compunits. This is useful for
example for JIT reader API where symbols are created by user-provided
code.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33554
Approved-By: Tom Tromey <tom@tromey.com>
Update printing of enum types to follow the same formatting
conventions as for structs resulting in more readable output.
Now that horizontal space is less of an issue enum values are
always printed.
Empty enums are now printed with an added "<no enum values>"
message.
Example of printing an enum with default values:
enum class TestEnum {A, B, C, D};
(gdb) ptype TestEnum
type = enum class TestEnum : int {
TestEnum::A = 0,
TestEnum::B = 1,
TestEnum::C = 2,
TestEnum::D = 3
}
Example of printing an empty enum:
enum class TestEnum {};
(gdb) ptype TestEnum
type = enum class TestEnum : int {
<no enum values>
}
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19294
Approved-By: Tom Tromey <tom@tromey.com>
When creating a new line-breakpoint after rerunning with a disabled or
removed breakpoint in a solib, you currently get this use-after-free
crash:
(gdb) break solib_main
Breakpoint 1 at 0x1030
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/outputs/gdb.base/solib-breakpoints-rerun/solib-breakpoints-rerun
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
Breakpoint 1, solib_main (arg=100) at /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/solib1.c:7
7 int ans = arg*arg; /* HERE */
(gdb) disable
(gdb) set confirm off
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/outputs/gdb.base/solib-breakpoints-rerun/solib-breakpoints-rerun
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[Inferior 1 (process 50868) exited normally]
(gdb) break 18
=================================================================
==50836==ERROR: AddressSanitizer: heap-use-after-free on address 0x7d65a543d488 at pc 0x55f022334c29 bp 0x7ffe9c7f45f0 sp 0x7ffe9c7f45e0
READ of size 8 at 0x7d65a543d488 thread T0
#0 0x55f022334c28 in symtab::filename() const ../../gdb/symtab.h:1747
#1 0x55f023a32b7d in create_sals_line_offset ../../gdb/linespec.c:2013
#2 0x55f023a37937 in convert_linespec_to_sals ../../gdb/linespec.c:2294
#3 0x55f023a3cf79 in parse_linespec ../../gdb/linespec.c:2652
#4 0x55f023a415b2 in location_spec_to_sals ../../gdb/linespec.c:3050
#5 0x55f023a423b0 in decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) ../../gdb/linespec.c:3126
#6 0x55f022826e1b in parse_breakpoint_sals ../../gdb/breakpoint.c:9069
#7 0x55f0228291c2 in create_breakpoint(gdbarch*, location_spec*, char const*, int, int, char const*, bool, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) ../../gdb/breakpoint.c:9312
#8 0x55f02282c298 in break_command_1 ../../gdb/breakpoint.c:9471
#9 0x55f02282d0bb in break_command(char const*, int) ../../gdb/breakpoint.c:9541
#10 0x55f022b05f56 in do_simple_func ../../gdb/cli/cli-decode.c:94
0x7d65a543d488 is located 904 bytes inside of 4064-byte region [0x7d65a543d100,0x7d65a543e0e0)
freed by thread T0 here:
#0 0x7f55aa91f79d in free /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:51
#1 0x55f0221f6403 in xfree<void> ../../gdb/../gdbsupport/gdb-xfree.h:37
#2 0x55f027b64851 in call_freefun ../../libiberty/obstack.c:103
#3 0x55f027b66283 in _obstack_free ../../libiberty/obstack.c:280
#4 0x55f0221f7a07 in auto_obstack::~auto_obstack() ../../gdb/../gdbsupport/gdb_obstack.h:126
#5 0x55f023f3dd83 in objfile::~objfile() ../../gdb/objfiles.c:509
#6 0x55f023f511d8 in std::default_delete<objfile>::operator()(objfile*) const /usr/include/c++/15.2.1/bits/unique_ptr.h:93
#7 0x55f023f4b8cd in std::unique_ptr<objfile, std::default_delete<objfile> >::~unique_ptr() /usr/include/c++/15.2.1/bits/unique_ptr.h:399
#8 0x55f0240b6dab in owning_intrusive_list<objfile, intrusive_base_node<objfile> >::erase(intrusive_list_iterator<objfile, intrusive_base_node<objfile> >) ../../gdb/../gdbsupport/owning_intrusive_list.h:113
#9 0x55f0240adb68 in program_space::remove_objfile(objfile*) ../../gdb/progspace.c:202
#10 0x55f023f3cfcf in objfile::unlink() ../../gdb/objfiles.c:409
#11 0x55f023f40faf in objfile_purge_solibs(program_space*) ../../gdb/objfiles.c:687
#12 0x55f02487ec19 in no_shared_libraries(program_space*) ../../gdb/solib.c:1359
#13 0x55f024b37e1e in target_pre_inferior() ../../gdb/target.c:2474
#14 0x55f0238ac7cd in run_command_1 ../../gdb/infcmd.c:381
#15 0x55f0238ae438 in run_command ../../gdb/infcmd.c:510
#16 0x55f022b05f56 in do_simple_func ../../gdb/cli/cli-decode.c:94
previously allocated by thread T0 here:
#0 0x7f55aa920cb5 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
#1 0x55f02241d780 in xmalloc ../../gdb/alloc.c:52
#2 0x55f027b6461f in call_chunkfun ../../libiberty/obstack.c:94
#3 0x55f027b649d1 in _obstack_begin_worker ../../libiberty/obstack.c:141
#4 0x55f027b650c5 in _obstack_begin ../../libiberty/obstack.c:164
#5 0x55f0221f775a in auto_obstack::auto_obstack() ../../gdb/../gdbsupport/gdb_obstack.h:123
#6 0x55f023f39c91 in objfile::objfile(gdb::ref_ptr<bfd, gdb_bfd_ref_policy>, program_space*, char const*, enum_flags<objfile_flag>) ../../gdb/objfiles.c:257
#7 0x55f023f3ccaa in objfile::make(gdb::ref_ptr<bfd, gdb_bfd_ref_policy>, program_space*, char const*, enum_flags<objfile_flag>, objfile*) ../../gdb/objfiles.c:392
#8 0x55f02498b1d2 in symbol_file_add_with_addrs ../../gdb/symfile.c:1069
#9 0x55f02498c099 in symbol_file_add_from_bfd(gdb::ref_ptr<bfd, gdb_bfd_ref_policy> const&, char const*, enum_flags<symfile_add_flag>, std::vector<other_sections, std::allocator<other_sections> >*, enum_flags<objfile_flag>, objfile*) ../../gdb/symfile.c:1156
#10 0x55f02487255b in solib_read_symbols(solib&, enum_flags<symfile_add_flag>) ../../gdb/solib.c:660
#11 0x55f024876c0c in solib_add(char const*, int, int) ../../gdb/solib.c:993
#12 0x55f02487f1f8 in handle_solib_event() ../../gdb/solib.c:1399
#13 0x55f0227df91f in bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const&, bpstat*) ../../gdb/breakpoint.c:5962
#14 0x55f023944fa8 in handle_signal_stop ../../gdb/infrun.c:7130
#15 0x55f02393e2a1 in handle_inferior_event ../../gdb/infrun.c:6574
#16 0x55f0239279f2 in fetch_inferior_event() ../../gdb/infrun.c:4713
#17 0x55f023885fe3 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:42
#18 0x55f023af706e in handle_target_event ../../gdb/linux-nat.c:4449
#19 0x55f027c2d2f0 in handle_file_event ../../gdbsupport/event-loop.cc:551
#20 0x55f027c2e4ff in gdb_wait_for_event ../../gdbsupport/event-loop.cc:672
It happened because last_displayed_symtab_info of stack.c still contained
a reference to a symtab that was already freed in the 2nd run.
This fixes it by clearing last_displayed_symtab_info in the objfile
destructor, if it is pointing to that objfile.
Now setting of the 2nd breakpoint works:
(gdb) break 18
Breakpoint 2 at 0x555555555141: file /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/so-impl-ld.c, line 18.
(gdb)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32668
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The erratum mitigation support for the Cortex-A53 843419 erratum
inserts a new stub for every possible instance of the erratum. Since
each stub ends up inserting 4k of space into the binary, in order to
avoid perturbing the alignment of other potential erratum sequences we
can end up adding substantially more space than the distance to the
next long-branch stub that we've prepared for.
The problem is, fundamentally a phase ordering problem, but that's
easily resolvable by running the 843419 erratum pass first and then
creating the stub groups once that is done. In this way we take into
account the additional padding when forming the groups to ensure that
they remain within range.
If the target symbol for a stub was empty we would previously end up
using an anonymous stub name of the form ___veneer. To make things a
little clearer use the section symbol for the target section in this
case. We now end up with veneer symbols like __.text_veneer.
Adjusted the tests accordingly.
It is absurd to build this file when it's not possibly used. Move its
references to where other elf-*.* are and introduce a compiler define
(paralleling what gas uses, as having the same purpose) to isolate out
ELF-specific pieces in compress.c (which is where the references into
elf-properties.c are coming from).
Input sections would generally best retain their order from in the
input(s) or relocatable links. In particular the (odd) sorting of note
sections by alignment is entirely unnecessary there, and could potentially
even be harmful. Simply accumulate orphan sections in the order observed.
Of course this has an effect on section order, so a few testsuite
adjustments are necessary. The test for PR ld/27590 is being relaxed, as
it's no clear why sh_link fields would need to have exact expectations
when at the same time section numbers aren't matched. (Obviously the .rela
sections should match their corresponding data sections', but afaict this
cannot be [easily] expressed.) Xstormy16 XFAILs for a few tests can be
dropped as the sections of interest there are orphan ones, and hence now
are placed independent of the linker scripts unusual placing of .data
ahead of .text.
Do a few cleanups:
- declaring variables where they are used
- rename functions to be more precise
- add explicit comparison against nullptr or 0
- remove struct/union keywords
- remove or update outdated comments
Change-Id: I3f9e8604f79ee4d36cbe3d65079cb23051fcc703
Approved-By: Tom Tromey <tom@tromey.com>
Replace these 2 switches that have only one case with a single if
statement. It is highly unlikely that we'll ever need to check for
other values.
Change-Id: I6a48d4f27ba4d1d128aaa39d5f3d693a11e99fc9
Approved-By: Tom Tromey <tom@tromey.com>
The only remaining caller of xcoff_secnum_to_sections doesn't care about
the section index in the objfile, so remove that part.
Return the BFD section as the return value of the function, instead of
an output parameter. Remove the unnecessary default in the switch, to
avoid a "jump to label over variable initialization" warning.
Rename to xcoff_secnum_to_section (singular).
Change-Id: I464d8b0e1425ea2732b0d61355c5b0c66218122e
Approved-By: Tom Tromey <tom@tromey.com>
The symbol table content is only needed for the duration of
scan_xcoff_symtab, so it's not necessary to allocate it on the objfile
obstack. Switch to using a vector that is freed at the end of the
function.
Change-Id: Ib5acdea460969300a92816a3e71b7d82c80faebf
Approved-By: Tom Tromey <tom@tromey.com>
It is not necessary to save the symbol table content and number of
symbols in xcoff_symfile_info, because they are only needed for the
duration of scan_xcoff_symtab.
Move the reading of the symbol table content to scan_xcoff_symtab, and
keep everything as local variables.
Change-Id: I21e2b95a0b8df2255ba46904083658a4e8cb89f0
Approved-By: Tom Tromey <tom@tromey.com>
It is no longer necessary to get names of symbols. The only thing we
are interested in is the symbol to get the TOC offset, for which the
name doesn't matter.
Change-Id: I47e6009ed7600ea9c412fb25ed21a295cd0fec49
Approved-By: Tom Tromey <tom@tromey.com>
coffread.c is the last spot (that I know of) that incorrectly calls
perror_with_name when a BFD function fails. The issue here is that
perror_with_name examines errno, but BFD failures do not set this.
This patch changes this to use error and bfd_errmsg.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31041
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Previously, sframe_xlate_do_remember_state () relied exclusively on
last_fre (the last Frame Row Entry for the previous PC range block). At
the start of a function (before an advance in location), last_fre is
NULL. The intent of DW_CFA_remember_state, however, is to simply
snapshot the state of the call frame information at the time. In terms
of SFrame generation, this means that we should simply look at cur_fre
(the scratchpad FRE currently being built from initial CFI
instructions in the current context).
Remove the common-empty-1.s which assumed that .cfi_startproc,
immediately followed by a .cfi_remember_state is not present out in the
wild. Its best to not make such an assumption, as such a sequence is
valid CFI, FWIW.
Initial CFI are arch-specific, so add a new testcase for x86_64 to check
.cfi_remember_state handling for SFrame is sensible. While at at, also
add a new testcase for s390x.
Co-Authored-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
PR gas/33756
* gen-sframe.c (sframe_xlate_do_remember_state): Use cur_fre.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Adjust common-empty-1 test to
be repurposed as cfi-sframe-x86_64-pr33756. Add s390x testcase.
* gas/cfi-sframe/common-empty-1.d: Removed.
* gas/cfi-sframe/common-empty-1.s: Removed.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33756.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33756.s: New test.
* gas/cfi-sframe/cfi-sframe-s390x-pr33756.d: New test.
* gas/cfi-sframe/cfi-sframe-s390x-pr33756.s: New test.
Inspection shows that xcoff_symfile_info::min_lineno_offset and
xcoff_symfile_info::max_lineno_offset are never really used. Removing
this then shows that find_linenos doesn't do any useful work. So,
remove the fields and this function.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
On my Fedora 41 machine, a cross-hosted mingw build fails with:
../../binutils-gdb/bfd/bfdio.c:249:50: error: implicit declaration of function 'ARRAY_SIZE'; did you mean 'ARRAYSIZE'? [-Wimplicit-function-declaration]
Including libiberty.h in bfdio.c fixes the failure.
The last user of sym_fns::sym_read_linetable was xcoffread.c. Now
that the code there has been removed, this callback can be removed as
well. This slightly simplifies buildsym.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
sym_finish::sym_finish isn't needed by any existing code, so this
patch removes it.
Note that it should never be needed again. It's much cleaner, IMO,
for symbol readers to attach data to the objfile or per-BFD via the
registry. Then, any cleanup will be automatic.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
sym_fns::sym_new_init has long been weird. There's even a comment in
symfile.c saying this.
After some recent changes, nothing needs this any more. So, this
patch removes it entirely.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
xcoffread.c is no longer really using the buildsym code. This removes
the last call, which should not be needed, and then removes the
include.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This removes a lot of obviously dead code from xcoffread.c. There are
some unused macros and types. A few globals can be removed because
they are never assigned to or really used for anything.
The last new year procedure missed running autoreconf in gnulib/ and
sim/ to update the Makefile.in files (following the updates of the
corresponding Makefile.am files). I propose to make the script run
`autoreconf -v` to ensure we don't miss those anymore. It takes a bit
of time, but that script isn't run very frequently (I'd say more or less
once a year).
Change-Id: Iab64415cedac716632d6a1230ebb87cc3190f4e4
Approved-By: Tom Tromey <tom@tromey.com>
The unordered_dense library is now contained in the
gdbsupport/unordered_dense directory, update the exclusion entry
accordingly.
Change-Id: If82355b94b245099ab4c2b27c929639242e33988
Approved-By: Tom Tromey <tom@tromey.com>
