| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When GDB opens a core file, in 'core_target::build_file_mappings ()',
we collection information about the files that are mapped into the
core file, specifically, the build-id and the DT_SONAME attribute for
the file, which will be set for some shared libraries.
We then cache the DT_SONAME to build-id information on the core file
bfd object in the function set_cbfd_soname_build_id.
Later, when we are loading the shared libraries for the core file, we
can use the library's file name to look in the DT_SONAME to build-id
map, and, if we find a matching entry, we can use the build-id to
validate that we are loading the correct shared library.
This works OK, but has some limitations: not every shared library will
have a DT_SONAME attribute. Though it is good practice to add such an
attribute, it's not required. A library without this attribute will
not have its build-id checked, which can lead to GDB loading the wrong
shared library.
What I want to do in this commit is to improve GDB's ability to use
the build-ids extracted in core_target::build_file_mappings to both
validate the shared libraries being loaded, and then to use these
build-ids to potentially find (via debuginfod) the shared library.
To do this I propose making the following changes to GDB:
(1) Rather than just recording the DT_SONAME to build-id mapping in
set_cbfd_soname_build_id, we should also record, the full filename to
build-id mapping, and also the memory ranges to build-id mapping for
every memory range covered by every mapped file.
(2) Add a new callback solib_ops::find_solib_addr. This callback
takes a solib object and returns an (optional) address within the
inferior that is part of this library. We can use this address to
find a mapped file using the stored memory ranges which will increase
the cases in which a match can be found.
(3) Move the mapped file record keeping out of solib.c and into
corelow.c. Future commits will make use of this information from
other parts of GDB. This information was never solib specific, it
lived in the solib.c file because that was the only user of the data,
but really, the data is all about the core file, and should be stored
in core_target, other parts of GDB can then query this data as needed.
Now, when we load a shared library for a core file, we do the
following lookups:
1. Is the exact filename of the shared library found in the filename
to build-id map? If so then use this build-id for validation.
2. Find an address within the shared library using ::find_solib_addr
and then look for an entry in the mapped address to build-id map.
If an entry is found then use this build-id.
3. Finally, look in the soname to build-id map. If an entry is
found then use this build-id.
The addition of step #2 here means that GDB is now far more likely to
find a suitable build-id for a shared library. Having acquired a
build-id the existing code for using debuginfod to lookup a shared
library object can trigger more often.
On top of this, we also create a build-id to filename map. This is
useful as often a shared library is implemented as a symbolic link to
the actual shared library file. The mapped file information is stored
based on the actual, real file name, while the shared library
information holds the original symbolic link file name.
If when loading the shared library, we find the symbolic link has
disappeared, we can use the build-id to file name map to check if the
actual file is still around, if it is (and if the build-id matches)
then we can fall back to use that file. This is another way in which
we can slightly increase the chances that GDB will find the required
files when loading a core file.
Adding all of the above required pretty much a full rewrite of the
existing set_cbfd_soname_build_id function and the corresponding
get_cbfd_soname_build_id function, so I have taken the opportunity to
move the information caching out of solib.c and into corelow.c where
it is now accessed through the function core_target_find_mapped_file.
At this point the benefit of this move is not entirely obvious, though
I don't think the new location is significantly worse than where it
was originally. The benefit though is that the cached information is
no longer tied to the shared library loading code.
I already have a second set of patches (not in this series) that make
use of this caching from elsewhere in GDB. I've not included those
patches in this series as this series is already pretty big, but even
if those follow up patches don't arrive, I think the new location is
just as good as the original location.
Rather that caching the information within the core file BFD via the
registry mechanism, the information used for the mapped file lookup is
now stored within the core_file target directly.
|
|
In svr4_handle_solib_event I noticed:
...
catch (const gdb_exception_error)
...
This seems to be the only place were we do this, elsewhere we have:
...
catch (const gdb_exception_error &)
...
I suppose the intent of adding '&' is to avoid a copy. I'm not sure if it's
necessary given that it's an unnamed const parameter, but I suppose it can't
hurt either.
Add the '&' here as well.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
>From what I can see, lookup_minimal_symbol doesn't have any dependencies
on the global current state other than the single reference to
current_program_space. Add a program_space parameter and make that
current_program_space reference bubble up one level.
Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Most calls to lookup_minimal_symbol don't pass a value for sfile and
objf. Make these parameters optional (have a default value of
nullptr). And since passing a value to `objf` is much more common than
passing a value to `sfile`, swap the order so `objf` comes first, to
avoid having to pass a nullptr value to `sfile` when wanting to pass a
value to `objf`.
Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@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>
|
|
Now that the nto port is removed, this is unused.
Change-Id: I86565310cdbcde17a837eb10585cdd153f4f03d8
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Rename to m_pspace, add getter. An objfile's pspace never changes, so
no setter is necessary.
Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626
|
|
Remove some includes reported as unused by clangd. Add some includes in
other files that were previously relying on the transitive include.
Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
|
|
Replace the global function address_in_mem_range with the member
function mem_range::contains. The implementation of the function
doesn't change.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Move the declarations out of defs.h, and the implementations out of
findvar.c.
I opted for a new file, because this functionality of converting
integers to bytes and vice-versa seems a bit to generic to live in
findvar.c.
Change-Id: I524858fca33901ee2150c582bac16042148d2251
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
|
|
I don't like the name `target_so_ops`, because:
- The name `target` is so overloaded, and in this case it's not even
related to target_ops or anything else called "target".
- We do have an implementation that actually fetches solibs from the
target (solib_target_so_op in solib-target.c), so it's confusing for
the "base class" to be called target_something as well.
Rename to solib_ops.
Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f
Approved-By: Tom Tromey <tom@tromey.com>
|
|
`struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f
("gdb: rename struct so_list to shobj")). In hindsight, `solib` would
have been a better name. We have solib.c, the implementations in
solib-*.c, many functions with solib in their name, the solib_loaded /
solib_unloaded observables, etc.
Rename shobj to solib.
Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d
Approved-By: Tom Tromey <tom@tromey.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.
|
|
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>
|
|
gdb::make_unique is a wrapper around std::make_unique when compiled with
C++17. Now that C++17 is required, use std::make_unique directly in the
codebase, and remove gdb::make_unique.
Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net
|
|
Remove get_current_regcache, inlining the call to get_thread_regcache in
callers. When possible, pass the right thread_info object known from
the local context. Otherwise, fall back to passing `inferior_thread ()`.
This makes the reference to global context bubble up one level, a small
step towards the long term goal of reducing the number of references to
global context (or rather, moving those references as close as possible
to the top of the call tree).
No behavior change expected.
Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6
|
|
While looking at the regcache code, I noticed that the address space
(passed to regcache when constructing it, and available through
regcache::aspace) wasn't relevant for the regcache itself. Callers of
regcache::aspace use that method because it appears to be a convenient
way of getting the address space for a thread, if you already have the
regcache. But there is always another way to get the address space, as
the callers pretty much always know which thread they are dealing with.
The regcache code itself doesn't use the address space.
This patch removes anything related to address_space from the regcache
code, and updates callers to get it from the thread in context. This
removes a bit of unnecessary complexity from the regcache code.
The current get_thread_arch_regcache function gets an address_space for
the given thread using the target_thread_address_space function (which
calls the target_ops::thread_address_space method). This suggest that
there might have been the intention of supporting per-thread address
spaces. But digging through the history, I did not find any such case.
Maybe this method was just added because we needed a way to get an
address space from a ptid (because constructing a regcache required an
address space), and this seemed like the right way to do it, I don't
know.
The only implementations of thread_address_space and
process_stratum_target::thread_address_space and
linux_nat_target::thread_address_space, which essentially just return
the inferior's address space. And thread_address_space is only used in
the current get_thread_arch_regcache, which gets removed. So, I think
that the thread_address_space target method can be removed, and we can
assume that it's fine to use the inferior's address space everywhere.
Callers of regcache::aspace are updated to get the address space from
the relevant inferior, either using some context they already know
about, or in last resort using the current global context.
So, to summarize:
- remove everything in regcache related to address spaces
- in particular, remove get_thread_arch_regcache, and rename
get_thread_arch_aspace_regcache to get_thread_arch_regcache
- remove target_ops::thread_address_space, and
target_thread_address_space
- adjust all users of regcache::aspace to get the address space another
way
Change-Id: I04fd41b22c83fe486522af7851c75bcfb31c88c7
|
|
Now that so_list lists are implemented using intrusive_list, it doesn't
really make sense for the element type to be named "_list". Rename to
just `struct shobj` (`struct so` was deemed to be not greppable enough).
Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Remove this function, replace it with deleting the so_list in callers.
Change-Id: Idbd0cb84674ade1d8e17af471550dbd388264f60
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Replace the hand-made linked list implementation with intrusive_list,
simplying management of list items.
Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Change these two fields, simplifying memory management and copying.
Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Make it a unique_ptr, so it gets automatically deleted when the so_list
is deleted.
Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
A subsequent patch makes use of non-trivial types in struct so_list.
This trips on the fact that svr4_copy_library_list uses memcpy to copy
so_list objects:
so_list *newobj = new so_list;
memcpy (newobj, src, sizeof (struct so_list));
solib-svr4 maintains lists of so_list objects in its own internal data
structures. When requested to return a list of so_list objects (through
target_so_ops::current_sos), it duplicates the internal so_list lists,
using memcpy. When changing so_list to make it non-trivial, we would
need to replace this use of memcpy somehow. That would mean making
so_list copyable, with all the complexity that entails, just to satisfy
this internal usage of solib-svr4 (and solib-rocm, which does the same).
Change solib-svr4 to use its own data type for its internal lists. The
use of so_list is a bit overkill anyway, as most fields of so_list are
irrelevant for this internal use.
- Introduce svr4_so, which contains just an std::string for the name
and a unique_ptr for the lm_info.
- Change the internal so_list lists to be std::vector<svr4_so>. Vector
seems like a good choice for this, we don't need to insert/remove
elements in the middle of these internal lists.
- Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as
everything is managed automatically now.
- Replace svr4_copy_library_list (which duplicated internal lists in
order to return them to the core) with so_list_from_svr4_sos, which
creates an so_list list from a vector of svr4_so.
- Generalize svr4_same a bit, because find_debug_base_for_solib now
needs to compare an so_list and an svr4_so to see if they are the
same.
Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Now that the lm_info class hierarchy has a virtual destructor and
therefore a vtable, use checked_static_cast instead of C-style cases to
ensure (when building in dev mode) that we're casting to the right kind
of lm_info.
Change-Id: I9a99b7d6aa9a44edbe76377d57a7008cfb75a744
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
target_so_ops::free_so is responsible for freeing the specific lm_info
object. All implementations basically just call delete. Remove that
method, make the destructor of lm_info virtual, and call delete directly
from the free_so function. Make the sub-classes final, just because
it's good practice.
Change-Id: Iee1fd4861c75034a9e41a656add8ed8dfd8964ee
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Initialize all fields in the class declaration, change allocations to
use "new", change deallocations to use "delete". This is needed by a
subsequent patches that use C++ stuff in so_list.
Change-Id: I4b140d9f1ec9ff809554a056f76e3eb2b9e23222
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
A subsequent patch changes so_list to be linked using
intrusive_list. Iterating an intrusive_list yields some references to
the list elements. Convert some functions accepting so_list objects to
take references, to make things easier and more natural. Add const
where possible and convenient.
Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
The clear_solib is implicitly meant to clear the resources associated to
the current program space (that's what the solib implementations that
actually support multi-program-space / multi-inferior do). Make that
explicit by adding a program_space parameter and pass down
current_program_space in call sites. The implementation of the
clear_solib callbacks is fairly simple, I don't think any of them rely
on global state other than accessing current_program_space.
Change-Id: I8d0cc4db7b4f8db8d7452879c0c62db03269bf46
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
This function is just a wrapper around the current inferior's gdbarch.
I find that having that wrapper just obscures where the arch is coming
from, and that it's often used as "I don't know which arch to use so
I'll use this magical target_gdbarch function that gets me an arch" when
the arch should in fact come from something in the context (a thread,
objfile, symbol, etc). I think that removing it and inlining
`current_inferior ()->arch ()` everywhere will make it a bit clearer
where that arch comes from and will trigger people into reflecting
whether this is the right place to get the arch or not.
Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I'm starting to work on these files, I thought it would be a good time
to remove unused imports. These were identified by
include-what-you-use. Tested by rebuilding.
Change-Id: I3eaf3fa0ea3506c7ecfbc8ecff5031433b1dadb8
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
These were renamed from bfd_read and bfd_write back in 2001 when they
lost an unnecessary parameter. Rename them back, and get rid of a few
casts that are only needed without prototyped functions (K&R C).
|
|
I noticed that target_close is only called in two places:
solib-svr4.c, and target_ops_ref_policy::decref.
This patch fixes the former by changing target_bfd_reopen to return a
target_ops_up and then fixing the sole caller. Then it removes
target_close by inlining its body into the decref method.
The advantage of this approach is that targets are now automatically
managed.
Regression tested on x86-64 Fedora 38.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Fix grammar in some comments and docs:
- machines that doesn't -> machines that don't
- its a -> it's a
- its the -> it's the
- if does its not -> if it does it's not
- one more instructions if doesn't match ->
one more instruction if it doesn't match
- it's own -> its own
- it's first -> its first
- it's pointer -> its pointer
I also came across "it's performance" in gdb/stubs/*-stub.c in the HP public
domain notice, I've left that alone.
Tested on x86_64-linux.
|
|
Fix a few typos:
- implemention -> implementation
- convertion(s) -> conversion(s)
- backlashes -> backslashes
- signoring -> ignoring
- (un)ambigious -> (un)ambiguous
- occured -> occurred
- hidding -> hiding
- temporarilly -> temporarily
- immediatelly -> immediately
- sillyness -> silliness
- similiar -> similar
- porkuser -> pokeuser
- thats -> that
- alway -> always
- supercede -> supersede
- accomodate -> accommodate
- aquire -> acquire
- priveleged -> privileged
- priviliged -> privileged
- priviledges -> privileges
- privilige -> privilege
- recieve -> receive
- (p)refered -> (p)referred
- succesfully -> successfully
- successfuly -> successfully
- responsability -> responsibility
- wether -> whether
- wich -> which
- disasbleable -> disableable
- descriminant -> discriminant
- construcstor -> constructor
- underlaying -> underlying
- underyling -> underlying
- structureal -> structural
- appearences -> appearances
- terciarily -> tertiarily
- resgisters -> registers
- reacheable -> reachable
- likelyhood -> likelihood
- intepreter -> interpreter
- disassemly -> disassembly
- covnersion -> conversion
- conviently -> conveniently
- atttribute -> attribute
- struction -> struct
- resonable -> reasonable
- popupated -> populated
- namespaxe -> namespace
- intialize -> initialize
- identifer(s) -> identifier(s)
- expection -> exception
- exectuted -> executed
- dungerous -> dangerous
- dissapear -> disappear
- completly -> completely
- (inter)changable -> (inter)changeable
- beakpoint -> breakpoint
- automativ -> automatic
- alocating -> allocating
- agressive -> aggressive
- writting -> writing
- reguires -> requires
- registed -> registered
- recuding -> reducing
- opeartor -> operator
- ommitted -> omitted
- modifing -> modifying
- intances -> instances
- imbedded -> embedded
- gdbaarch -> gdbarch
- exection -> execution
- direcive -> directive
- demanged -> demangled
- decidely -> decidedly
- argments -> arguments
- agrument -> argument
- amespace -> namespace
- targtet -> target
- supress(ed) -> suppress(ed)
- startum -> stratum
- squence -> sequence
- prompty -> prompt
- overlow -> overflow
- memember -> member
- languge -> language
- geneate -> generate
- funcion -> function
- exising -> existing
- dinking -> syncing
- destroh -> destroy
- clenaed -> cleaned
- changep -> changedp (name of variable)
- arround -> around
- aproach -> approach
- whould -> would
- symobl -> symbol
- recuse -> recurse
- outter -> outer
- freeds -> frees
- contex -> context
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Remove the breakpoint_pointer_iterator layer. Adjust all users of
all_breakpoints and all_tracepoints to use references instead of
pointers.
Change-Id: I376826f812117cee1e6b199c384a10376973af5d
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
Remove the bp_location_pointer_iterator layer. Adjust all users of
breakpoint::locations to use references instead of pointers.
Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
This changes gdb_bfd_lookup_symbol to use a function_view. This
simplifies the code a little bit.
|
|
Replace spaces with tabs in a bunch of places.
Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
|
|
In ROCm-GDB, we install an solib provider for the GPU code objects on
top of the svr4 provider for the host, in order to add solibs
representing the GPU code objects to the solib list containing the host
process' shared libraries. We override the target_so_ops::handle_event
function pointer with our own, in which we call svr4_so_ops.handle_event
(which contains svr4_handle_solib_event) manually. When the host
(un)loads a library, the ROCm part of handle_event is a no-op. When the
GPU (un)loads a code object, we want the host side (svr4) to be a no-op.
The problem is that when handle_event is called because of a GPU event,
svr4_handle_solib_event gets called while not stopped at an svr4
probe. It then assumes this means there's a problem with the probes
interface and disables it through the following sequence of events:
- solib_event_probe_at return nullptr
- svr4_handle_solib_event returns early
- the make_scope_exit callback calls disable_probes_interface
We could fix that by making the ROCm handle_event callback check if an
svr4 probe is that the stop address, and only call
svr4_so_ops.handle_event if so. However, it doesn't feel right to
include some svr4 implementation detail in the ROCm event handler.
Instead, this patch changes svr4_handle_solib_event to not assume it is
an error if called while not at an svr4 probe location, and therefore
not disable the probes interface. That just means moving the
make_scope_exit call below where we lookup the probe by pc.
Change-Id: Ie8ddf5beffa2e92b8ebfdd016454546252519244
Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
Add a few debug statements that were useful to me when debugging why the
glibc probes interface wasn't getting used.
Change-Id: Ic20744f9fc80a90f196896b0829949411620c540
|
|
From glibc 2.35 and later, the "map_failed" stap probe is no longer
included in glibc. The removal of the probe looks like an accident,
but it was caused by a glibc commit which meant that the "map_failed"
probe could no longer be reached; the compiler then helpfully
optimised out the probe.
In GDB, in solib-svr4.c, we have a list of probes that we look for
related to the shared library loading detection. If any of these
probes are missing then GDB will fall back to the non-probe based
mechanism for detecting shared library loading. The "map_failed"
probe is include in the list of required probes.
This means that on glibc 2.35 (or later) systems, GDB is going to
always fall back to the non-probes based mechanism for detecting
shared library loading.
I raised a glibc bug to discuss this issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=29818
But, whatever the ultimate decision from the glibc team, given there
are version of glibc in the wild without the "map_failed" probe, we
probably should update GDB to handle this situation.
The "map_failed" probe is already a little strange, very early
versions of glibc didn't include this probe, so, in some cases, if
this probe is missing GDB is happy to ignore it. This is fine, the
action associated with this probe inside GDB is DO_NOTHING, this means
the probe isn't actually required in order for GDB to correctly detect
the loading of shared libraries.
In this commit I propose changing the rules so that any probe whose
action is DO_NOTHING, is optional.
There is one possible downside to this change, and that concerns 'set
stop-on-solib-events on'. If a probe is removed from glibc, but the
old style breakpoint based mechanism is still in place within glibc
for that same event, then GDB will stop when using the old style
non-probe based mechanism, but not when using the probes based
mechanism.
For the map_failed case this is not a problem, both the map_failed
probe, and the call to the old style breakpoint location were
optimised out, and so neither event (probes based, or breakpoint
based) will trigger. This would only become an issue if glibc removed
a probe, but left the breakpoint in place (this would almost certainly
be a bug in glibc).
For now, I'm proposing that we just don't worry about this. Because
some probes have actions that are not DO_NOTHING, then we know the
user will always seem _some_ stops when a shared library is
loaded/unloaded, and (I'm guessing), in most cases, that's all they
care about. I figure when someone complains then we can figure out
what the right solution is then.
With this commit in place, then, when using a glibc 2.35 or later
system, GDB will once again use the stap probes for shared library
detection.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
|
|
When looking up names, GDB needs to stay within one linker namespace to
find the correct instance in case the same name is provided in more than
one namespace.
Modify svr4_iterate_over_objfiles_in_search_order() to stay within the
namespace of the current_objfile argument. If no current_objfile is
provided (i.e. it is nullptr), iterate over objfiles in the initial
namespace.
For objfiles that do not have a corresponding so_list to provide the
namespace, assume that the objfile was loaded into the initial namespace.
This would cover the main executable objfile (which is indeed loaded into
the initial namespace) as well as manually added symbol files.
Expected fails:
- gdb.base/non-lazy-array-index.exp: the expression parser may lookup
global symbols, which may result in xfers to read auxv for determining
the debug base as part of svr4_iterate_over_objfiles_in_search_order().
- gdb.server/non-lazy-array-index.exp: symbol lookup may access the
target to read AUXV in order to determine the debug base for SVR4
linker namespaces.
Known issues:
- get_symbol_address() and get_msymbol_address() search objfiles for a
'better' match. This was introduced by
4b610737f02 Handle copy relocations
to handle copy relocations but it now causes a wrong address to be
read after symbol lookup actually cound the correct symbol. This can
be seen, for example, with gdb.base/dlmopen.exp when compiled with
clang.
- gnu ifuncs are only looked up in the initial namespace.
- lookup_minimal_symbol() and lookup_minimal_symbol_text() directly
iterate over objfiles and are not aware of linker namespaces.
|
|
Introduce a new qXfer:libraries-svr4:read annex key/value pair
lmid=<namespace identifier>
to be used together with start and prev to provide the namespace of start
and prev to gdbserver.
Unknown key/value pairs are ignored by gdbserver so no new supports check
is needed.
Introduce a new library-list-svr4 library attribute
lmid
to provide the namespace of a library entry to GDB.
This implementation uses the address of a namespace's r_debug object as
namespace identifier.
This should have incremented the minor version but since unknown XML
attributes are ignored, anyway, and since changing the version results in
a warning from GDB, the version is left at 1.0.
|
|
In glibc, the r_debug structure contains (amongst others) the following
fields:
int r_version:
Version number for this protocol. It should be greater than 0.
If r_version is 2, struct r_debug is extended to struct r_debug_extended
with one additional field:
struct r_debug_extended *r_next;
Link to the next r_debug_extended structure. Each r_debug_extended
structure represents a different namespace. The first r_debug_extended
structure is for the default namespace.
1. Change solib_svr4_r_map argument to take the debug base.
2. Add solib_svr4_r_next to find the link map in the next namespace from
the r_next field.
3. Update svr4_current_sos_direct to get the link map in the next namespace
from the r_next field.
4. Don't check shared libraries in other namespaces when updating shared
libraries in a new namespace.
5. Update svr4_same to check the load offset in addition to the name
6. Update svr4_default_sos to also set l_addr_inferior
7. Change the flat solib_list into a per-namespace list using the
namespace's r_debug address to identify the namespace.
Add gdb.base/dlmopen.exp to test this.
To remain backwards compatible with older gdbserver, we reserve the
namespace zero for a flat list of solibs from all namespaces. Subsequent
patches will extend RSP to allow listing libraries grouped by namespace.
This fixes PR 11839.
Co-authored-by: Lu, Hongjiu <hongjiu.lu@intel.com>
|
|
Whenever we call locate_base(), we clear info->debug_base directly before
the call. Thus, we never cache the base location as locate_base() had
intended.
Move the svr4_have_link_map_offsets() check into elf_locate_base(), inline
locate_base() at all call sites, and remove it.
|
|
With the test-case included in this patch, we run into:
...
(gdb) target remote localhost:2347^M
`target:twice-connect' has disappeared; keeping its symbols.^M
Remote debugging using localhost:2347^M
warning: Unable to find dynamic linker breakpoint function.^M
GDB will be unable to debug shared library initializers^M
and track explicitly loaded dynamic code.^M
Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M
0x00007ffff7dd4550 in ?? ()^M
(gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started
FAIL: gdb.server/twice-connect.exp: found interpreter
...
The problem originates in find_program_interpreter, where
bfd_get_section_contents is called to read .interp, but fails. The function
returns false but the result is ignored, so find_program_interpreter returns
some random string.
Fix this by checking the result of the call to bfd_get_section_contents.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29652
|
|
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
|
|
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
|
