2020-02-26 17:40:49 -05:00
|
|
|
/* debuginfod utilities for GDB.
|
2023-01-01 16:49:04 +04:00
|
|
|
Copyright (C) 2020-2023 Free Software Foundation, Inc.
|
2020-02-26 17:40:49 -05:00
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
#include "defs.h"
|
2022-05-03 23:17:31 +00:00
|
|
|
#include "diagnostics.h"
|
2020-02-29 13:33:35 +00:00
|
|
|
#include <errno.h>
|
2020-02-26 17:40:49 -05:00
|
|
|
#include "gdbsupport/scoped_fd.h"
|
|
|
|
#include "debuginfod-support.h"
|
2023-10-13 09:27:48 +00:00
|
|
|
#include <optional>
|
2021-10-29 19:55:57 -04:00
|
|
|
#include "cli/cli-cmds.h"
|
|
|
|
#include "cli/cli-style.h"
|
2022-10-24 14:05:06 -04:00
|
|
|
#include "cli-out.h"
|
2021-11-29 14:58:38 -05:00
|
|
|
#include "target.h"
|
2021-10-29 19:55:57 -04:00
|
|
|
|
|
|
|
/* Set/show debuginfod commands. */
|
|
|
|
static cmd_list_element *set_debuginfod_prefix_list;
|
|
|
|
static cmd_list_element *show_debuginfod_prefix_list;
|
|
|
|
|
2023-10-02 13:59:57 -04:00
|
|
|
/* maint set/show debuginfod commands. */
|
|
|
|
static cmd_list_element *maint_set_debuginfod_cmdlist;
|
|
|
|
static cmd_list_element *maint_show_debuginfod_cmdlist;
|
|
|
|
|
2021-10-29 19:55:57 -04:00
|
|
|
static const char debuginfod_on[] = "on";
|
|
|
|
static const char debuginfod_off[] = "off";
|
|
|
|
static const char debuginfod_ask[] = "ask";
|
|
|
|
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
static const char *debuginfod_enabled_enum[] =
|
|
|
|
{
|
|
|
|
debuginfod_on,
|
|
|
|
debuginfod_off,
|
|
|
|
debuginfod_ask,
|
|
|
|
nullptr
|
|
|
|
};
|
|
|
|
|
|
|
|
static const char *debuginfod_enabled =
|
|
|
|
#if defined(HAVE_LIBDEBUGINFOD)
|
|
|
|
debuginfod_ask;
|
|
|
|
#else
|
|
|
|
debuginfod_off;
|
|
|
|
#endif
|
|
|
|
|
2023-10-02 13:59:57 -04:00
|
|
|
/* Controls whether ELF/DWARF section downloading is enabled. */
|
|
|
|
static bool debuginfod_download_sections =
|
|
|
|
#if defined(HAVE_LIBDEBUGINFOD_FIND_SECTION)
|
|
|
|
true;
|
|
|
|
#else
|
|
|
|
false;
|
|
|
|
#endif
|
|
|
|
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
static unsigned int debuginfod_verbose = 1;
|
2020-02-26 17:40:49 -05:00
|
|
|
|
|
|
|
#ifndef HAVE_LIBDEBUGINFOD
|
|
|
|
scoped_fd
|
|
|
|
debuginfod_source_query (const unsigned char *build_id,
|
|
|
|
int build_id_len,
|
|
|
|
const char *srcpath,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *destname)
|
|
|
|
{
|
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
}
|
|
|
|
|
|
|
|
scoped_fd
|
|
|
|
debuginfod_debuginfo_query (const unsigned char *build_id,
|
|
|
|
int build_id_len,
|
|
|
|
const char *filename,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *destname)
|
|
|
|
{
|
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
}
|
2021-10-29 19:55:57 -04:00
|
|
|
|
2022-03-02 20:00:59 -05:00
|
|
|
scoped_fd
|
|
|
|
debuginfod_exec_query (const unsigned char *build_id,
|
|
|
|
int build_id_len,
|
|
|
|
const char *filename,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *destname)
|
|
|
|
{
|
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
}
|
|
|
|
|
2023-08-15 12:17:48 -04:00
|
|
|
scoped_fd
|
|
|
|
debuginfod_section_query (const unsigned char *build_id,
|
|
|
|
int build_id_len,
|
|
|
|
const char *filename,
|
|
|
|
const char *section_name,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *destname)
|
|
|
|
{
|
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
}
|
2021-10-29 19:55:57 -04:00
|
|
|
#define NO_IMPL _("Support for debuginfod is not compiled into GDB.")
|
|
|
|
|
2020-02-26 17:40:49 -05:00
|
|
|
#else
|
|
|
|
#include <elfutils/debuginfod.h>
|
|
|
|
|
2020-08-13 17:47:05 -04:00
|
|
|
struct user_data
|
|
|
|
{
|
|
|
|
user_data (const char *desc, const char *fname)
|
2022-10-24 14:05:06 -04:00
|
|
|
: desc (desc), fname (fname)
|
2020-08-13 17:47:05 -04:00
|
|
|
{ }
|
|
|
|
|
|
|
|
const char * const desc;
|
|
|
|
const char * const fname;
|
2022-10-24 14:05:06 -04:00
|
|
|
ui_out::progress_update progress;
|
2020-08-13 17:47:05 -04:00
|
|
|
};
|
2020-02-26 17:40:49 -05:00
|
|
|
|
2022-10-24 14:05:06 -04:00
|
|
|
/* Convert SIZE into a unit suitable for use with progress updates.
|
|
|
|
SIZE should in given in bytes and will be converted into KB, MB, GB
|
|
|
|
or remain unchanged. UNIT will be set to "B", "KB", "MB" or "GB"
|
|
|
|
accordingly. */
|
|
|
|
|
|
|
|
static const char *
|
|
|
|
get_size_and_unit (double &size)
|
|
|
|
{
|
|
|
|
if (size < 1024)
|
|
|
|
/* If size is less than 1 KB then set unit to B. */
|
|
|
|
return "B";
|
|
|
|
|
|
|
|
size /= 1024;
|
|
|
|
if (size < 1024)
|
|
|
|
/* If size is less than 1 MB then set unit to KB. */
|
|
|
|
return "K";
|
|
|
|
|
|
|
|
size /= 1024;
|
|
|
|
if (size < 1024)
|
|
|
|
/* If size is less than 1 GB then set unit to MB. */
|
|
|
|
return "M";
|
|
|
|
|
|
|
|
size /= 1024;
|
|
|
|
return "G";
|
|
|
|
}
|
|
|
|
|
2020-02-26 17:40:49 -05:00
|
|
|
static int
|
|
|
|
progressfn (debuginfod_client *c, long cur, long total)
|
|
|
|
{
|
2020-08-13 17:47:05 -04:00
|
|
|
user_data *data = static_cast<user_data *> (debuginfod_get_user_data (c));
|
2021-05-07 11:37:16 -04:00
|
|
|
gdb_assert (data != nullptr);
|
2020-08-13 17:47:05 -04:00
|
|
|
|
2022-10-24 14:05:06 -04:00
|
|
|
string_file styled_fname (current_uiout->can_emit_style_escape ());
|
|
|
|
fprintf_styled (&styled_fname, file_name_style.style (), "%s",
|
|
|
|
data->fname);
|
|
|
|
|
2020-02-26 17:40:49 -05:00
|
|
|
if (check_quit_flag ())
|
|
|
|
{
|
2022-10-24 14:05:06 -04:00
|
|
|
gdb_printf ("Cancelling download of %s %s...\n",
|
|
|
|
data->desc, styled_fname.c_str ());
|
2020-02-26 17:40:49 -05:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2022-10-24 14:05:06 -04:00
|
|
|
if (debuginfod_verbose == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Print progress update. Include the transfer size if available. */
|
|
|
|
if (total > 0)
|
2020-02-26 17:40:49 -05:00
|
|
|
{
|
2022-10-24 14:05:06 -04:00
|
|
|
/* Transfer size is known. */
|
|
|
|
double howmuch = (double) cur / (double) total;
|
|
|
|
|
|
|
|
if (howmuch >= 0.0 && howmuch <= 1.0)
|
2022-03-22 20:01:54 -04:00
|
|
|
{
|
2022-10-24 14:05:06 -04:00
|
|
|
double d_total = (double) total;
|
|
|
|
const char *unit = get_size_and_unit (d_total);
|
|
|
|
std::string msg = string_printf ("Downloading %0.2f %s %s %s",
|
|
|
|
d_total, unit, data->desc,
|
|
|
|
styled_fname.c_str ());
|
|
|
|
data->progress.update_progress (msg, unit, howmuch, d_total);
|
|
|
|
return 0;
|
2022-03-22 20:01:54 -04:00
|
|
|
}
|
2020-02-26 17:40:49 -05:00
|
|
|
}
|
|
|
|
|
2022-10-24 14:05:06 -04:00
|
|
|
std::string msg = string_printf ("Downloading %s %s",
|
|
|
|
data->desc, styled_fname.c_str ());
|
|
|
|
data->progress.update_progress (msg);
|
2020-02-26 17:40:49 -05:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
gdb/debuginfod: cleanup debuginfod earlier
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-05-23 11:37:41 +01:00
|
|
|
/* Cleanup ARG, which is a debuginfod_client pointer. */
|
|
|
|
|
|
|
|
static void
|
|
|
|
cleanup_debuginfod_client (void *arg)
|
|
|
|
{
|
|
|
|
debuginfod_client *client = static_cast<debuginfod_client *> (arg);
|
|
|
|
debuginfod_end (client);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return a pointer to the single global debuginfod_client, initialising it
|
|
|
|
first if needed. */
|
|
|
|
|
2021-05-07 11:37:16 -04:00
|
|
|
static debuginfod_client *
|
|
|
|
get_debuginfod_client ()
|
2020-02-26 17:40:49 -05:00
|
|
|
{
|
gdb/debuginfod: cleanup debuginfod earlier
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-05-23 11:37:41 +01:00
|
|
|
static debuginfod_client *global_client = nullptr;
|
2020-02-26 17:40:49 -05:00
|
|
|
|
2021-05-07 11:37:16 -04:00
|
|
|
if (global_client == nullptr)
|
|
|
|
{
|
gdb/debuginfod: cleanup debuginfod earlier
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-05-23 11:37:41 +01:00
|
|
|
global_client = debuginfod_begin ();
|
2021-05-07 11:37:16 -04:00
|
|
|
|
|
|
|
if (global_client != nullptr)
|
gdb/debuginfod: cleanup debuginfod earlier
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-05-23 11:37:41 +01:00
|
|
|
{
|
|
|
|
/* It is important that we cleanup the debuginfod_client object
|
|
|
|
before calling exit. Some of the libraries used by debuginfod
|
|
|
|
make use of at_exit handlers to perform cleanup.
|
|
|
|
|
|
|
|
If we wrapped the debuginfod_client in a unique_ptr and relied
|
|
|
|
on its destructor to cleanup then this would be run as part of
|
|
|
|
the global C++ object destructors, which is after the at_exit
|
|
|
|
handlers, which is too late.
|
|
|
|
|
|
|
|
So instead, we make use of GDB's final cleanup mechanism. */
|
|
|
|
make_final_cleanup (cleanup_debuginfod_client, global_client);
|
|
|
|
debuginfod_set_progressfn (global_client, progressfn);
|
|
|
|
}
|
2021-05-07 11:37:16 -04:00
|
|
|
}
|
2020-02-26 17:40:49 -05:00
|
|
|
|
gdb/debuginfod: cleanup debuginfod earlier
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-05-23 11:37:41 +01:00
|
|
|
return global_client;
|
2020-02-26 17:40:49 -05:00
|
|
|
}
|
|
|
|
|
2021-10-29 19:55:57 -04:00
|
|
|
/* Check if debuginfod is enabled. If configured to do so, ask the user
|
|
|
|
whether to enable debuginfod. */
|
|
|
|
|
|
|
|
static bool
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
debuginfod_is_enabled ()
|
2021-10-29 19:55:57 -04:00
|
|
|
{
|
2022-04-27 16:41:24 -04:00
|
|
|
const char *urls = skip_spaces (getenv (DEBUGINFOD_URLS_ENV_VAR));
|
2021-10-29 19:55:57 -04:00
|
|
|
|
2022-04-27 16:41:24 -04:00
|
|
|
if (debuginfod_enabled == debuginfod_off
|
|
|
|
|| urls == nullptr
|
|
|
|
|| *urls == '\0')
|
2021-10-29 19:55:57 -04:00
|
|
|
return false;
|
|
|
|
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
if (debuginfod_enabled == debuginfod_ask)
|
2021-10-29 19:55:57 -04:00
|
|
|
{
|
2022-03-09 17:26:37 -07:00
|
|
|
gdb_printf (_("\nThis GDB supports auto-downloading debuginfo " \
|
|
|
|
"from the following URLs:\n"));
|
|
|
|
|
2023-10-13 10:17:02 +00:00
|
|
|
std::string_view url_view (urls);
|
2022-03-09 17:26:37 -07:00
|
|
|
while (true)
|
|
|
|
{
|
2022-04-08 18:50:56 -04:00
|
|
|
size_t off = url_view.find_first_not_of (' ');
|
2023-10-13 10:17:02 +00:00
|
|
|
if (off == std::string_view::npos)
|
2022-03-09 17:26:37 -07:00
|
|
|
break;
|
2022-04-08 18:50:56 -04:00
|
|
|
url_view = url_view.substr (off);
|
2022-05-31 11:00:06 +02:00
|
|
|
/* g++ 11.2.1 on s390x, g++ 11.3.1 on ppc64le and g++ 11 on
|
|
|
|
hppa seem convinced url_view might be of SIZE_MAX length.
|
|
|
|
And so complains because the length of an array can only
|
|
|
|
be PTRDIFF_MAX. */
|
2022-05-03 23:17:31 +00:00
|
|
|
DIAGNOSTIC_PUSH
|
|
|
|
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
|
2022-04-08 18:50:56 -04:00
|
|
|
off = url_view.find_first_of (' ');
|
2022-05-03 23:17:31 +00:00
|
|
|
DIAGNOSTIC_POP
|
2022-03-09 17:26:37 -07:00
|
|
|
gdb_printf
|
|
|
|
(_(" <%ps>\n"),
|
|
|
|
styled_string (file_name_style.style (),
|
2023-10-13 10:54:46 +00:00
|
|
|
std::string (url_view.substr (0, off)).c_str ()));
|
2023-10-13 10:17:02 +00:00
|
|
|
if (off == std::string_view::npos)
|
2022-03-09 17:26:37 -07:00
|
|
|
break;
|
|
|
|
url_view = url_view.substr (off);
|
|
|
|
}
|
|
|
|
|
|
|
|
int resp = nquery (_("Enable debuginfod for this session? "));
|
2021-10-29 19:55:57 -04:00
|
|
|
if (!resp)
|
|
|
|
{
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (_("Debuginfod has been disabled.\nTo make this " \
|
|
|
|
"setting permanent, add \'set debuginfod " \
|
|
|
|
"enabled off\' to .gdbinit.\n"));
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
debuginfod_enabled = debuginfod_off;
|
2021-10-29 19:55:57 -04:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (_("Debuginfod has been enabled.\nTo make this " \
|
|
|
|
"setting permanent, add \'set debuginfod enabled " \
|
|
|
|
"on\' to .gdbinit.\n"));
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
debuginfod_enabled = debuginfod_on;
|
2021-10-29 19:55:57 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2022-10-24 14:05:06 -04:00
|
|
|
/* Print the result of the most recent attempted download. */
|
|
|
|
|
|
|
|
static void
|
2023-03-16 10:12:17 -06:00
|
|
|
print_outcome (int fd, const char *desc, const char *fname)
|
2022-10-24 14:05:06 -04:00
|
|
|
{
|
|
|
|
if (fd < 0 && fd != -ENOENT)
|
|
|
|
gdb_printf (_("Download failed: %s. Continuing without %s %ps.\n"),
|
|
|
|
safe_strerror (-fd),
|
2023-03-16 10:12:17 -06:00
|
|
|
desc,
|
|
|
|
styled_string (file_name_style.style (), fname));
|
2022-10-24 14:05:06 -04:00
|
|
|
}
|
|
|
|
|
2020-02-26 17:40:49 -05:00
|
|
|
/* See debuginfod-support.h */
|
|
|
|
|
|
|
|
scoped_fd
|
|
|
|
debuginfod_source_query (const unsigned char *build_id,
|
|
|
|
int build_id_len,
|
|
|
|
const char *srcpath,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *destname)
|
|
|
|
{
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
if (!debuginfod_is_enabled ())
|
2020-02-26 17:40:49 -05:00
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
|
2021-05-07 11:37:16 -04:00
|
|
|
debuginfod_client *c = get_debuginfod_client ();
|
2020-02-26 17:40:49 -05:00
|
|
|
|
|
|
|
if (c == nullptr)
|
|
|
|
return scoped_fd (-ENOMEM);
|
|
|
|
|
2021-11-19 19:41:40 -05:00
|
|
|
char *dname = nullptr;
|
2023-03-16 10:12:17 -06:00
|
|
|
scoped_fd fd;
|
2023-10-13 09:27:48 +00:00
|
|
|
std::optional<target_terminal::scoped_restore_terminal_state> term_state;
|
2021-11-29 14:58:38 -05:00
|
|
|
|
2023-03-16 10:12:17 -06:00
|
|
|
{
|
|
|
|
user_data data ("source file", srcpath);
|
|
|
|
|
|
|
|
debuginfod_set_user_data (c, &data);
|
|
|
|
if (target_supports_terminal_ours ())
|
|
|
|
{
|
|
|
|
term_state.emplace ();
|
|
|
|
target_terminal::ours ();
|
|
|
|
}
|
|
|
|
|
|
|
|
fd = scoped_fd (debuginfod_find_source (c,
|
|
|
|
build_id,
|
|
|
|
build_id_len,
|
|
|
|
srcpath,
|
|
|
|
&dname));
|
|
|
|
debuginfod_set_user_data (c, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
print_outcome (fd.get (), "source file", srcpath);
|
2020-11-23 20:09:50 +01:00
|
|
|
|
|
|
|
if (fd.get () >= 0)
|
2021-11-19 19:41:40 -05:00
|
|
|
destname->reset (dname);
|
2020-02-26 17:40:49 -05:00
|
|
|
|
|
|
|
return fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* See debuginfod-support.h */
|
|
|
|
|
|
|
|
scoped_fd
|
|
|
|
debuginfod_debuginfo_query (const unsigned char *build_id,
|
|
|
|
int build_id_len,
|
|
|
|
const char *filename,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *destname)
|
|
|
|
{
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
if (!debuginfod_is_enabled ())
|
2020-02-26 17:40:49 -05:00
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
|
2021-05-07 11:37:16 -04:00
|
|
|
debuginfod_client *c = get_debuginfod_client ();
|
2020-02-26 17:40:49 -05:00
|
|
|
|
|
|
|
if (c == nullptr)
|
|
|
|
return scoped_fd (-ENOMEM);
|
|
|
|
|
|
|
|
char *dname = nullptr;
|
2023-03-16 10:12:17 -06:00
|
|
|
scoped_fd fd;
|
2023-10-13 09:27:48 +00:00
|
|
|
std::optional<target_terminal::scoped_restore_terminal_state> term_state;
|
2021-11-29 14:58:38 -05:00
|
|
|
|
2023-03-16 10:12:17 -06:00
|
|
|
{
|
|
|
|
user_data data ("separate debug info for", filename);
|
|
|
|
|
|
|
|
debuginfod_set_user_data (c, &data);
|
|
|
|
if (target_supports_terminal_ours ())
|
|
|
|
{
|
|
|
|
term_state.emplace ();
|
|
|
|
target_terminal::ours ();
|
|
|
|
}
|
|
|
|
|
|
|
|
fd = scoped_fd (debuginfod_find_debuginfo (c, build_id, build_id_len,
|
|
|
|
&dname));
|
|
|
|
debuginfod_set_user_data (c, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
print_outcome (fd.get (), "separate debug info for", filename);
|
2020-02-26 17:40:49 -05:00
|
|
|
|
2020-11-23 20:09:50 +01:00
|
|
|
if (fd.get () >= 0)
|
|
|
|
destname->reset (dname);
|
2020-09-14 22:28:42 -04:00
|
|
|
|
2020-02-26 17:40:49 -05:00
|
|
|
return fd;
|
|
|
|
}
|
2022-03-02 20:00:59 -05:00
|
|
|
|
|
|
|
/* See debuginfod-support.h */
|
|
|
|
|
|
|
|
scoped_fd
|
|
|
|
debuginfod_exec_query (const unsigned char *build_id,
|
|
|
|
int build_id_len,
|
|
|
|
const char *filename,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *destname)
|
|
|
|
{
|
|
|
|
if (!debuginfod_is_enabled ())
|
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
|
|
|
|
debuginfod_client *c = get_debuginfod_client ();
|
|
|
|
|
|
|
|
if (c == nullptr)
|
|
|
|
return scoped_fd (-ENOMEM);
|
|
|
|
|
|
|
|
char *dname = nullptr;
|
2023-03-16 10:12:17 -06:00
|
|
|
scoped_fd fd;
|
2023-10-13 09:27:48 +00:00
|
|
|
std::optional<target_terminal::scoped_restore_terminal_state> term_state;
|
2022-03-02 20:00:59 -05:00
|
|
|
|
2023-03-16 10:12:17 -06:00
|
|
|
{
|
|
|
|
user_data data ("executable for", filename);
|
|
|
|
|
|
|
|
debuginfod_set_user_data (c, &data);
|
|
|
|
if (target_supports_terminal_ours ())
|
|
|
|
{
|
|
|
|
term_state.emplace ();
|
|
|
|
target_terminal::ours ();
|
|
|
|
}
|
|
|
|
|
|
|
|
fd = scoped_fd (debuginfod_find_executable (c, build_id, build_id_len,
|
|
|
|
&dname));
|
|
|
|
debuginfod_set_user_data (c, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
print_outcome (fd.get (), "executable for", filename);
|
2022-03-02 20:00:59 -05:00
|
|
|
|
|
|
|
if (fd.get () >= 0)
|
|
|
|
destname->reset (dname);
|
|
|
|
|
|
|
|
return fd;
|
|
|
|
}
|
2023-08-15 12:17:48 -04:00
|
|
|
|
|
|
|
/* See debuginfod-support.h */
|
|
|
|
|
|
|
|
scoped_fd
|
|
|
|
debuginfod_section_query (const unsigned char *build_id,
|
|
|
|
int build_id_len,
|
|
|
|
const char *filename,
|
|
|
|
const char *section_name,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *destname)
|
|
|
|
{
|
|
|
|
#if !defined (HAVE_LIBDEBUGINFOD_FIND_SECTION)
|
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
#else
|
|
|
|
|
2023-10-02 13:59:57 -04:00
|
|
|
if (!debuginfod_download_sections || !debuginfod_is_enabled ())
|
2023-08-15 12:17:48 -04:00
|
|
|
return scoped_fd (-ENOSYS);
|
|
|
|
|
|
|
|
debuginfod_client *c = get_debuginfod_client ();
|
|
|
|
|
|
|
|
if (c == nullptr)
|
|
|
|
return scoped_fd (-ENOMEM);
|
|
|
|
|
|
|
|
char *dname = nullptr;
|
|
|
|
std::string desc = std::string ("section ") + section_name + " for";
|
|
|
|
scoped_fd fd;
|
2023-10-13 09:27:48 +00:00
|
|
|
std::optional<target_terminal::scoped_restore_terminal_state> term_state;
|
2023-08-15 12:17:48 -04:00
|
|
|
|
|
|
|
{
|
|
|
|
user_data data (desc.c_str (), filename);
|
|
|
|
debuginfod_set_user_data (c, &data);
|
|
|
|
if (target_supports_terminal_ours ())
|
|
|
|
{
|
|
|
|
term_state.emplace ();
|
|
|
|
target_terminal::ours ();
|
|
|
|
}
|
|
|
|
|
|
|
|
fd = scoped_fd (debuginfod_find_section (c, build_id, build_id_len,
|
|
|
|
section_name, &dname));
|
|
|
|
debuginfod_set_user_data (c, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
print_outcome (fd.get (), desc.c_str (), filename);
|
|
|
|
gdb_assert (destname != nullptr);
|
|
|
|
|
|
|
|
if (fd.get () >= 0)
|
|
|
|
destname->reset (dname);
|
|
|
|
|
|
|
|
return fd;
|
|
|
|
#endif /* HAVE_LIBDEBUGINFOD_FIND_SECTION */
|
|
|
|
}
|
|
|
|
|
2020-02-26 17:40:49 -05:00
|
|
|
#endif
|
2021-10-29 19:55:57 -04:00
|
|
|
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
/* Set callback for "set debuginfod enabled". */
|
|
|
|
|
|
|
|
static void
|
|
|
|
set_debuginfod_enabled (const char *value)
|
|
|
|
{
|
|
|
|
#if defined(HAVE_LIBDEBUGINFOD)
|
|
|
|
debuginfod_enabled = value;
|
|
|
|
#else
|
2022-07-05 18:11:49 -04:00
|
|
|
/* Disabling debuginfod when gdb is not built with it is a no-op. */
|
|
|
|
if (value != debuginfod_off)
|
|
|
|
error (NO_IMPL);
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get callback for "set debuginfod enabled". */
|
|
|
|
|
|
|
|
static const char *
|
|
|
|
get_debuginfod_enabled ()
|
|
|
|
{
|
|
|
|
return debuginfod_enabled;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Show callback for "set debuginfod enabled". */
|
|
|
|
|
|
|
|
static void
|
|
|
|
show_debuginfod_enabled (ui_file *file, int from_tty, cmd_list_element *cmd,
|
|
|
|
const char *value)
|
|
|
|
{
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (file,
|
|
|
|
_("Debuginfod functionality is currently set to "
|
|
|
|
"\"%s\".\n"), debuginfod_enabled);
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Set callback for "set debuginfod urls". */
|
|
|
|
|
|
|
|
static void
|
|
|
|
set_debuginfod_urls (const std::string &urls)
|
|
|
|
{
|
|
|
|
#if defined(HAVE_LIBDEBUGINFOD)
|
|
|
|
if (setenv (DEBUGINFOD_URLS_ENV_VAR, urls.c_str (), 1) != 0)
|
|
|
|
warning (_("Unable to set debuginfod URLs: %s"), safe_strerror (errno));
|
|
|
|
#else
|
|
|
|
error (NO_IMPL);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get callback for "set debuginfod urls". */
|
|
|
|
|
|
|
|
static const std::string&
|
|
|
|
get_debuginfod_urls ()
|
|
|
|
{
|
|
|
|
static std::string urls;
|
|
|
|
#if defined(HAVE_LIBDEBUGINFOD)
|
|
|
|
const char *envvar = getenv (DEBUGINFOD_URLS_ENV_VAR);
|
|
|
|
|
|
|
|
if (envvar != nullptr)
|
|
|
|
urls = envvar;
|
|
|
|
else
|
|
|
|
urls.clear ();
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return urls;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Show callback for "set debuginfod urls". */
|
|
|
|
|
|
|
|
static void
|
|
|
|
show_debuginfod_urls (ui_file *file, int from_tty, cmd_list_element *cmd,
|
|
|
|
const char *value)
|
|
|
|
{
|
|
|
|
if (value[0] == '\0')
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (file, _("Debuginfod URLs have not been set.\n"));
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
else
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (file, _("Debuginfod URLs are currently set to:\n%s\n"),
|
|
|
|
value);
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Show callback for "set debuginfod verbose". */
|
|
|
|
|
|
|
|
static void
|
|
|
|
show_debuginfod_verbose_command (ui_file *file, int from_tty,
|
|
|
|
cmd_list_element *cmd, const char *value)
|
|
|
|
{
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (file, _("Debuginfod verbose output is set to %s.\n"),
|
|
|
|
value);
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
}
|
|
|
|
|
2023-10-02 13:59:57 -04:00
|
|
|
/* Set callback for "maint set debuginfod download-sections". */
|
|
|
|
|
|
|
|
static void
|
|
|
|
maint_set_debuginfod_download_sections (bool value)
|
|
|
|
{
|
|
|
|
#if !defined(HAVE_LIBDEBUGINFOD_FIND_SECTION)
|
|
|
|
if (value)
|
|
|
|
error (_("Support for section downloading is not compiled into GDB. " \
|
|
|
|
"Defaulting to \"off\"."));
|
|
|
|
#endif
|
|
|
|
|
|
|
|
debuginfod_download_sections = value;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get callback for "maint set debuginfod download-sections". */
|
|
|
|
|
|
|
|
static bool
|
|
|
|
maint_get_debuginfod_download_sections ()
|
|
|
|
{
|
|
|
|
return debuginfod_download_sections;
|
|
|
|
}
|
|
|
|
|
2021-10-29 19:55:57 -04:00
|
|
|
/* Register debuginfod commands. */
|
|
|
|
|
|
|
|
void _initialize_debuginfod ();
|
|
|
|
void
|
|
|
|
_initialize_debuginfod ()
|
|
|
|
{
|
|
|
|
/* set/show debuginfod */
|
|
|
|
add_setshow_prefix_cmd ("debuginfod", class_run,
|
2021-10-31 11:34:06 -06:00
|
|
|
_("Set debuginfod options."),
|
|
|
|
_("Show debuginfod options."),
|
2021-10-29 19:55:57 -04:00
|
|
|
&set_debuginfod_prefix_list,
|
|
|
|
&show_debuginfod_prefix_list,
|
|
|
|
&setlist, &showlist);
|
|
|
|
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
add_setshow_enum_cmd ("enabled", class_run, debuginfod_enabled_enum,
|
|
|
|
_("Set whether to use debuginfod."),
|
|
|
|
_("Show whether to use debuginfod."),
|
|
|
|
_("\
|
2023-10-02 13:59:57 -04:00
|
|
|
When set to \"on\", enable the use of debuginfod to download missing\n\
|
|
|
|
debug info and source files. GDB may also download components of debug\n\
|
|
|
|
info instead of entire files. \"off\" disables the use of debuginfod.\n\
|
|
|
|
When set to \"ask\", prompt whether to enable or disable debuginfod." ),
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
set_debuginfod_enabled,
|
|
|
|
get_debuginfod_enabled,
|
|
|
|
show_debuginfod_enabled,
|
|
|
|
&set_debuginfod_prefix_list,
|
|
|
|
&show_debuginfod_prefix_list);
|
2021-10-29 19:55:57 -04:00
|
|
|
|
|
|
|
/* set/show debuginfod urls */
|
|
|
|
add_setshow_string_noescape_cmd ("urls", class_run, _("\
|
|
|
|
Set the list of debuginfod server URLs."), _("\
|
|
|
|
Show the list of debuginfod server URLs."), _("\
|
|
|
|
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."),
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
set_debuginfod_urls,
|
|
|
|
get_debuginfod_urls,
|
|
|
|
show_debuginfod_urls,
|
2021-10-29 19:55:57 -04:00
|
|
|
&set_debuginfod_prefix_list,
|
|
|
|
&show_debuginfod_prefix_list);
|
|
|
|
|
|
|
|
/* set/show debuginfod verbose */
|
|
|
|
add_setshow_zuinteger_cmd ("verbose", class_support,
|
|
|
|
&debuginfod_verbose, _("\
|
|
|
|
Set verbosity of debuginfod output."), _("\
|
|
|
|
Show debuginfod debugging."), _("\
|
|
|
|
When set to a non-zero value, display verbose output for each debuginfod \
|
|
|
|
query.\nTo disable, set to zero. Verbose output is displayed by default."),
|
gdb: rework "set debuginfod" commands
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-11-02 12:21:31 -04:00
|
|
|
nullptr,
|
2021-10-29 19:55:57 -04:00
|
|
|
show_debuginfod_verbose_command,
|
|
|
|
&set_debuginfod_prefix_list,
|
|
|
|
&show_debuginfod_prefix_list);
|
2023-10-02 13:59:57 -04:00
|
|
|
|
|
|
|
/* maint set/show debuginfod. */
|
|
|
|
add_setshow_prefix_cmd ("debuginfod", class_maintenance,
|
|
|
|
_("Set debuginfod specific variables."),
|
|
|
|
_("Show debuginfod specific variables."),
|
|
|
|
&maint_set_debuginfod_cmdlist,
|
|
|
|
&maint_show_debuginfod_cmdlist,
|
|
|
|
&maintenance_set_cmdlist, &maintenance_show_cmdlist);
|
|
|
|
|
|
|
|
/* maint set/show debuginfod download-sections. */
|
|
|
|
add_setshow_boolean_cmd ("download-sections", class_maintenance, _("\
|
|
|
|
Set whether debuginfod may download individual ELF/DWARF sections."), _("\
|
|
|
|
Show whether debuginfod may download individual ELF/DWARF sections."), _("\
|
|
|
|
When enabled, debuginfod may attempt to download individual ELF/DWARF \
|
|
|
|
sections from debug info files.\nIf disabled, only whole debug info files \
|
|
|
|
may be downloaded."),
|
|
|
|
maint_set_debuginfod_download_sections,
|
|
|
|
maint_get_debuginfod_download_sections,
|
|
|
|
nullptr,
|
|
|
|
&maint_set_debuginfod_cmdlist,
|
|
|
|
&maint_show_debuginfod_cmdlist);
|
2021-10-29 19:55:57 -04:00
|
|
|
}
|