GDB 10.1 released
an HTTP server for distributing ELF/DWARF debugging information as well as source code."
| From: | Joel Brobecker <brobecker-AT-adacore.com> | |
| To: | gdb-announce-AT-sourceware.org, info-gnu-AT-gnu.org | |
| Subject: | GDB 10.1 released! | |
| Date: | Sat, 24 Oct 2020 09:48:51 +0400 | |
| Message-ID: | <20201024054851.E4512A0754@float.home> |
GDB 10.1 released!
Release 10.1 of GDB, the GNU Debugger, is now available. GDB is
a source-level debugger for Ada, C, C++, Fortran, Go, Rust, and many
other languages. GDB can target (i.e., debug programs running on)
more than a dozen different processor architectures, and GDB itself
can run on most popular GNU/Linux, Unix and Microsoft Windows variants.
GDB is free (libre) software.
You can download GDB from the GNU FTP server in the directory:
ftp://ftp.gnu.org/gnu/gdb
The vital stats:
Size md5sum Name
21MiB 1822a7dd45e7813f4408407eec1a6af1 gdb-10.1.tar.xz
39MiB 67b01c95c88ab8e05a08680904bd6c92 gdb-10.1.tar.gz
There is a web page for GDB at:
http://www.gnu.org/software/gdb/
That page includes information about GDB mailing lists (an announcement
mailing list, developers discussion lists, etc.), details on how to
access GDB's source repository, locations for development snapshots,
preformatted documentation, and links to related information around
the net. We will put errata notes and host-specific tips for this release
on-line as any problems come up. All mailing lists archives are also
browsable via the web.
GDB 10.1 includes the following changes and enhancements:
* Support for debugging new targets:
- BPF (bpf-unknown-none)
* GDBserver support for the following targets:
- ARC GNU/Linux
- RISC-V GNU/Linux
* Multi-target debugging support (experimental)
* Support for debuginfod, an HTTP server for distributing ELF/DWARF
debugging information as well as source code.
* Support for debugging a 32-bit Windows program using a 64-bit Windows GDB.
* Support for building GDB with GNU Guile 3.0 and 2.2 (in addition to 2.0)
* Improved performance during startup through the use of threading
during symbol table loading (an optional feature in GDB 9, now
enabled by default in GDB 10).
* Various enhancements to the Python and Guile APIs
* Various TUI Mode fixes and enhancements.
* Other miscellaneous enhancements:
- Detection when attaching to a process of a mismatch between
this process and the executable previously loaded into GDB.
- Support for default arguments for "alias" commands.
* GDBserver support for the following host triplets has been removed:
i[34567]86-*-lynxos*
powerpc-*-lynxos*
i[34567]86-*-nto*
bfin-*-*linux*
crisv32-*-linux*
cris-*-linux*
m32r*-*-linux*
tilegx-*-linux*
arm*-*-mingw32ce*
i[34567]86-*-mingw32ce*
For a complete list and more details on each item, please see the gdb/NEWS
file, available at:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;...
--
Joel Brobecker
--
If you have a working or partly working program that you'd like
to offer to the GNU project as a GNU package,
see https://www.gnu.org/help/evaluation.html.
Posted Oct 24, 2020 17:51 UTC (Sat)
by mjw (subscriber, #16740)
[Link]
Posted Oct 25, 2020 12:52 UTC (Sun)
by pabs (subscriber, #43278)
[Link] (11 responses)
Posted Oct 25, 2020 17:53 UTC (Sun)
by kalvdans (subscriber, #82065)
[Link]
Posted Oct 25, 2020 19:26 UTC (Sun)
by mjw (subscriber, #16740)
[Link] (8 responses)
When relaying queries to upstream debuginfods, debuginfod does not include any particular security features. It trusts that the binaries returned by the debuginfods are accurate. Therefore, the list of servers should include only trustworthy ones. If accessed across HTTP rather than HTTPS, the network should be trustworthy. Authentication information through the internal libcurl library is not currently enabled.
Posted Oct 25, 2020 23:37 UTC (Sun)
by pabs (subscriber, #43278)
[Link] (7 responses)
Posted Oct 26, 2020 10:37 UTC (Mon)
by mjw (subscriber, #16740)
[Link] (5 responses)
I wouldn't say solely. You already trust your distro to provide the binaries to run under gdb, which could in theory do anything. But yes, the underlying idea is that you trust the binary provider to also provide the debuginfo and sources for that binary through trusting their https certificate.
> That doesn't inspire confidence in me, I think I would want to run a local debuginfod server that transparently uses rpm/apt to download the right packages, extract and cache the debug symbols.
That is certainly a valid use case. There is even an example config that does (almost) what you want out of the box (for rpm based systems): https://sourceware.org/git/?p=elfutils.git;a=blob;f=confi...
And that is basically what distro public servers do, except they can more easily work with all packages ever build and just preindex the packages (plus debuginfo and debugsources) based on build-ids.
If you want to do it completely transparently and locally then you'll just need to add a transparent downloader for the rpm/apt packages (based in build-id) that deposits those in a directory that the debuginfod server scans.
Posted Oct 26, 2020 12:52 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (4 responses)
Posted Oct 26, 2020 14:32 UTC (Mon)
by fuhchee (guest, #40059)
[Link] (3 responses)
The debuginfod.systemtap.org server I operate is just an off-the-shelf copy of debuginfod, run against a directories that contain literally nothing but curl-scraped copies of rpm/deb/etc. files from distros' web archives. There is little to the setup other than cron jobs driving curl from ugly little shell scripts.
Longer form background info on server operation is here:
https://developers.redhat.com/blog/2019/12/17/deploying-d...
Posted Oct 26, 2020 15:01 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Oct 26, 2020 15:42 UTC (Mon)
by fuhchee (guest, #40059)
[Link] (1 responses)
Posted Oct 27, 2020 3:37 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Oct 26, 2020 12:03 UTC (Mon)
by fuhchee (guest, #40059)
[Link]
I get it. To some extent, this is inherent in returning contents of distro archives in raw form, no longer protected by whatever crypto signature mechanism is in use at the distro level. Substantial trust will come from having distros / ISVs set up their own https debuginfod servers. End-users can each decide which servers they wish to trust (since they control $DEBUGINFOD_URLS), and particularly concerned end-users can very easily run their own local server.
Posted Oct 25, 2020 22:25 UTC (Sun)
by roc (subscriber, #30627)
[Link]
Using a SIGSEGV handler to work around crashes in C++ demangling also does not inspire confidence. https://robert.ocallahan.org/2020/03/debugging-gdb-using-...
Posted Oct 26, 2020 7:59 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (6 responses)
Posted Oct 26, 2020 8:03 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Oct 26, 2020 8:36 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (3 responses)
Posted Oct 26, 2020 9:37 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Debug info servers have been used by Windows developers for quite some time. They are really useful, if somewhat tricky to set up. In a company where I worked, all the CI builds uploaded the debug information onto the debug symbol servers (along with source code).
So you could just fire up WinDbg, attach to an app and immediately get its source code. It was awesome.
Posted Oct 26, 2020 12:21 UTC (Mon)
by fuhchee (guest, #40059)
[Link]
Posted Oct 28, 2020 12:51 UTC (Wed)
by jtaylor (subscriber, #91739)
[Link]
Posted Oct 26, 2020 10:25 UTC (Mon)
by roc (subscriber, #30627)
[Link] (1 responses)
If you only host debuginfo for the latest version of each package then users will often find they can't get debuginfo for packages that are frequently updated because they happen to not be using the latest version.
Posted Oct 26, 2020 11:51 UTC (Mon)
by fuhchee (guest, #40059)
[Link]
debuginfod
GDB 10.1 released
GDB 10.1 released
Note the Security section of debuginfod:
GDB 10.1 released
debuginfod does not include any particular security features. While it is robust with respect to inputs, some abuse is possible. It forks a new thread for each incoming HTTP request, which could lead to a denial-of-service in terms of RAM, CPU, disk I/O, or network I/O. If this is a problem, users are advised to install debuginfod with a HTTPS reverse-proxy front-end that enforces site policies for firewalling, authentication, integrity, authorization, and load control. The /metrics webapi endpoint is probably not appropriate for disclosure to the public.
That last sentence doesn't seem accurate or doesn't mean what I think it does. It might be speaking about client certificates, not server cerficates. Server certificates seem to be checked as expected. I noticed that the experimental opensuse debuginfod server had an expired certificate. libdebuginfod refuses to retrieve any binaries/debuginfo/sources from that server. The error message doesn't mention that is because of a bad certificate though. I submitted a patch.
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
GDB 10.1 released
These usually run with read only filesystems and to save space without any debug information or easy way to add that information to the running container.
Tools being able to pull this data from a remote server should simplify a few operations.
GDB 10.1 released
GDB 10.1 released