aboutsummaryrefslogtreecommitdiff
path: root/gdb/solib-svr4.c
AgeCommit message (Collapse)AuthorFilesLines
2024-05-30gdb: remove unused includes in utils.hSimon Marchi1-0/+1
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
2024-05-09gdb: convert address_in_mem_range to mem_range::containsAndrew Burgess1-1/+1
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>
2024-04-22gdb: move store/extract integer functions to extract-store-integer.{c,h}Simon Marchi1-0/+1
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>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
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>
2024-02-05gdb: rename target_so_ops to solib_opsSimon Marchi1-4/+4
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>
2024-02-05gdb: rename struct shobj -> struct solibSimon Marchi1-23/+23
`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>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
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.
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-8/+8
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>
2023-11-21gdb: Use C++17's std::make_unique instead of gdb::make_uniqueLancelot Six1-4/+4
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
2023-11-17gdb: remove get_current_regcacheSimon Marchi1-1/+1
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
2023-11-17gdb: remove regcache's address spaceSimon Marchi1-3/+2
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
2023-10-19gdb: rename struct so_list to shobjSimon Marchi1-23/+23
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>
2023-10-19gdb: remove free_so functionSimon Marchi1-1/+1
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>
2023-10-19gdb: link so_list using intrusive_listSimon Marchi1-59/+38
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>
2023-10-19gdb: make so_list::{so_original_name,so_name} std::stringsSimon Marchi1-14/+11
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>
2023-10-19gdb: make so_list::lm_info a unique_ptrSimon Marchi1-10/+15
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>
2023-10-19gdb: make solib-svr4 not use so_list internallySimon Marchi1-177/+98
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>
2023-10-19gdb: use gdb::checked_static_cast when casting lm_infoSimon Marchi1-8/+8
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>
2023-10-19gdb: remove target_so_ops::free_soSimon Marchi1-11/+0
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>
2023-10-19gdb: allocate so_list with new, deallocate with deleteSimon Marchi1-9/+4
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>
2023-10-19gdb: replace some so_list parameters to use referencesSimon Marchi1-18/+17
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>
2023-10-19gdb: add program_space parameter to target_so_ops::clear_solibSimon Marchi1-4/+2
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>
2023-10-10gdb: remove target_gdbarchSimon Marchi1-37/+51
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>
2023-09-28gdb: remove unused imports in solib*.[ch]Simon Marchi1-1/+0
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>
2023-08-09Rename bfd_bread and bfd_bwriteAlan Modra1-1/+1
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).
2023-07-10Remove target_closeTom Tromey1-10/+6
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>
2023-06-05[gdb] Fix grammar in comments and docsTom de Vries1-1/+1
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.
2023-06-03[gdb] Fix typosTom de Vries1-3/+3
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>
2023-05-25gdb: remove breakpoint_pointer_iteratorSimon Marchi1-2/+2
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>
2023-05-25gdb: remove bp_location_pointer_iteratorSimon Marchi1-3/+3
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>
2023-03-28Use function_view in gdb_bfd_lookup_symbolTom Tromey1-11/+9
This changes gdb_bfd_lookup_symbol to use a function_view. This simplifies the code a little bit.
2023-03-09gdb, gdbserver, gdbsupport: fix whitespace issuesSimon Marchi1-2/+2
Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-02-02gdb/solib-svr4: don't disable probes interface if probe not foundSimon Marchi1-5/+10
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>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
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.
2022-12-02gdb: add some debug statements to solib-svr4.cSimon Marchi1-1/+13
Add a few debug statements that were useful to me when debugging why the glibc probes interface wasn't getting used. Change-Id: Ic20744f9fc80a90f196896b0829949411620c540
2022-11-28gdb: relax requirement for the map_failed stap probe to be presentAndrew Burgess1-7/+26
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>
2022-10-18gdb, solib-svr4: support namespaces in DSO iterationMarkus Metzger1-2/+76
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.
2022-10-18gdb, gdbserver: extend RSP to support namespacesMarkus Metzger1-3/+35
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.
2022-10-18gdb, gdbserver: support dlmopen()Markus Metzger1-91/+294
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>
2022-10-18gdb, solib-svr4: remove locate_base()Markus Metzger1-51/+11
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.
2022-10-14[gdb] Fix heap-buffer-overflow in find_program_interpreterTom de Vries1-3/+5
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
2022-10-11gdb: fix auxv cachingSimon Marchi1-10/+5
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
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-2/+2
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>
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi1-3/+3
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-20Constify some target_so_ops instancesTom Tromey1-16/+18
This changes some target_so_ops instances to be const. This makes their use a little more obvious (they can't be mutated) and also allows for the removal of some initialization code.
2022-09-20Move solib_ops into gdbarchTom Tromey1-1/+1
This changs solib_ops to be an ordinary gdbarch value and updates all the uses. This removes a longstanding FIXME and makes the code somewhat cleaner as well.
2022-08-04Use registry in gdbarchTom Tromey1-20/+12
gdbarch implements its own registry-like approach. This patch changes it to instead use registry.h. It's a rather large patch but largely uninteresting -- it's mostly a straightforward conversion from the old approach to the new one. The main benefit of this change is that it introduces type safety to the gdbarch registry. It also removes a bunch of code. One possible drawback is that, previously, the gdbarch registry differentiated between pre- and post-initialization setup. This doesn't seem very important to me, though.
2022-08-03Use gdb_bfd_ref_ptr in objfileTom Tromey1-2/+2
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to removing some manual memory management, this fixes a use-after-free that was introduced by the registry rewrite series. The issue there was that, in some cases, registry shutdown could refer to memory that had already been freed. This help fix the bug by delaying the destruction of the BFD reference (and thus the per-bfd object) until after the registry has been shut down.
2022-07-28Rewrite registry.hTom Tromey1-1/+1
This rewrites registry.h, removing all the macros and replacing it with relatively ordinary template classes. The result is less code than the previous setup. It replaces large macros with a relatively straightforward C++ class, and now manages its own cleanup. The existing type-safe "key" class is replaced with the equivalent template class. This approach ended up requiring relatively few changes to the users of the registry code in gdb -- code using the key system just required a small change to the key's declaration. All existing users of the old C-like API are now converted to use the type-safe API. This mostly involved changing explicit deletion functions to be an operator() in a deleter class. The old "save/free" two-phase process is removed, and replaced with a single "free" phase. No existing code used both phases. The old "free" callbacks took a parameter for the enclosing container object. However, this wasn't truly needed and is removed here as well.
2022-05-05gdb: use gdb::function_view for ↵Simon Marchi1-8/+7
gdbarch_iterate_over_objfiles_in_search_order callback A rather straightforward patch to change an instance of callback + void pointer to gdb::function_view, allowing pasing lambdas that capture, and eliminating the need for the untyped pointer. Change-Id: I73ed644e7849945265a2c763f79f5456695b0037