| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch is the result of running check-include-guards.py on the
current tree. Running it a second time causes no changes.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
Remove some includes reported as unused by clangd. Add some to files
that actually need it.
Change-Id: I01c61c174858c1ade5cb54fd7ee1f582b17c3363
|
|
Convert one use of htab_t, mapping (unrelocated) pc to call_site
objects, to `gdb::unordered_map<unrelocated_addr, call_site *>`.
Change-Id: I40a0903253a8589dbdcb75d52ad4d233931f6641
Approved-By: Tom Tromey <tom@tromey.com>
|
|
struct symtab *find_line_symtab (struct symtab *, int, int *, bool *);
The last parameter is bool* that when set will receive information
if the match was exact. This parameter is never used by any callsite
and can therefore be removed.
This will become:
symtab *find_line_symtab (symtab *sym_tab, int line, int *index);
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make the current program space references bubble up.
In collect_symtabs_from_filename, remove the calls to
set_current_program_space and just pass the relevant pspaces.
This appears safe to do, because nothing in the `collector` callback
cares about the current pspace.
Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This function is used by multiple stabs readers (even if not all), and
the comment in stabsread.h even acknowledges it. I believe that the
comment is incorrect in saying that the function should be in dbxread
because not everyone uses it. If any one reader other than dbx uses
it, the function should be in stabsread, in my opinion.
This commit makes also renames the function to stabs_end_psymtab since,
again, this is not specific to dbx/aout format.
struct symloc had to be moved because stabs_end_psymtab dereferences
symloc objects, so stabsread.c must be aware of the full struct.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The binary provided with bug 32165 [1] has 36139 ELF sections. GDB
crashes on it with (note that my GDB is build with -D_GLIBCXX_DEBUG=1:
$ ./gdb -nx -q --data-directory=data-directory ./vmlinux
Reading symbols from ./vmlinux...
(No debugging symbols found in ./vmlinux)
(gdb) info func
/usr/include/c++/14.2.1/debug/vector:508:
In function:
std::debug::vector<_Tp, _Allocator>::reference std::debug::vector<_Tp,
_Allocator>::operator[](size_type) [with _Tp = long unsigned int;
_Allocator = std::allocator<long unsigned int>; reference = long
unsigned int&; size_type = long unsigned int]
Error: attempt to subscript container with out-of-bounds index -29445, but
container only holds 36110 elements.
Objects involved in the operation:
sequence "this" @ 0x514000007340 {
type = std::debug::vector<unsigned long, std::allocator<unsigned long> >;
}
The crash occurs here:
#3 0x00007ffff5e334c3 in __GI_abort () at abort.c:79
#4 0x00007ffff689afc4 in __gnu_debug::_Error_formatter::_M_error (this=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:1320
#5 0x0000555561119a16 in std::__debug::vector<unsigned long, std::allocator<unsigned long> >::operator[] (this=0x514000007340, __n=18446744073709522171)
at /usr/include/c++/14.2.1/debug/vector:508
#6 0x0000555562e288e8 in minimal_symbol::value_address (this=0x5190000bb698, objfile=0x514000007240) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:517
#7 0x0000555562e5a131 in global_symbol_searcher::expand_symtabs (this=0x7ffff0f5c340, objfile=0x514000007240, preg=std::optional [no contained value])
at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4983
#8 0x0000555562e5d2ed in global_symbol_searcher::search (this=0x7ffff0f5c340) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5189
#9 0x0000555562e5ffa4 in symtab_symbol_info (quiet=false, exclude_minsyms=false, regexp=0x0, kind=FUNCTION_DOMAIN, t_regexp=0x0, from_tty=1)
at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5361
#10 0x0000555562e6131b in info_functions_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5525
That is, at this line of `minimal_symbol::value_address`, where
`objfile->section_offsets` is an `std::vector`:
return (CORE_ADDR (this->unrelocated_address ())
+ objfile->section_offsets[this->section_index ()]);
A section index of -29445 is suspicious. The minimal_symbol at play
here is:
(top-gdb) p m_name
$1 = 0x521001de10af "_sinittext"
So I restarted debugging, breaking on:
(top-gdb) b general_symbol_info::set_section_index if $_streq("_sinittext", m_name)
And I see that weird -29445 value:
(top-gdb) frame
#0 general_symbol_info::set_section_index (this=0x525000082390, idx=-29445) at /home/smarchi/src/binutils-gdb/gdb/symtab.h:611
611 { m_section = idx; }
But going up one frame, the section index is 36091:
(top-gdb) frame
#1 0x0000555562426526 in minimal_symbol_reader::record_full (this=0x7ffff0ead560, name="_sinittext", copy_name=false,
address=-2111475712, ms_type=mst_text, section=36091) at /home/smarchi/src/binutils-gdb/gdb/minsyms.c:1228
1228 msymbol->set_section_index (section);
It seems like the problem is just that the type used for the section
index (short) is not big enough. Change from short to int. If somebody
insists, we could even go long long / int64_t, but I doubt it's
necessary.
With that fixed, I get:
(gdb) info func
All defined functions:
Non-debugging symbols:
0xffffffff81000000 _stext
0xffffffff82257000 _sinittext
0xffffffff822b4ebb _einittext
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=32165
Change-Id: Icb1c3de9474ff5adef7e0bbbf5e0b67b279dee04
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
A user noticed that when an Ada program (including the runtime) is
compiled with -flto, then "catch exception" does not work -- even
though setting the equivalent breakpoint by hand does work.
Looking into this, it turns out that GCC puts the exception functions
from the Ada runtime into a CU that uses the C language, not Ada.
Then, when trying to look up the relevant symbol,
lookup_name_info::search_name_hash uses the "verbatim" form of the
symbol name (like "<__gnat_debug_raise_exception>") rather than the
"<>"-less form, causing the symbol not to be found.
This patch fixes the problem in two steps.
First, lookup_name_info::search_name_hash is changed to use the same
hack that language_defn::get_symbol_name_matcher uses. That is, when
the current language is Ada, verbatim-mode lookups are special-cased.
(This is a bit unfortunate; perhaps a better long term approach would
be to promote verbatim mode to a fundamental mode of
lookup_name_info.)
Second, although the above fixes the problem in the Ada language mode,
the code still fails in other languages. However, due to the way
these lookups are coded in ada-lang.c, I think it makes sense to
temporarily set the current language to Ada in
create_ada_exception_catchpoint.
Tested on x86-64 Fedora 38.
A new test case that mimics the -flto scenario is included.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
This is a simple find / replace from "struct bound_minimal_symbol" to
"bound_minimal_symbol", to make things shorter and more consisten
througout. In some cases, move variable declarations where first used.
Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The call site hash table is the last hash table using obstack
allocation. In one large (non-public) test case, these hash tables
take a substiantial amount of memory. Some of this memory is wasted
-- whenever the hash table is resized, the old table is not freed.
This patch fixes the problem by changing this hash table to be
heap-allocated. This means that resizing will no longer "leak"
memory.
|
|
It seemed cleaner to me for compunit_symtab to have a
forget_cached_source_info method, then for the objfile to know how to
do this.
|
|
This rearranges symtab so that the private members appear at the end,
and then adds the "private" keyword.
|
|
This renames symtab::fullname to m_fullname and adds new accessor
methods.
|
|
This moves search_symbol_list to symtab.c and exports it. It will be
useful in a later patch.
|
|
This patch renames is_cplus_template_function to is_template_function.
There is nothing C++-specific about this code, and the code in the
DWARF reader that creates these objects is not C++-specific. In fact
this may already be used by Rust (though I didn't check).
|
|
This patch renames global_symbol_searcher::filenames and makes it
private, adding a new method to append a filename to the vector. This
also cleans up memory management here, removing an alloca from rbreak,
and removing a somewhat ugly SCOPE_EXIT from the Python code, in favor
of having global_symbol_searcher manage the memory itself.
Regression tested on x86-64 Fedora 38.
|
|
This patch makes allocate_on_obstack a little bit safer, by enforcing
the rule that objects allocated on an obstack must have a trivial
destructor.
The static assert is done in a method -- doing it inside the class
itself won't work because the class is incomplete at that point.
|
|
I noticed that "info locals" on a certain large Ada program was very
slow. I tracked this down to ada_get_tsd_type expanding nearly every
CU in the program.
This patch fixes the problem by changing this code to use the more
efficient lookup_transparent_type which, unlike the Ada-specific
lookup functions, does not try to find all matching instances.
Note that I first tried fixing this by changing ada_find_any_type, but
this did not work -- I may revisit this approach at some later date.
Also note that the copyright dates on the test files are set that way
because I copied them from another test.
New in v2: the new test failed on the Linaro regression tester.
Looking at the logs, it seems that gdb was picking up a 'value' from
libgnat:
$1 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value>
This version renames the local variable in an attempt to work around
this.
v3: In v2, while trying to reproduce the problem locally, I
accidentally forgot to commit one of the changes.
|
|
We currently pass frames to function by value, as `frame_info_ptr`.
This is somewhat expensive:
- the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
by value
- the constructors and destructor link/unlink the object in the global
`frame_info_ptr::frame_list` list. This is an `intrusive_list`, so
it's not so bad: it's just assigning a few points, there's no memory
allocation as if it was `std::list`, but still it's useless to do
that over and over.
As suggested by Tom Tromey, change many function signatures to accept
`const frame_info_ptr &` instead of `frame_info_ptr`.
Some functions reassign their `frame_info_ptr` parameter, like:
void
the_func (frame_info_ptr frame)
{
for (; frame != nullptr; frame = get_prev_frame (frame))
{
...
}
}
I wondered what to do about them, do I leave them as-is or change them
(and need to introduce a separate local variable that can be
re-assigned). I opted for the later for consistency. It might not be
clear why some functions take `const frame_info_ptr &` while others take
`frame_info_ptr`. Also, if a function took a `frame_info_ptr` because
it did re-assign its parameter, I doubt that we would think to change it
to `const frame_info_ptr &` should the implementation change such that
it doesn't need to take `frame_info_ptr` anymore. It seems better to
have a simple rule and apply it everywhere.
Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Make the current_program_space reference bubble up one level.
Remove one unnecessary declaration of clear_solib.
Change-Id: I234e2c8c0b71713364fc7b76cee2bee2b026bd6d
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The constant SEARCH_ALL conflicts with a define in a Windows header.
This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the
conflict.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31307
|
|
Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the
sym-domains.def file has been introduced, and requires the user to
define the DOMAIN(x) macro.
On older systems (centos-7 with glibc-2.17 for example), this DOMAIN
macro conflicts with another macro defined in /usr/include/math.h.
Fix this conflict by changing sym-domains.def to use a macro named
SYM_DOMAIN instead of DOMAIN.
Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Nothing calls the variant of symbol_matches_domain that accepts a
domain_enum for searching, so this patch removes it and the
corresponding symbol::matches.
|
|
This changes lookup_symbol and associated APIs to accept
domain_search_flags rather than a domain_enum.
Note that this introduces some new constants to Python and Guile. I
chose to break out the documentation patch for this, because the
internals here do not change until a later patch, and it seemed
simpler to patch the docs just once, rather than twice.
|
|
This changes quick_symbol_functions::lookup_global_symbol_language to
accept domain_search_flags rather than just a domain_enum, and fixes
up the fallout.
To avoid introducing any regressions, any code passing VAR_DOMAIN now
uses SEARCH_VFT.
That is, no visible changes should result from this patch. However,
it sets the stage to refine some searches later on.
|
|
The Python and Guile code exposed the internal domain constants both
as attributes of symbols and as values to pass to lookup functions.
Now, perfect backward compatibility here can't be achieved: some
symbols are going to have domain changes by the end of this series.
However, it seemed to me that we can preserve lookups using the basic
domain values.
This patch implements this by exporting the "or"-able search constants
with an extra bit set. Then it introduces some functions to convert
such constants to domain_search_flags. This will be used by the
Python and Guile code, so that both old- and new-style lookups will
work properly; and while preserving the idea that the domain constants
can be compared to a symbol's domain.
|
|
This patch changes gdb to replace search_domain with
domain_search_flags everywhere. search_domain is removed.
|
|
This adds a new flag enum type, domain_search_flags, which is the flag
version of domain_enum. Nothing uses this yet, but the goal here is
to have all symbol searches and lookups use these flags. The new
names are chosen to exactly parallel domain_enum.
|
|
Future patches will change and reuse the names from domain_enum. This
patch makes this less error-prone by having a single point to define
these names, using the typical gdb ".def" file.
|
|
Thi simplifies symbol_to_info_string, removing the 'kind' parameter
and instead having it use the symbol's domain.
|
|
NR_DOMAINS is only used for a static assert, but we no longer need it
now. If we add too many constants to this enum, GCC will warn about
the bitfield overflow:
error: ‘symbol::m_domain’ is too small to hold all values of ‘enum domain_enum’
|
|
Remove SYMBOL_BLOCK_OPS, SYMBOL_COMPUTED_OPS and SYMBOL_REGISTER_OPS, in
favor of methods on struct symbol. More changes could be done here to
improve the design and make things safer, but I just wanted to do a
straightforward change to remove the macros for now.
Change-Id: I27adb74a28ea3c0dc9a85c2953413437cd95ad21
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on
the ppc backend), there are failures in gdb.reverse/solib-precsave.exp and
gdb.reverse/solib-reverse.exp.
The failure happens around the following code:
38 b[1] = shr2(17); /* middle part two */
40 b[0] = 6; b[1] = 9; /* generic statement, end part two */
42 shr1 ("message 1\n"); /* shr1 one */
Normal execution:
- step from line 38 will land on line 40.
- step from line 40 will land on line 42.
Reverse execution:
- step from line 42 will land on line 40.
- step from line 40 will land on line 40.
- step from line 40 will land on line 38.
The problem here is that line 40 contains two contiguous but distinct
PC ranges in the line table, like so:
Line 40 - [0x7ec ~ 0x7f4]
Line 40 - [0x7f4 ~ 0x7fc]
The two distinct ranges are generated because GCC started outputting source
column information, which GDB doesn't take into account at the moment.
When stepping forward from line 40, we skip both of these ranges and land on
line 42. When stepping backward from line 42, we stop at the start PC of the
second (or first, going backwards) range of line 40.
Since we've reached ecs->event_thread->control.step_range_start, we stop
stepping backwards.
The above issues were fixed by introducing a new function that looks for
adjacent PC ranges for the same line, until we notice a line change. Then
we take that as the start PC of the range. The new start PC for the range
is used for the control.step_range_start when setting up a step range.
The test case gdb.reverse/map-to-same-line.exp is added to test the fix
for the above reverse step issues.
Patch has been tested on PowerPC, X86 and AArch64 with no regressions.
|
|
This commit adds a mechanism for GDB to detect the linetable opcode
DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate
that a certain instruction marks the point where the frame is destroyed.
While the standard allows for multiple points marked with epilogue_begin
in the same function, for performance reasons, the function that
searches for the epilogue address will only find the last address that
sets this flag for a given block.
This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to
use the epilogue begin directly, and only if an epilogue can't be found
will it attempt heuristics based on the current instruction.
Finally, this commit also changes the dwarf assembler to be able to emit
epilogue-begin instructions, to make it easier to test this patch
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The previous patch fixed the immediate performance problem with Ada
name matching, by having a subset of matches call
expand_symtabs_matching rather than expand_matching_symbols. However,
it seemed to me that expand_matching_symbols should not be needed at
all.
To achieve this, this patch changes ada_lookup_name_info::split_name
to use the decoded name, rather than the encoded name. In order to
make this work correctly, a new decoded form is used: one that does
not decode operators (this is already done) and also does not decode
wide characters. The latter change is done so that changes to the Ada
source charset don't affect the DWARF index.
With this in place, we can change ada-lang.c to always use
expand_symtabs_matching rather than expand_matching_symbols.
|
|
C++17 makes the second parameter to static_assert optional, so we can
remove gdb_static_assert now.
|
|
Given that GDB now requires a C++17, replace all uses of
gdb::string_view with std::string_view.
This change has mostly been done automatically:
- gdb::string_view -> std::string_view
- #include "gdbsupport/gdb_string_view.h" -> #include <string_view>
One things which got brought up during review is that gdb::stging_view
does support being built from "nullptr" while std::sting_view does not.
Two places are manually adjusted to account for this difference:
gdb/tui/tui-io.c:tui_getc_1 and
gdbsupport/format.h:format_piece::format_piece.
The above automatic change transformed
"gdb::to_string (const gdb::string_view &)" into
"gdb::to_string (const std::string_view &)". The various direct users
of this function are now explicitly including
"gdbsupport/gdb_string_view.h". A later patch will remove the users of
gdb::to_string.
The implementation and tests of gdb::string_view are unchanged, they will
be removed in a following patch.
Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Since GDB now requires C++17, we don't need the internally maintained
gdb::optional implementation. This patch does the following replacing:
- gdb::optional -> std::optional
- gdb::in_place -> std::in_place
- #include "gdbsupport/gdb_optional.h" -> #include <optional>
This change has mostly been done automatically. One exception is
gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
already lives in the gdb namespace.
Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
get_symbol_address is only used symbol::value_address, make it a private
helper method.
Change-Id: I318ddcfcf1269d95045b8efe9137812df9c5113c
Approved-By: Tom Tromey <tom@tromey.com>
|
|
get_msymbol_address is only used in minimal_symbol::value_address. Make
it a private helper method.
Change-Id: I3f30e1b9d89ace6682fb08a7ebb91746db0ccf0f
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch changes class symbol_search to store a block_enum rather
than an int.
Regression tested on x86-64 Fedora 38.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This renames split_style::DOT, to avoid name clashes when building gdb
with an old version of Bison (2.3, the version available on macOS).
In particular the error looks like:
./split-name.h:34:3: error: expected identifier
DOT,
^
m2-exp.c:163:13: note: expanded from macro 'DOT'
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30286
|
|
This adds symbol::matches, a wrapper for symbol_matches_domain. Most
places calling symbol_matches_domain can call this method instead,
which is a bit less wordy and also (IMO) clearer.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This commit fixes a bug mentioned by Florian Weimer during the
libpthread/ld.so load order discussion from 2021. Florian provided
instructions for reproducing the bug here:
https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html
That particular test does some interesting things involving forks,
threads, and thread local storage. Fortunately, none of that is
needed to reproduce the problem.
I've made a new test case (which is now found in a separate commit)
contained in the files gdb.base/add-symbol-file-attach.{c,exp}. The
.c file is fairly simple as is the recipe for reproducing the problem.
After separately starting the test case and noting the process id,
start gdb (w/ no arguments), and do the following to reproduce the
assertion failure - for this run, the process id of the separately
started add-symbol-file-attach process is 4103218:
(gdb) add-symbol-file add-symbol-file-attach
add symbol table from file "add-symbol-file-attach"
(y or n) y
Reading symbols from add-symbol-file-attach...
(gdb) attach 4103218
Attaching to process 4103218
Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y
Reading symbols from /tmp/add-symbol-file-attach...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f502130bf27 in pause () from /lib64/libc.so.6
(gdb) p foo
symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*,
const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
The add-symbol-file command causes the symbols to be loaded without
the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being
set. This, in turn, causes the "maybe_copied" flag to be set for
the global symbol (named "foo" in the provided test case).
The attach command will cause another objfile to be created, but
it will reuse the symtabs from the objfile created by add-symbol-file,
leading to a situation in which the OBJFILE_MAINLINE flag will be set
for the new (attach-created) objfile, however the "maybe_copied"
flag will still be set for the global symbol. Had it been loaded
anew, this flag would not be set due to OBJFILE_MAINLINE being set
for the objfile.
At present, minimal_symbol::value_address looks like this:
CORE_ADDR
minimal_symbol::value_address (objfile *objfile) const
{
if (this->maybe_copied (objfile))
return get_msymbol_address (objfile, this);
else
return (CORE_ADDR (this->unrelocated_address ())
+ objfile->section_offsets[this->section_index ()]);
}
So, we can now see the problem: When the "maybe_copied" flag is set,
get_msymbol_address() will be called. However, get_msymbol_address()
assumes that it won't be called with the OBF_MAINLINE flag set for
the objfile in question. It, in fact, contains an assert() which
makes sure that this is the case:
gdb_assert ((objf->flags & OBJF_MAINLINE) == 0);
(If this assert is removed, then get_msymbol_address() recurses
infinitely for the case under consideration.)
So, the problem here is that the maybe_copied flag is set for the
symbol AND the OBJF_MAINLINE flag is set for the objfile. As noted
earlier, this happens due to add-symbol-file being used; this causes
the maybe_copied flag to be set. Later, when the attach is performed,
OBJF_MAINLINE will be set for that objfile, leading to this
unfortunate situation.
My first cut at a solution involved adjusting the
MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the
method noted above) to include a test of the OBJFILE_MAINLINE flag.
However, Simon Marchi, in his review of my patch, suggested a better
solution. Simon observed that the 'maybe_copied' flag is (was, after
this commit) being set/initialized in record_minimal_symbol() using
using the objfile in the context in which the symbol was created.
Simon further observed:
Today, a single copy is created, as symtabs are shared between
objfiles. This means that everything that we store into a symbol
must be independent of any objfile. However, the value of the
maybe_copied field is dependent on the objfile in the context of
which the symbol was created. Meaning that when the symbol is
re-used in the context of another objfile, the maybe_copied value is
not right in the context of that objfile.
So I think it means there isn't a single "is this symbol maybe
copied" value, but instead "is this symbol maybe copied, in the
context of this given objfile". And the answer is yes or no,
depending on whether the objfile is mainline. So maybe_copied
should become a method that takes an objfile and returns an answer
based on that.
Simon's full review can be found here:
https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html
Simon also provided a patch which implements this suggestion. The
current patch is mostly his work, though I did make some adjustments
during a rebase in addition to making some changes to account for a
concern from Tom Tromey.
During his review of the v3 series, Tom noted, "The old approach was
specific to ELF, while the new approach will be used by any object
format." Tom further observed, "...it seems like it could result in an
incorrect evaluation in some scenario." This seemed plausible to me,
so I introduced the flag 'object_format_has_copy_relocs' to struct
objfile. It is set at the end of elf_symfile_read() in elfread.c.
The minimal_symbol::maybe_copied method tests this new flag, forcing
this method to return false when the flag is not set. If we find that
other object file formats use the same copy reloc mechanism as ELF,
then 'object_format_has_copy_relocs' should be set for objfiles using
those formats.
Lastly, I'll note that this is a strange use case. It's far more
common to either let gdb figure out which file to load by itself when
attaching, i.e.
(gdb) attach 4104360
Attaching to process 4104360
Reading symbols from /tmp/add-symbol-file-attach...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
(gdb) p foo
$1 = 42
...or to use the "file" command prior to the attach, like this:
(gdb) file add-symbol-file-attach
Reading symbols from add-symbol-file-attach...
(gdb) attach 4104360
Attaching to program: /tmp/add-symbol-file-attach, process 4104360
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
Both of these more common scenarios work perfectly fine; using
"add-symbol-file" to load the program to which you will attach
isn't recommended as a normal use case. That said, it's bad for
gdb to assert, hence this fix.
Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca>
Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Approved-by: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
|
|
I forgot to convert struct linetable_entry to use the "unrelocated"
(as opposed to "raw") terminology. This patch corrects the oversight.
|
|
enum address_class has a stale comment referring to
MSYMBOL_VALUE_RAW_ADDRESS, which no longer exists. This patch updates
the comment.
|
|
unrelocated_addr is currently defined in symtab.h, but in order to
avoid having to include that in more places, I wanted to move the type
elsewhere. I considered defs.h, but it seemed reasonable to have it
next to CORE_ADDR, which is what this patch does.
|
|
This adds a new callback to symbol_block_ops. This callback lets a
LOC_BLOCK symbol implement its own function to find the underlying
block.
|
|
This moves the definition of symbol::value_block outside of the class.
A subsequent patch will change this method to use SYMBOL_BLOCK_OPS,
and it seemed simplest to move this method out-of-line, and cleaner to
do this as a separate change.
|
