As reported in PR 27157, if some environment variables read at startup
by GDB are defined but empty, we hit the assert in gdb_abspath:
$ XDG_CACHE_HOME= ./gdb -nx --data-directory=data-directory -q
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2007040==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000001b0 (pc 0x5639d4aa4127 bp 0x7ffdac232c00 sp 0x7ffdac232bf0 T0)
==2007040==The signal is caused by a READ memory access.
==2007040==Hint: address points to the zero page.
#0 0x5639d4aa4126 in target_stack::top() const /home/smarchi/src/binutils-gdb/gdb/target.h:1334
#1 0x5639d4aa41f1 in inferior::top_target() /home/smarchi/src/binutils-gdb/gdb/inferior.h:369
#2 0x5639d4a70b1f in current_top_target() /home/smarchi/src/binutils-gdb/gdb/target.c:120
#3 0x5639d4b00591 in gdb_readline_wrapper_cleanup::gdb_readline_wrapper_cleanup() /home/smarchi/src/binutils-gdb/gdb/top.c:1046
#4 0x5639d4afab31 in gdb_readline_wrapper(char const*) /home/smarchi/src/binutils-gdb/gdb/top.c:1104
#5 0x5639d4ccce2c in defaulted_query /home/smarchi/src/binutils-gdb/gdb/utils.c:893
#6 0x5639d4ccd6af in query(char const*, ...) /home/smarchi/src/binutils-gdb/gdb/utils.c:985
#7 0x5639d4ccaec1 in internal_vproblem /home/smarchi/src/binutils-gdb/gdb/utils.c:373
#8 0x5639d4ccb3d1 in internal_verror(char const*, int, char const*, __va_list_tag*) /home/smarchi/src/binutils-gdb/gdb/utils.c:439
#9 0x5639d5151a92 in internal_error(char const*, int, char const*, ...) /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
#10 0x5639d5162ab4 in gdb_abspath(char const*) /home/smarchi/src/binutils-gdb/gdbsupport/pathstuff.cc:132
#11 0x5639d5162fac in get_standard_cache_dir[abi:cxx11]() /home/smarchi/src/binutils-gdb/gdbsupport/pathstuff.cc:228
#12 0x5639d3e76a81 in _initialize_index_cache() /home/smarchi/src/binutils-gdb/gdb/dwarf2/index-cache.c:325
#13 0x5639d4dbbe92 in initialize_all_files() /home/smarchi/build/binutils-gdb/gdb/init.c:321
#14 0x5639d4b00259 in gdb_init(char*) /home/smarchi/src/binutils-gdb/gdb/top.c:2344
#15 0x5639d4440715 in captured_main_1 /home/smarchi/src/binutils-gdb/gdb/main.c:950
#16 0x5639d444252e in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1229
#17 0x5639d44425cf in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1254
#18 0x5639d3923371 in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
#19 0x7fa002d3f0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#20 0x5639d392314d in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0x4d414d)
gdb_abspath doesn't handle empty strings, so handle this case in the
callers. If a variable is defined but empty, I think it's reasonable in
this case to just ignore it, as if it was not defined.
Note that this sometimes also lead to a segfault, because the failed
assertion happens very early during startup, before things are fully
initialized.
gdbsupport/ChangeLog:
PR gdb/27157
* pathstuff.cc (get_standard_cache_dir, get_standard_config_dir,
find_gdb_home_config_file): Add empty string check.
gdb/testsuite/ChangeLog:
PR gdb/27157
* gdb.base/empty-host-env-vars.exp: New test.
Change-Id: I8654d8e97e74e1dff6d308c111ae4b1bbf07bef9
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.
Use the LOCALAPPDATA environment variable to determine the cache dir
when running on Windows with native command line, otherwise nasty
warning "Couldn't determine a path for index cached directory" appears.
Change-Id: I77903f9f0cb4743555866b8aea892cef55132589
A recent commit caused pathstuff.cc to fail to compile on mingw, like:
../../binutils-gdb/gdbsupport/pathstuff.cc:324:1: error: no previous declaration for 'std::string find_gdb_home_config_file(const char*, _stati64*)' [-Werror=missing-declarations]
Some newly-added #includes were changing which "stat" was being seen
by the compiler. This patch moves the includes to the header, so that
the declaration and definition now agree.
2020-11-10 Tom Tromey <tromey@adacore.com>
PR build/26848:
* pathstuff.h: Move include block here...
* pathstuff.cc: ... from here.
This commit effectively changes the default location of the .gdbinit
file, while maintaining backward compatibility.
For non Apple hosts the .gdbinit file will now be looked for in the
following locations:
$XDG_CONFIG_HOME/gdb/gdbinit
$HOME/.config/gdb/gdbinit
$HOME/.gdbinit
On Apple hosts the search order is instead:
$HOME/Library/Preferences/gdb/gdbinit
$HOME/.gdbinit
I've performed an extensive rewrite of the documentation, moving all
information about initialization files and where to find them into a
new @node, text from other areas has been moved into this one
location, and other areas cross-reference to this new @node as much as
possible.
gdb/ChangeLog:
* NEWS: Mention changes to config file search path.
* main.c
gdb/doc/ChangeLog:
* gdb.texinfo (Mode Options): Descriptions of initialization files
has been moved to 'Initialization Files'.
(Startup): Likewise.
(Initialization Files): New node.
(gdb man): Update to mention alternative file paths.
(gdbinit man): Likewise.
This adds a new get_standard_config_dir, which returns the name of the
configuration directory. In XDG, this is ~/.config/gdb/. Future
patches will make use of this.
2020-07-05 Tom Tromey <tom@tromey.com>
* pathstuff.h (get_standard_config_dir): Declare.
* pathstuff.cc (get_standard_config_dir): New function.
This patch renames the .c source files in gdbsupport to .cc.
In the gdb directory, there is an argument against renaming the source
files, which is that it makes using some git commands more difficult to
do archeology. Some commands have some kind of "follow" option that
makes git try to follow renames, but it doesn't work in all situations.
Given that we have just moved the gdbsupport directory, that argument
doesn't hold for source files in that directory. I therefore suggest
renaming them to .cc, so that they are automatically recognized as C++
by various tools and editors.
The original motivation behind this is that when building gdbsupport
with clang, I get:
CC agent.o
clang: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated]
In the gdb/ directory, we make clang happy by passing "-x c++". We
could do this in gdbsupport too, but I think that renaming the files is
a better long-term solution.
gdbserver still does its own build of gdbsupport, so a few changes in
its Makefile are necessary.
gdbsupport/ChangeLog:
* Makefile.am: Rename source files from .c to .cc.
(CC, CFLAGS): Don't override.
(AM_CFLAGS): Rename to ...
(AM_CXXFLAGS): ... this.
* Makefile.in: Re-generate.
* %.c: Rename to %.cc.
gdbserver/ChangeLog:
* Makefile.in: Rename gdbsupport source files from .c to .cc.
