aboutsummaryrefslogtreecommitdiff
path: root/gdb/debuginfod-support.c
AgeCommit message (Collapse)AuthorFilesLines
9 hoursUpdate copyright dates to include 2025Tom Tromey1-1/+1
This updates the copyright headers to include 2025. I did this by running gdb/copyright.py and then manually modifying a few files as noted by the script. Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-11-11Wrap help strings at 80 columnsTom Tromey1-6/+6
This patch ensures that all ordinary help strings are wrapped at 80 columns. For the most part this consists of changing code like this (note the embedded \n and the trailing backslash without a newline): -Manage the space-separated list of debuginfod server URLs that GDB will query \ -when missing debuginfo, executables or source files.\nThe default value is \ -copied from the DEBUGINFOD_URLS environment variable."), ... to end each line with \n\, like: +Manage the space-separated list of debuginfod server URLs that GDB will\n\ +query when missing debuginfo, executables or source files.\n\ +The default value is copied from the DEBUGINFOD_URLS environment variable."), Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-11-10gdb: use mapped file information to improve debuginfod textAndrew Burgess1-2/+2
When opening a core-file GDB is able to use debuginfod to download the executable that matches the core-file if GDB can find a build-id for the executable in the core-file. In this case GDB calls debuginfod_exec_query to download the executable and GDB prints a message like: Downloading executable for /path/to/core-file... which makes sense in that case. For a long time GDB has also had the ability to download memory-mapped files and shared libraries when opening a core-file. However, recent commits have made these cases more likely to trigger, which is a good thing, but the messaging from GDB in these cases is not ideal. When downloading a memory-mapped file GDB prints: Downloading executable for /path/to/memory-mapped-file And for a shared library: Downloading executable for /path/to/libfoo.so These last two messages could, I think, be improved. I propose making two changes. First, I suggest instead of using /path/to/core-file in the first case, we use the name of the executable that GDB is fetching. This makes the messaging consistent in that we print the name of the file we're fetching rather than the name of the file we're fetching something for. I further propose that we replace 'executable for' with the more generic word 'file'. The messages will then become: Downloading file /path/to/exec-file... Downloading file /path/to/memory-mapped-file... Downloading file /path/to/libfoo.so... I think these messages are clearer than what we used to have, and they are consistent in that we name the thing being downloaded in all cases. There is one tiny problem. The first case relies on GDB knowing the name of the executable it wants to download. The only place we can currently get that from is, I think, the memory-mapped file list. [ ASIDE: There is `bfd_core_file_failing_command` which reports the executable and argument list from the core file, but this information is not ideal for this task. First, the executable and arguments are merged into a single string, and second, the string is a relatively short, fixed length string, so the executable name is often truncated. For these reasons I don't consider fetching the executable name using this bfd function as a solution. ] We do have to consider the case that the core file does not have any mapped file information. This shouldn't ever be the case for a Linux target, but it's worth considering. [ ASIDE: I mention Linux specifically because this only becomes a problem if we try to do a lookup via debuginfod, which requires that we have build-ids available. Linux has special support for embedding build-ids into the core file, but I'm not sure if other kernels do this. ] For the unlikely edge case of a core-file that has build-ids, but doesn't have any mapped file information then I propose that we synthesis a filename like: 'with build-id xxxxxx'. We would then see a message like: Downloading file with build-id xxxxxx... Where 'xxxxxx' would be replaced by the actual build-id. This isn't ideal, but I think is good enough, and, as I said, I think this case is not going to be hit very often, or maybe at all. We already had some tests that emitted two of the above messages, which I've updated, these cover the mapped-file and shared library case. The message about downloading the exec for the core-file is actually really hard to trigger now as usually the exec will also appear in the memory-mapped file list and GDB will download the file at this stage. Then when GDB needs the executable for loading the symbols it'll ask debuginfod, and debuginfod will find the file in its cache, and so no message will be printed. If anyone has any ideas about how to trigger this case then I'm happy to add additional tests. Approved-By: Tom Tromey <tom@tromey.com>
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-27Rewrite final cleanupsTom Tromey1-10/+4
This patch rewrites final cleanups to use std::function and otherwise be more C++-ish.
2024-01-19gdb: Buffer output streams during events that might download debuginfoAaron Merey1-5/+10
Introduce new ui_file buffering_file to temporarily collect output written to gdb_std* output streams during print_thread, print_frame_info and print_stop_event. This ensures that output during these functions is not interrupted by debuginfod progress messages. With the addition of deferred debuginfo downloading it is possible for download progress messages to print during these events. Without any intervention we can end up with poorly formatted output: (gdb) backtrace [...] #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (Downloading separate debug info for /lib64/libpython3.11.so.1.0 function_cache=0x561221b224d0, state=<optimized out>... To fix this we buffer writes to gdb_std* output streams while allowing debuginfod progress messages to skip the buffers and print to the underlying output streams immediately. Buffered output is then written to the output streams. This ensures that progress messages print first, followed by uninterrupted frame/thread/stop info: (gdb) backtrace [...] Downloading separate debug info for /lib64/libpython3.11.so.1.0 #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (function_cache=0x561221b224d0, state=<optimized out>... Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.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: Remove uses of gdb::to_string (const std::string_view &)Lancelot Six1-3/+1
This patch removes all uses of to_string(const std::string_view&) and use the std::string ctor or implicit conversion from std::string_view to std::string instead. A later patch will remove this gdb::to_string while removing gdbsupport/gdb_string_view.h. Change-Id: I877cde557a0727be7b0435107e3c7a2aac165895 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdb: Use std::string_view instead of gdb::string_viewLancelot Six1-3/+4
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>
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-5/+5
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-10-02gdb: Add command 'maint set/show debuginfod download-sections'Aaron Merey1-3/+60
This setting controls whether GDB may attempt to download ELF/DWARF sections from debuginfod servers. This setting is enabled by default if gdb is built with debuginfod section download support (requires libdebuginfod 0.188). Also update debuginfod command help text and gdb.texinfo with information on section downloading and the new command. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-02gdb/debuginfod: Add debuginfod_section_queryAaron Merey1-0/+60
Add new function debuginfod_section_query. This function queries debuginfod servers for an individual ELF/DWARF section associated with a given build-id. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-06-09gdb/debuginfod: cleanup debuginfod earlierAndrew Burgess1-18/+29
A GDB crash was discovered on Fedora GDB that was tracked back to an issue with the way that debuginfod is cleaned up. The bug was reported on Fedora 37, 38, and 39. Here are the steps to reproduce: 1. The file /etc/ssl/openssl.cnf contains the following lines: [provider_sect] default = default_sect ##legacy = legacy_sect ## [default_sect] activate = 1 ##[legacy_sect] ##activate = 1 The bug will occur when the '##' characters are removed so that the lines in question look like this: [provider_sect] default = default_sect legacy = legacy_sect [default_sect] activate = 1 [legacy_sect] activate = 1 2. Clean up any existing debuginfod cache data: > rm -rf $HOME/.cache/debuginfod_client 3. Run GDB: > gdb -nx -q -iex 'set trace-commands on' \ -iex 'set debuginfod enabled on' \ -iex 'set confirm off' \ -ex 'start' -ex 'quit' /bin/ls +set debuginfod enabled on +set confirm off Reading symbols from /bin/ls... Downloading separate debug info for /usr/bin/ls ... snip ... Temporary breakpoint 1, main (argc=1, argv=0x7fffffffde38) at ../src/ls.c:1646 1646 { +quit Fatal signal: Segmentation fault ----- Backtrace ----- ... snip ... So GDB ends up crashing during exit. What's happening is that when debuginfod is initialised debuginfod_begin is called (this is in the debuginfod library), this in turn sets up libcurl, which makes use of openssl. Somewhere during this setup process an at_exit function is registered to cleanup some state. Back in GDB the debuginfod_client object is managed using this code: /* Deleter for a debuginfod_client. */ struct debuginfod_client_deleter { void operator() (debuginfod_client *c) { debuginfod_end (c); } }; using debuginfod_client_up = std::unique_ptr<debuginfod_client, debuginfod_client_deleter>; And then a global debuginfod_client_up is created to hold a pointer to the debuginfod_client object. As a global this will be cleaned up using the standard C++ global object destructor mechanism, which is run after the at_exit handlers. However, it is expected that when debuginfod_end is called the debuginfod_client object will still be in a usable state, that is, we don't expect the at_exit handlers to have run and started cleaning up the library state. To fix this issue we need to ensure that debuginfod_end is called before the at_exit handlers have a chance to run. This commit removes the debuginfod_client_up type, and instead has GDB hold a raw pointer to the debuginfod_client object. We then make use of GDB's make_final_cleanup to register a function that will call debuginfod_end. As GDB's final cleanups are called before exit is called, this means that debuginfod_end will be called before the at_exit handlers are called, and the crash identified above is resolved. It's not obvious how this issue can easily be tested for. The bug does not appear to manifest when using a local debuginfod server, so we'd need to setup something more involved. For now I'm proposing this patch without any associated tests. Co-Authored-By: Mark Wielaard <mark@klomp.org> Co-Authored-By: Simon Marchi <simark@simark.ca> Reviewed-By: Tom Tromey <tom@tromey.com> Reviewed-By: Aaron Merey <amerey@redhat.com>
2023-03-20Make ui_out::do_progress_end 'private'Tom Tromey1-44/+57
I noticed that ui_out::do_progress_end is public, just to support one use in debuginfod-support.c. This patch makes it private, updates progress_info to call it from its destructor, and finally changes debuginfod-support.c to follow.
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-11-10gdb/debuginfod: Improve progress updatesAaron Merey1-43/+73
If the download size is known, a progress bar is displayed along with the percentage of completion and the total download size. Downloading separate debug info for /lib/libxyz.so [############ ] 25% (10.01 M) If the download size is not known, a progress indicator is displayed with a ticker ("###") that moves across the screen at a rate of 1 tick every 0.5 seconds. Downloading separate debug info for /lib/libxyz.so [ ### ] If the output stream is not a tty, batch mode is enabled, the screen is too narrow or width has been set to 'unlimited', then only a static description of the download is printed. No bar or ticker is displayed. Downloading separate debug info for /lib/libxyz.so... In any case, if the size of the download is known at the time the description is printed then it will be included in the description. Downloading 10.01 MB separate debug info for /lib/libxyz.so...
2022-07-15gdb-add-index always generates an error when libdebuginfod wasn't compiled inAaron Merey1-1/+3
gdb-add-index runs gdb with -iex 'set debuginfod enabled off'. If gdb is not compiled against libdebuginfod this causes an unnecessary error message to be printed to stderr indicating that gdb was not built with debuginfod support. Fix this by changing the 'set debuginfod enabled off' command to a no-op when gdb isn't built with libdebuginfod.
2022-06-15gdb: Always suppress stringop-overread warning in debuginfod-support.cMark Wielaard1-7/+4
Just like on s390x with g++ 11.2.1 and ppc64le with g++ 11.3.1 g++ 11 on hppa produces a spurious warning for stringop-overread in debuginfod_is_enabled for url_view. Just always suppress it on all arches. https://sourceware.org/bugzilla/show_bug.cgi?id=29198 gdb/ChangeLog: * debuginfod-support.c (debuginfod_is_enabled): Always use DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD.
2022-05-12gdb: Workaround stringop-overread warning in debuginfod-support.c on powerpc64Mark Wielaard1-5/+5
Just like on s390x with g++ 11.2.1, ppc64le with g++ 11.3.1 produces a spurious warning for stringop-overread in debuginfod_is_enabled for url_view. Also suppress it on powerpc64. gdb/ChangeLog: * debuginfod-support.c (debuginfod_is_enabled): Use DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on powerpc64.
2022-05-04gdb: Workaround stringop-overread warning in debuginfod-support.c on s390xMark Wielaard1-0/+11
For some reason g++ 11.2.1 on s390x produces a spurious warning for stringop-overread in debuginfod_is_enabled for url_view. Add a new DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD macro to suppress this warning. include/ChangeLog: * diagnostics.h (DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD): New macro. gdb/ChangeLog: * debuginfod-support.c (debuginfod_is_enabled): Use DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on s390x.
2022-05-02gdb/debuginfod: Whitespace-only URL should disable debuginfodAaron Merey1-3/+4
Currently debuginfod is disabled when the string of server URLs is unset or set to be the empty string (via the $DEBUGINFOD_URLS environment variable or the 'set debuginfod urls' gdb command). Extend this functionality so that a whitespace-only URL also disables debuginfod. Modify a testcase to verify that a whitespace-only URL disables debuginfod.
2022-04-20gdb/debuginfod: Prevent out_of_range exceptionAaron Merey1-3/+4
Trailing whitespace in the string of debuginfod URLs causes an out_of_range exception during the printing of URLs for the first use notice. To fix this, stop printing URLs when the substring to be printed consists only of whitespace. Also add first use notice testcases. Co-Authored-By: Pedro Alves <pedro@palves.net>
2022-04-01gdb/debuginfod-support.c: Always display debuginfod errorsAaron Merey1-3/+3
Errors encountered when downloading files from debuginfod servers are not displayed if debuginfod verbosity is set to 0 (via 'set debuginfod verbose 0'). Tom recommended that these errors always be displayed, regardless of the verbosity setting [1]. Fix this. [1] https://sourceware.org/pipermail/gdb-patches/2022-March/186350.html
2022-03-31Style URLs in GDB outputTom Tromey1-4/+21
I noticed that GDB will display URLs in a few spots. This changes them to be styled. Originally I thought I'd introduce a new "url" style, but there aren't many places to use this, so I just reused filename styling instead. This patch also changes the debuginfod URL list to be printed one URL per line. I think this is probably a bit easier to read.
2022-03-29Unify gdb printf functionsTom Tromey1-33/+33
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-03-24Remove download size from debuginfod progress messages if unavailableAaron Merey1-18/+26
Currently debuginfod progress update messages include the size of each download: Downloading 7.5 MB separate debug info for /lib/libxyz.so.0 This value originates from the Content-Length HTTP header of the transfer. However this header is not guaranteed to be present for each download. This can happen when debuginfod servers compress files on-the-fly at the time of transfer. In this case gdb wrongly prints "-0.00 MB" as the size. This patch removes download sizes from progress messages when they are not available. It also removes usage of the progress bar until a more thorough reworking of progress updating is implemented. [1] [1] https://sourceware.org/pipermail/gdb-patches/2022-February/185798.html
2022-03-21PR gdb/27570: missing support for debuginfod in core_target::build_file_mappingsAaron Merey1-0/+51
Add debuginfod support to core_target::build_file_mappings and locate_exec_from_corefile_build_id to enable the downloading of missing executables and shared libraries referenced in core files. Also add debuginfod support to solib_map_sections so that previously downloaded shared libraries can be retrieved from the local debuginfod cache. When core file shared libraries are found locally, verify that their build-ids match the corresponding build-ids found in the core file. If there is a mismatch, attempt to query debuginfod for the correct build and print a warning if unsuccessful: warning: Build-id of /lib64/libc.so.6 does not match core file. Also disable debuginfod when gcore invokes gdb. Debuginfo is not needed for core file generation so debuginfod queries will slow down gcore unnecessarily.
2022-03-10Simplify the ui-out progress APITom Tromey1-1/+1
I noticed that 'progress' is a method on ui-out, but it seems to me that it would be better if the only API were via the progress_meter class. This patch makes this change, changing progress to be a method on the meter itself.
2022-03-08PR gdb/27876 - debuginfod-downloaded source files don't pass proper fullname ↵Aaron Merey1-2/+3
across mi / (gdb)info source Source files downloaded from debuginfod currently use their original DWARF filename as their "fullname". This causes a mismatch between the fullname and the actual location of the source file in the debuginfod client cache. MI consumers such as VSCode will fail to open debuginfod-downloaded source files due to this. Also 'info source' will fail to include the true paths of these files. To fix this, use the debuginfod cache path as the fullname for debuginfod- downloaded source files.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-12-29Use filtered output in show callbacksTom Tromey1-4/+4
"show" command callbacks, like most ordinary gdb commands, should use filtered output. I found a few that did not, so this patch changes them to use the filtered form.
2021-12-29Consistently Use ui_file parameter to show callbacksTom Tromey1-2/+3
I happened to notice that one "show" callback was printing to gdb_stdout rather than to the passed-in ui_file parameter. I went through all such callbacks and fixed them to consistently use the ui_file. Regression tested on x86-64 Fedora 34.
2021-11-29[PR gdb/27026] CTRL-C is ignored when debug info is downloadedAaron Merey1-0/+15
During debuginfod downloads, ctrl-c should result in the download being cancelled and skipped. However in some cases, ctrl-c fails to get delivered to gdb during downloading. This can result in downloads being unskippable. Fix this by ensuring that target_terminal::ours is in effect for the duration of each download. Co-authored-by: Tom de Vries <tdevries@suse.de> https://sourceware.org/bugzilla/show_bug.cgi?id=27026#c3
2021-11-15gdb: rework "set debuginfod" commandsSimon Marchi1-188/+126
As discussed here [1], do some re-work in the "set debuginfod commands". First, use "set debuginfod enabled on/off/ask" instead of "set debuginfod on/off/ask". This is more MI-friendly, and it gives an output that makes more sense in "info set", for example. Then, make the show commands not call "error" when debuginfod support is not compiled in. This makes the commands "show" and "show debuginfod" stop early, breaking gdb.base/default.exp: Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/default.exp ... FAIL: gdb.base/default.exp: info set FAIL: gdb.base/default.exp: show - Make the "debuginfod enabled" setting default to "off" when debuginfod support is not compiled in, and "ask" otherwise. - Make the setter of "debuginfod enabled" error out when debuginfod support is not compiled in, so that "debuginfod enabled" will always remain "off" in that case. - Make the setter of "debuginfod verbose" work in any case. I don't see the harm in letting the user change that setting, since the user will hit an error if they try to enable the use of debuginfod. - I would do the same for the "debuginfod urls" setter, but because this one needs to see the DEBUGINFOD_URLS_ENV_VAR macro, provided by libdebuginfod, I made that one error out as well if debuginfod support is not compiled it (otherwise, I would have left it like "debuginfod verbose". Alternatively, we could hard-code "DEBUGINFOD_URLS" in the code (in fact, it was prior to this patch, but I think it was an oversight, as other spots use DEBUGINFOD_URLS_ENV_VAR), or use a dummy string to store the setting, but I don't really see the value in that. Rename debuginfod_enable to debuginfod_enabled, just so it matches the setting name. [1] https://sourceware.org/pipermail/gdb-patches/2021-October/182937.html Change-Id: I45fdb2993f668226a5639228951362b7800f09d5 Co-Authored-By: Aaron Merey <amerey@redhat.com>
2021-10-31Fix unittest.exp failure due to 'set debuginfod' additionTom Tromey1-2/+2
The 'set debuginfod' change caused a regression in unittest.exp: Running selftest help_doc_invariants. help doc broken invariant: command 'info set debuginfod' help doc first line is not terminated with a '.' character help doc broken invariant: command 'set debuginfod' help doc first line is not terminated with a '.' character help doc broken invariant: command 'show debuginfod' help doc first line is not terminated with a '.' character Self test failed: self-test failed at ../../binutils-gdb/gdb/unittests/command-def-selftests.c:100 This patch fixes the problem. I'm checking it in.
2021-10-29gdb: add set/show commands for managing debuginfodAaron Merey1-8/+268
Add 'set debuginfod' command. Accepts 'on', 'off' or 'ask' as an argument. 'on' enables debuginfod for the current session. 'off' disables debuginfod for the current session. 'ask' will prompt the user to either enable or disable debuginfod when the next query is about to be performed: This GDB supports auto-downloading debuginfo from the following URLs: <URL1> <URL2> ... Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod on' to .gdbinit. For interactive sessions, 'ask' is the default. For non-interactive sessions, 'off' is the default. Add 'show debuginfod status' command. Displays whether debuginfod is set to 'on', 'off' or 'ask'. Add 'set/show debuginfod urls' commands. Accepts a string of space-separated debuginfod server URLs to be queried. The default value is copied from the DEBUGINFOD_URLS environment variable. Finally add 'set/show debuginfod verbose' commands to control whether debuginfod-related output is displayed. Verbose output is enabled by default. (gdb) run Starting program: /bin/sleep 5 Download failed: No route to host. Continuing without debug info for /lib64/libc.so.6. If GDB is not built with debuginfod then these commands will just display Support for debuginfod is not compiled into GDB.
2021-05-07debuginfod-support.c: Use long-lived debuginfod_clientAaron Merey1-12/+20
Instead of initializing a new debuginfod_client for each query, store the first initialized client for the remainder of the GDB session and use it for every debuginfod query. In conjunction with upcoming changes to libdebuginfod, using one client for all queries will avoid latency caused by unneccesarily setting up TCP connections multiple times. Tested on Fedora 33 x86_64. gdb/ChangeLog: * debuginfod-support.c (debuginfod_init): Remove. (get_debuginfod_client): New function.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-12-16[gdb] Print progress for debuginfodMartin Liska1-8/+19
Prints progress like: Downloading 4.89 MB separate debug info for /usr/lib64/libgcrypt.so.20. Downloading 1.10 MB separate debug info for /usr/lib64/liblzma.so.5. Downloading 1.31 MB separate debug info for /usr/lib64/liblz4.so.1. Downloading 0.96 MB separate debug info for /usr/lib64/libsmime3.so. [### ] Tested on x86_64-linux. ChangeLog: 2020-12-16 Martin Liska <mliska@suse.cz> Tom de Vries <tdevries@suse.de> * gdb/debuginfod-support.c (struct user_data): Remove has_printed field. Add meter field. (progressfn): Print progress using meter.
2020-11-23[gdb] Don't return non-existing path in debuginfod_source_queryTom de Vries1-2/+4
When setting env var DEBUGINFOD_URLS to " " and running the testsuite, we run into these regressions: ... FAIL: gdb.base/list-missing-source.exp: info source FAIL: gdb.base/source-dir.exp: info source before setting directory search list ... Setting var DEBUGINFOD_URLS to " " allows the debuginfod query function debuginfod_source_query to get past its early exit. The function debuginfod_source_query is documented as: "If the file is successfully retrieved, its path on the local machine is stored in DESTNAME". However, in case we get back -ENOENT from libdebuginfod, we still set DESTNAME: .... if (fd.get () < 0 && fd.get () != -ENOENT) printf_filtered (_("Download failed: %s. Continuing without source file %ps.\n"), safe_strerror (-fd.get ()), styled_string (file_name_style.style (), srcpath)); else *destname = make_unique_xstrdup (srcpath); return fd; ... Fix this by making debuginfod_source_query fit it's documentation and only setting DESTNAME when successfully retrieving a file. Likewise in debuginfod_debuginfo_query. gdb/ChangeLog: 2020-11-23 Tom de Vries <tdevries@suse.de> * debuginfod-support.c (debuginfod_source_query) (debuginfod_debuginfo_query): Only set DESTNAME if successful.
2020-11-18[gdb] Improve early exits for env var in debuginfod-support.cTom de Vries1-2/+4
There's an early exit in libdebuginfod's debuginfod_query_server, which checks both for: - getenv (DEBUGINFOD_URLS_ENV_VAR) == NULL, and - (getenv (DEBUGINFOD_URLS_ENV_VAR))[0] == '\0'. In debuginfod_source_query and debuginfod_debuginfo_query (which both end up calling debuginfod_query_server) there are also early exits checking the same env var, but those just check for NULL. Make the early exit tests in debuginfod-support.c match those in libdebuginfod. gdb/ChangeLog: 2020-11-18 Tom de Vries <tdevries@suse.de> * debuginfod-support.c (debuginfod_source_query) (debuginfod_debuginfo_query): Also do early exit if "(getenv (DEBUGINFOD_URLS_ENV_VAR))[0] == '\0'".
2020-09-14gdb: introduce debuginfod_client_up typeSimon Marchi1-11/+24
Introduce and use a unique pointer specialization for the debuginfod_client type. The deleter calls debuginfod_end to free the client. gdb/ChangeLog: * debuginfod-support.c (debuginfod_client_deleter): New. (debuginfod_client_up): New. (debuginfod_init): Return debuginfod_client_up. (debuginfod_source_query): Adjust. (debuginfod_debuginfo_query): Adjust. Change-Id: Ie56441e123ab80b78e5311c824c162cd804f68c0
2020-09-14gdb: use make_unique_xstrdup in debuginfod-support.cSimon Marchi1-1/+1
Use make_unique_xstrdup instead of reset + xstrdup. gdb/ChangeLog: * debuginfod-support.c (debuginfod_source_query): Use make_unique_xstrdup. Change-Id: Iee9524fea7630b4d6ee5c74e30c60fe222dc1d2c
2020-08-13debuginfod-support.c: Replace globals with user_dataAaron Merey1-16/+22
Store query information in user_data struct instead of global variables. gdb/ChangeLog: * debuginfod-support.c: Replace global variables with user_data.
2020-03-02gdb: Move defs.h before any system header in debuginfod-support.cJon Turney1-1/+1
* defs.h includes config.h * config.h may define _GNU_SOURCE * if _GNU_SOURCE is defined, that must be before including any system header (see feature_test_macro(7)) This is necessary to ensure that a prototype for mkostemp() is brought into scope by <stdlib.h> when compiling filestuff.h, on platforms where _GNU_SOURCE isn't unconditionally defined for C++. In file included from ../../gdb/../gdbsupport/scoped_fd.h:24, from ../../gdb/debuginfod-support.c:22: ../../gdb/../gdbsupport/filestuff.h: In function ‘int gdb_mkostemp_cloexec(char*, int)’: ../../gdb/../gdbsupport/filestuff.h:59:10: error: ‘mkostemp’ was not declared in this scope; did you mean ‘mkstemp’? gdb/ChangeLog: 2020-02-29 Jon Turney <jon.turney@dronecode.org.uk> * debuginfod-support.c: Include defs.h first.
2020-02-26Add debuginfod support to GDBAaron Merey1-0/+155
debuginfod is a lightweight web service that indexes ELF/DWARF debugging resources by build-id and serves them over HTTP. This patch enables GDB to query debuginfod servers for separate debug files and source code when it is otherwise not able to find them. GDB can be built with debuginfod using the --with-debuginfod configure option. This requires that libdebuginfod be installed and found at configure time. debuginfod is packaged with elfutils, starting with version 0.178. For more information see https://sourceware.org/elfutils/. Tested on x86_64 Fedora 31. gdb/ChangeLog: 2020-02-26 Aaron Merey <amerey@redhat.com> * Makefile.in: Handle optional debuginfod support. * NEWS: Update. * README: Add --with-debuginfod summary. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Handle optional debuginfod support. * debuginfod-support.c: debuginfod helper functions. * debuginfod-support.h: Ditto. * doc/gdb.texinfo: Add --with-debuginfod to configure options summary. * dwarf2/read.c (dwarf2_get_dwz_file): Query debuginfod servers when a dwz file cannot be found. * elfread.c (elf_symfile_read): Query debuginfod servers when a debuginfo file cannot be found. * source.c (open_source_file): Query debuginfod servers when a source file cannot be found. * top.c (print_gdb_configuration): Include --{with,without}-debuginfod in the output. gdb/testsuite/ChangeLog: 2020-02-26 Aaron Merey <amerey@redhat.com> * gdb.debuginfod: New directory for debuginfod tests. * gdb.debuginfod/main.c: New test file. * gdb.debuginfod/fetch_src_and_symbols.exp: New tests.
generated by cgit v1.1 at 2025-04-09 02:21:34 +0000