mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-12-19 01:19:41 +08:00
73d7312ff6
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>
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.