This minimizes the "make" output from the yacc and lex rules,
following the same technique as the rest of the Makefile.
The lex rule had a special case to deal with the situation where flex
is not available. I don't think this is needed, so I removed it. If
flex is truly unavailable, the person building gdb can simply "touch"
the output file.
gdb/ChangeLog
2018-07-09 Tom Tromey <tom@tromey.com>
* Makefile.in (%.c: %.y): Use ECHO_YACC.
(%.c: %.l): Use ECHO_LEX. Just fail if flex not available.
* silent-rules.mk (ECHO_YACC, ECHO_LEX): New variables.
exec.c ws handled specially in COMMON_OBS, but there doesn't seem to
be a reason for this. This changes the Makefile to treat exec.c as an
ordinary source file.
gdb/ChangeLog
2018-07-09 Tom Tromey <tom@tromey.com>
* Makefile.in (ALLDEPFILES): Remove exec.c.
(COMMON_OBS): Remove exec.o.
(COMMON_SFILES): Add exec.c.
I don't think anyone uses lint any more, so this removes the support
for it from the Makefile.
gdb/ChangeLog
2018-07-09 Tom Tromey <tom@tromey.com>
* Makefile.in (LINT, LINTFLAGS, LINTFILES, lint): Remove.
This introduces a stamp file for version.c, preventing unnecessary
version.o rebuilds.
gdb/ChangeLog
2018-07-09 Tom Tromey <tom@tromey.com>
* Makefile.in (clean mostlyclean): Remove stamp-version.
(version.c): Depend on stamp-version.
(stamp-version): New rule, from version.c rule.
This introduces a stamp file for init.c. This prevents constant
rebuilds of init.o, by arranging for init.c to only be modified when
its contents change. (FWIW this is a standard idiom in use by
Automake and by gdb itself for many years.)
gdb/ChangeLog
2018-07-09 Tom Tromey <tom@tromey.com>
* Makefile.in (init.c): Depend on stamp-init.
(stamp-init): New rule, from init.c rule.
(clean mostlyclean): Remove stamp-init.
This simplifies the INIT_FILES variable. COMMON_OBS includes
CONFIG_OBS and SUBDIR_GCC_COMPILE_OBS, so there's no need to reference
CONFIG_OBS or SUBDIR_GCC_COMPILE_SRCS there. Once this is done, it it
clear that duplicates can't occur, so remove the duplicate-removing
code as well.
gdb/ChangeLog
2018-07-09 Tom Tromey <tom@tromey.com>
* Makefile.in (INIT_FILES): Remove CONFIG_SRCS,
SUBDIR_GCC_COMPILE_SRCS.
The init.c build rule has a few sed expressions that aren't necessary
any more. This removes them.
gdb/ChangeLog
2018-07-09 Tom Tromey <tom@tromey.com>
* Makefile.in (init.c): Remove some unused sed rules.
The TSOBS variable doesn't seem to serve a useful purpose in
gdb/Makefile.in, so remove it.
gdb/ChangeLog
2018-07-09 Tom Tromey <tom@tromey.com>
* Makefile.in (TSOBS): Remove.
(INIT_FILES): Update.
(LIBGDB_OBS): Update.
(COMMON_SFILES): Add inflow.c.
(SFILES): Remove inflow.c.
------------------------------------------------------------------------------
(gdb) help save gdb-index
Save a gdb-index file.
Usage: save gdb-index [-dwarf-5] DIRECTORY
No options create one file with .gdb-index extension for pre-DWARF-5
compatible .gdb_index section. With -dwarf-5 creates two files with
extension .debug_names and .debug_str for DWARF-5 .debug_names section.
------------------------------------------------------------------------------
But gdb-add-index command provided no way how to pass the -dwarf-5 option.
gdb/ChangeLog
2018-07-07 Jan Kratochvil <jan.kratochvil@redhat.com>
* contrib/gdb-add-index.sh ($dwarf5): New, use it.
This patch silences this warning:
/Users/simark/src/binutils-gdb/gdb/darwin-nat.c:839:10: error: 'syscall' is deprecated: first deprecated in macOS 10.12 - syscall(2) is unsupported; please switch to a supported interface. For SYS_kdebug_trace use kdebug_signpost(). [-Werror,-Wdeprecated-declarations]
res = syscall (SYS___pthread_kill, thread->gdb_port, nsignal);
^
/usr/include/unistd.h:745:6: note: 'syscall' has been explicitly marked deprecated here
int syscall(int, ...);
^
The comment of the new pthread_kill function explains why we use the
syscall function directly.
include/ChangeLog:
* diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_DECLARATIONS):
Define for clang.
gdb/ChangeLog:
* darwin-nat.c (darwin_pthread_kill): New function.
(darwin_resume_thread): Use darwin_pthread_kill.
When doing a combined build with the gcc and binutils-gdb repos, I run into
this build error in gdb:
...
gdb/macroexp.c: \
In function ‘void get_next_token_for_substitution(macro_buffer*, \
macro_buffer*, char**, macro_buffer*, char**, int*, bool*)’:
gdb/macroexp.c:925:17: error: \
implicitly-declared ‘constexpr macro_buffer& \
macro_buffer::operator=(const macro_buffer&)’ is deprecated \
[-Werror=deprecated-copy]
*token = *lookahead;
...
Wdeprecated-copy is a new gcc warning added after gcc 8.
This patch fixes the build error by adding an explicit copy operator to the
macro_buffer class. I've added asserts to ensure that both the dest and src
of the copy are shared, in other words, neither is owner of the text pointer.
I've run the gdb testsuite on x86_64-linux and the asserts did not trigger.
2018-07-05 Tom de Vries <tdevries@suse.de>
* macroexp.c (macro_buffer) <operator=>: New member function.
Commit a50c11c666 was intended to use exit_inferior in
darwin_attach_pid, but I accidentally pushed the wrong version of the
patch. This fixes the problem.
gdb/ChangeLog
2018-07-04 Tom Tromey <tom@tromey.com>
* darwin-nat.c (darwin_attach_pid): Use exit_inferior.
This patch gets rid of this warning on macOS:
CXX main.o
/Users/simark/src/binutils-gdb/gdb/main.c:492:27: error: 'sbrk' is deprecated [-Werror,-Wdeprecated-declarations]
lim_at_start = (char *) sbrk (0);
^
/usr/include/unistd.h:585:1: note: 'sbrk' has been explicitly marked deprecated here
__deprecated __WATCHOS_PROHIBITED __TVOS_PROHIBITED
^
/usr/include/sys/cdefs.h:176:37: note: expanded from macro '__deprecated'
#define __deprecated __attribute__((deprecated))
^
sbrk on macOS is not useful for our purposes, since sbrk(0) always
returns the same value. From what I read, brk/sbrk on macOS is just an
emulation, it always returns a pointer in a 4MB section reserved for
that.
So instead of letting users use "maint set per-command space on" and
print silly results, I think we should just disable that feature for
this platform (as we do for platforms that don't have sbrk).
I defined a HAVE_USEFUL_SBRK macro and used that instead of HAVE_SBRK.
gdb/ChangeLog:
* common/common-defs.h (HAVE_USEFUL_SBRK): Define.
* main.c: Use HAVE_USEFUL_SBRK instead of HAVE_SBRK.
* maint.c: Likewise.
* top.c: Likewise.
Now that the GDB 8.2 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 8.2 branch created (1b919490e8):
* version.in: Bump version to 8.2.50.DATE-git.
There's a buildroot where I want to debug a binary, and I tried to
connect to it from outside, but got very weird errors like
architecture mismatch or protocol errors. At last, after switching on
'--debug' for gdbserver I found a message 'Can't open /proc/pid/'
message and suddenly found that I forgot to mount procfs in my
buildroot.
Make discovering the problem easier by making GDB / GDBserver warn
(even without --debug) if /proc can not be accessed.
Native debugging:
(gdb) start
Temporary breakpoint 1 at 0x400835: file test.c, line 10.
Starting program: /tmp/test
warning: /proc is not accessible.
GDBserver/remote debugging:
$ ./gdbserver :9999 ./gdbserver
gdbserver: /proc is not accessible.
gdb/ChangeLog:
2018-07-04 Vyacheslav Barinov <v.barinov@samsung.com>
Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_init_ptrace): Rename to ...
(linux_init_ptrace_procfs): ... this. Call
linux_proc_init_warnings.
(linux_nat_target::post_attach)
(linux_nat_target::post_startup_inferior): Adjust.
* nat/linux-procfs.c (linux_proc_init_warnings): Define function.
* nat/linux-procfs.h (linux_proc_init_warnings): Declare function.
gdb/gdbserver/ChangeLog:
2018-07-04 Vyacheslav Barinov <v.barinov@samsung.com>
Pedro Alves <palves@redhat.com>
* linux-low.c (initialize_low): Call linux_proc_init_warnings.
The version check of the dwarf compilation unit header in
error_check_comp_unit_head is done too late, and consequently dwarf code with
an unsupported version in the compilation unit header is interpreted as dwarf5
code in read_comp_unit_head.
Fixed by moving the check earlier.
Build and reg-tested on x86_64-linux.
2018-07-04 Tom de Vries <tdevries@suse.de>
* dwarf2read.c (error_check_comp_unit_head): Move dwarf version
check ...
(read_comp_unit_head): ... here.
* gdb.dwarf2/dw2-error.exp: Update expected error message.
This removes a use of VEC from breakpoint.h, also removing the
now-unnecessary breakpoint_p typedef.
This patch fixes a latent memory leak in
find_matching_tracepoint_location, which neglected to free the vector
returned by all_tracepoints.
Tested by the buildbot.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* tracepoint.c (process_tracepoint_on_disconnect, start_tracing)
(stop_tracing, tstatus_command)
(find_matching_tracepoint_location, merge_uploaded_tracepoints)
(print_one_static_tracepoint_marker): Update.
* breakpoint.c (static_tracepoints_here, all_tracepoints): Return
std::vector.
* breakpoint.h (breakpoint_p): Remove typedef. Don't declare
VEC.
(all_tracepoints, static_tracepoints_here): Return std::vector.
The sole caller of exit_inferior_num_silent was getting the inferior's
number to then use the number to look up the inferior again. I think
it's better to simply not have exit_inferior_num_silent; any potential
callers that only have the inferior's number should probably be
converted to pass the inferior itself around instead.
Tested by the buildbot.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
* infrun.c (follow_exec): Use exit_inferior_silent.
* inferior.c (exit_inferior_num_silent): Remove.
* inferior.h (exit_inferior_num_silent): Don't declare.
On macOS, when gdb is not code-signed, it will throw an exception from
darwin_attach_pid. However, gdb also then crashes:
thread.c:93: internal-error: struct thread_info *inferior_thread(): Assertion `tp' failed.
I think the problem here is that darwin_attach_pid does not clean up
inferior_ptid and inf->pid on failure. This leads to a situation
where gdb tries to find a thread, but cannot.
In other cases, gdb would mourn the inferior at this point; but here
this is not possible because the target has not been pushed. Instead
this patch works by simply updating the inferior and inferior_ptid on
failure.
Tested by building an unsigned gdb on macOS and trying to run an
inferior.
gdb/ChangeLog
2018-07-03 Tom Tromey <tom@tromey.com>
PR cli/23340:
* darwin-nat.c (darwin_attach_pid): Reset inferior and
inferior_ptid on error.
Implement MIPS target support for passing options to the disassembler,
complementing commit 65b48a8140 ("GDB: Add support for the new
set/show disassembler-options commands.").
This includes options that expect an argument, so adjust the generic
code and data structures used so as to handle such options. So as to
give backends syntax flexibility no specific delimiter has been defined
to separate options from their respective arguments, so it has to be
included as the last character of the option name. Completion code
however has not been adjusted and consequently option arguments cannot
be completed at this time.
Also the MIPS target has non-empty defaults for the options, so that ABI
names for the general-purpose registers respect our `set mips abi ...'
setting rather than always being determined from the ELF headers of the
binary file selected. Handle these defaults as implicit options, never
shown to the user and always prepended to the user-specified options, so
that the latters can override the defaults.
The resulting output for the MIPS target is as follows:
(gdb) show disassembler-options
The current disassembler options are ''
The following disassembler options are supported for use with the
'set disassembler-options <option>[,<option>...]' command:
no-aliases Use canonical instruction forms.
msa Recognize MSA instructions.
virt Recognize the virtualization ASE instructions.
xpa Recognize the eXtended Physical Address (XPA) ASE
instructions.
ginv Recognize the Global INValidate (GINV) ASE instructions.
gpr-names=ABI Print GPR names according to specified ABI.
Default: based on binary being disassembled.
fpr-names=ABI Print FPR names according to specified ABI.
Default: numeric.
cp0-names=ARCH Print CP0 register names according to specified architecture.
Default: based on binary being disassembled.
hwr-names=ARCH Print HWR names according to specified architecture.
Default: based on binary being disassembled.
reg-names=ABI Print GPR and FPR names according to specified ABI.
reg-names=ARCH Print CP0 register and HWR names according to specified
architecture.
For the options above, the following values are supported for "ABI":
numeric 32 n32 64
For the options above, the following values are supported for "ARCH":
numeric r3000 r3900 r4000 r4010 vr4100 vr4111 vr4120 r4300 r4400 r4600
r4650 r5000 vr5400 vr5500 r5900 r6000 rm7000 rm9000 r8000 r10000 r12000
r14000 r16000 mips5 mips32 mips32r2 mips32r3 mips32r5 mips32r6 mips64
mips64r2 mips64r3 mips64r5 mips64r6 interaptiv-mr2 sb1 loongson2e
loongson2f loongson3a octeon octeon+ octeon2 octeon3 xlr xlp
(gdb)
which corresponds to what `objdump --help' used to print for the MIPS
target, with minor formatting changes, most notably option argument
lists being wrapped, but also the amount of white space separating
options from the respective descriptions. The relevant part the new
code is now also used by `objdump --help', which means these formatting
changes apply to both outputs, except for argument list wrapping, which
is GDB-specific.
This also adds a separating new line between the heading and option
lists where descriptions are provided, hence:
(gdb) set architecture s390:31-bit
(gdb) show disassembler-options
The current disassembler options are ''
The following disassembler options are supported for use with the
'set disassembler-options <option>[,<option>...]' command:
esa Disassemble in ESA architecture mode
zarch Disassemble in z/Architecture mode
insnlength Print unknown instructions according to length from first two bits
(gdb)
but:
(gdb) set architecture powerpc:common
(gdb) show disassembler-options
The current disassembler options are ''
The following disassembler options are supported for use with the
'set disassembler-options <option>[,<option>...]' command:
403, 405, 440, 464, 476, 601, 603, 604, 620, 7400, 7410, 7450, 7455, 750cl,
821, 850, 860, a2, altivec, any, booke, booke32, cell, com, e200z4, e300,
e500, e500mc, e500mc64, e5500, e6500, e500x2, efs, efs2, power4, power5,
power6, power7, power8, power9, ppc, ppc32, 32, ppc64, 64, ppc64bridge,
ppcps, pwr, pwr2, pwr4, pwr5, pwr5x, pwr6, pwr7, pwr8, pwr9, pwrx, raw, spe,
spe2, titan, vle, vsx
(gdb)
Existing affected target backends have been adjusted accordingly.
This has been verified manually with:
(gdb) set architecture arm
(gdb) set architecture powerpc:common
(gdb) set architecture s390:31-bit
to cause no issues with the `show disassembler-options' and `set
disassembler-options' commands. A test case for the MIPS target has
also been provided, covering the default settings with ABI overrides as
well as disassembler option overrides.
2018-07-02 Maciej W. Rozycki <macro@mips.com>
Simon Marchi <simon.marchi@polymtl.ca>
include/
PR tdep/8282
* dis-asm.h (disasm_option_arg_t): New typedef.
(disasm_options_and_args_t): Likewise.
(disasm_options_t): Add `arg' member, document members.
(disassembler_options_mips): New prototype.
(disassembler_options_arm, disassembler_options_powerpc)
(disassembler_options_s390): Update prototypes.
opcodes/
PR tdep/8282
* mips-dis.c (mips_option_arg_t): New enumeration.
(mips_options): New variable.
(disassembler_options_mips): New function.
(print_mips_disassembler_options): Reimplement in terms of
`disassembler_options_mips'.
* arm-dis.c (disassembler_options_arm): Adapt to using the
`disasm_options_and_args_t' structure.
* ppc-dis.c (disassembler_options_powerpc): Likewise.
* s390-dis.c (disassembler_options_s390): Likewise.
gdb/
PR tdep/8282
* disasm.h (gdb_disassembler): Add
`m_disassembler_options_holder'. member
* disasm.c (get_all_disassembler_options): New function.
(gdb_disassembler::gdb_disassembler): Use it.
(gdb_buffered_insn_length_init_dis): Likewise.
(gdb_buffered_insn_length): Adjust accordingly.
(set_disassembler_options): Handle options with arguments.
(show_disassembler_options_sfunc): Likewise. Add a leading new
line if showing options with descriptions.
(disassembler_options_completer): Adapt to using the
`disasm_options_and_args_t' structure.
* mips-tdep.c (mips_disassembler_options): New variable.
(mips_disassembler_options_o32): Likewise.
(mips_disassembler_options_n32): Likewise.
(mips_disassembler_options_n64): Likewise.
(gdb_print_insn_mips): Don't set `disassembler_options'.
(gdb_print_insn_mips_n32, gdb_print_insn_mips_n64): Remove
functions.
(mips_gdbarch_init): Always set `gdbarch_print_insn' to
`gdb_print_insn_mips'. Set `gdbarch_disassembler_options',
`gdbarch_disassembler_options_implicit' and
`gdbarch_valid_disassembler_options'.
* arm-tdep.c (_initialize_arm_tdep): Adapt to using the
`disasm_options_and_args_t' structure.
* gdbarch.sh (disassembler_options_implicit): New `gdbarch'
method.
(valid_disassembler_options): Switch from `disasm_options_t' to
the `disasm_options_and_args_t' structure.
* NEWS: Document `set disassembler-options' support for the MIPS
target.
* gdbarch.h: Regenerate.
* gdbarch.c: Regenerate.
gdb/doc/
PR tdep/8282
* gdb.texinfo (Source and Machine Code): Document `set
disassembler-options' support for the MIPS target.
gdb/testsuite/
PR tdep/8282
* gdb.arch/mips-disassembler-options.exp: New test.
* gdb.arch/mips-disassembler-options.s: New test source.
The "fp" register name is an alias for "s0" which is an alias for "x8".
The "fp" name is only understood by very recent Binutils and thus not
used by GCC. GCC does not emit a frame pointer with common optimization
options such as -Og or -O2.
It is still possible to use the "fp" register name, e.g.
(gdb) p/x $fp
$1 = 0x800367c8
works.
However, in the register dump you see now:
(gdb) info registers
...
t2 0xffffffffffffffff 18446744073709551615
s0 0x800367c8 0x800367c8
s1 0x80033280 2147693184
...
gdb/
* riscv-tdep.c (riscv_register_aliases): Swap "fp" and "s0"
entries.
The following patch caused some amd64-*-tdep files to fail to compile:
| commit de52b9607d
| Date: Tue Jun 26 16:33:27 2018 +0100
| Subject: x86_64-windows GDB crash due to fs_base/gs_base registers
This is because we added one additional "segments" argument to
function amd64_target_description and forgot to update all the callers.
This patch fixes the omissions.
gdb/ChangeLog:
* amd64-darwin-tdep.c (x86_darwin_init_abi_64): Add missing
parameter in call to amd64_target_description.
* amd64-dicos-tdep.c (amd64_dicos_init_abi): Likewise.
* amd64-fbsd-tdep.c (amd64fbsd_core_read_description)
(amd64fbsd_init_abi): Likewise.
* amd64-nbsd-tdep.c (amd64nbsd_init_abi): Likewise.
* amd64-obsd-tdep.c (amd64obsd_init_abi): Likewise.
* amd64-sol2-tdep.c (amd64_sol2_init_abi): Likewise.
* amd64-fbsd-nat.c (amd64_fbsd_nat_target): Likewise.
The change to amd64-fbsd-nat.c was done "blind" (no access to system),
but is reasonably straightforward. The changes to the -tdep.c files
were verify by rebuilding GDB on x86_64-linux when configured with
--enable-targets=all.
GDB is currently crashing anytime we try to access the fs_base/gs_base
registers, either to read them, or to write them. This can be observed
under various scenarios:
- Explicit reference to those registers (eg: print $fs_base) --
probably relatively rare;
- Calling a function in the inferior, with the crash happening
because we are trying to read those registers in order to save
their value ahead of making the function call;
- Just a plain "info registers";
The crash was introduced by the following commit:
| commit 48aeef91c2
| Date: Mon Jun 26 18:14:43 2017 -0700
| Subject: Include the fs_base and gs_base registers in amd64 target descriptions.
The Windows-nat implementation was unfortunately not prepared to deal
with those new registers. In particular, the way it fetches registers
is done by using a table where the index is the register number, and
the value at that index is the offset in the area in the thread's CONTEXT
data where the corresponding register value is stored.
For instance, in amd64-windows-nat.c, we can find the mappings static
array containing the following 57 elements in it:
#define context_offset(x) (offsetof (CONTEXT, x))
static const int mappings[] =
{
context_offset (Rax),
[...]
context_offset (FloatSave.MxCsr)
};
That array is then used by windows_fetch_one_register via:
char *context_offset = ((char *) &th->context) + mappings[r];
The problem is that fs_base's register number is 172, which is
well past the end of the mappings array (57 elements in total).
We end up getting an undefined offset, which happens to be so large
that it then causes the address where we try to read the register
value (a little bit later) to be invalid, thus crashing GDB with
a SEGV.
This patch side-steps the issue entirely by removing support for
those registers in GDB on x86_64-windows, because a look at the
CONTEXT structure indicates no support for getting those registers.
A more comprehensive fix would patch the potential buffer overflow
of the mappings array, but this can be done as a separate commit.
gdb/ChangeLog:
* gdb/amd64-tdep.h (amd64_create_target_description): Add
"segments" parameter.
* gdb/amd64-tdep.c (amd64_none_init_abi, amd64_x32_none_init_abi)
(_initialize_amd64_tdep): Update call to
amd64_create_target_description.
(amd64_target_description): Add "segments" parameter. Adjust
the implementation to use it.
* gdb/amd64-linux-tdep.c (amd64_linux_read_description): Update
call to amd64_create_target_description.
* gdb/amd64-windows-tdep.c (amd64_windows_init_abi): Likewise.
* gdb/arch/amd64.h (amd64_create_target_description): Add
"segments" register.
* gdb/arch/amd64.c (amd64_create_target_description): Add
"segments" parameter. Call create_feature_i386_64bit_segments
only if SEGMENTS is true.
* gdb/gdbserver/win32-i386-low.c (i386_arch_setup): Update
call to amd64_create_target_description.
Tested on x86_64-windows using AdaCore's testsuite (by Joel Brobecker
<brobecker at adacore dot com>).
It's long annoyed me that "info threads"'s columns are misaligned.
Particularly the "Target Id" column's content is usually longer than
the specified column width, so the table ends up with the "Frame"
column misaligned. For example, currently we get this:
(gdb) info threads
Id Target Id Frame
1 Thread 0x7ffff7fb5740 (LWP 9056) "threads" 0x00007ffff7bc28ad in __pthread_join (threadid=140737345763072, thread_return=0x7fffffffd3e8) at pthread_join.c:90
2 Thread 0x7ffff7803700 (LWP 9060) "function0" thread_function0 (arg=0x0) at threads.c:90
* 3 Thread 0x7ffff7002700 (LWP 9061) "threads" thread_function1 (arg=0x1) at threads.c:106
The fact that the "Frame" heading is in a weird spot is particularly
annoying.
This commit turns the above into into this:
(gdb) info threads
Id Target Id Frame
1 Thread 0x7ffff7fb5740 (LWP 7548) "threads" 0x00007ffff7bc28ad in __pthread_join (threadid=140737345763072, thread_return=0x7fffffffd3e8) at pthread_join.c:90
2 Thread 0x7ffff7803700 (LWP 7555) "function0" thread_function0 (arg=0x0) at threads.c:91
* 3 Thread 0x7ffff7002700 (LWP 7557) "threads" thread_function1 (arg=0x1) at threads.c:104
It does that by computing the max width of the "Target Id" column and
using that as column width when creating the table.
This results in calling target_pid_to_str / target_extra_thread_info /
target_thread_name twice for each thread, but I think that it doesn't
matter in practice performance-wise, because the remote target caches
the info, and with native targets it shouldn't be noticeable. It
could matter if we have many threads (say, thousands), but then "info
threads" is practically useless in such a scenario anyway -- better
thread filtering and aggregation would be necessary.
(Note: I have an old branch somewhere where I attempted at making
gdb's "info threads"-like tables follow a model/view design, so that a
general framework took care of issues like these, but it's incomplete
and a much bigger change. This patch doesn't prevent going in that
direction in the future, of course.)
gdb/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* thread.c (thread_target_id_str): New, factored out from ...
(print_thread_info_1): ... here. Use it to compute the max
"Target Id" column width.
gdb/testsuite/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* gdb.threads/names.exp: Adjust expected "info threads" output.
The following patch will make "info threads" call target_extra_thread_info
more frequently. When I looked at the remote implementation, I noticed
that if we're not using qXfer:threads:read, then we'd be increasing the
remote protocol traffic. This commit prevents that from happening.
Also, it removes a gratuitous local static buffer, which seems good on
its own.
gdb/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* remote.c (remote_target::extra_thread_info): Delete
'display_buf' and 'n' locals. from the cache, regardless of
packet mechanims is in use. Use cache for qThreadExtra and qP
methods too.
While experimenting with the previous patch, I noticed this inconsistency
in GDB's output:
(gdb) b 32
Breakpoint 1 at 0x40062f: file inline-break.c, line 32. (1)
(gdb) r
....
Breakpoint 1, func1 (x=1) at inline-break.c:32 (2)
32 return x * 23; /* break here */
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x40062f in main at inline-break.c:32 (3)
breakpoint already hit 1 time
(gdb)
Notice that when the breakpoint as set, GDB showed "inline-break.c,
line 32" (1), the same line number that was specified in the command.
When we run to the breakpoint, we present the stop at the same line
number, and correctly show "func1" as the function name (2).
But in "info break" output (3), notice that we say "in main", not "in
func1".
The same thing happens if you set a breakpoint by address. I.e.:
(gdb) b *0x40062f
Breakpoint 2 at 0x40062f: file inline-break.c, line 32.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x000000000040062f in main at inline-break.c:32
(gdb) r
....
Breakpoint 2, func1 (x=1) at inline-break.c:32
32 return x * 23; /* break here */
The problem is that the breakpoints were set at an inline function,
but when we set such a breakpoint by line number or address, we don't
record the functions symbol in the sal, and as consequence the
breakpoint location does not have an associated symbol either.
Then, in print_breakpoint_location, if the location does not have a
symbol, we call find_pc_sect_function to find one, and this is what
finds "main", because find_pc_sect_function uses
block_linkage_function:
/* Return the symbol for the function which contains a specified
lexical block, described by a struct block BL. The return value
will not be an inlined function; the containing function will be
returned instead. */
struct symbol *
block_linkage_function (const struct block *bl)
To fix this, this commit adds an alternative to find_pc_sect_function
that uses block_containing_function instead:
/* Return the symbol for the function which contains a specified
block, described by a struct block BL. The return value will be
the closest enclosing function, which might be an inline
function. */
struct symbol *
block_containing_function (const struct block *bl)
(It seems odd to me that block_linkage_function says "the CONTAINING
function will be returned", and then block_containing_function says it
returns "the closest enclosing function". Something seems reversed
here. Still, I've kept the same nomenclature and copied the comments,
so that at least there's consistency. Maybe we should fix that up
somehow.)
Then I wondered, why make print_breakpoint_location look up the symbol
every time it is called, instead of just always storing the symbol
when the location is created, since the location already stores the
symbol in some cases. So to find which cases might be missing setting
the symbol in the sal which is used to create the breakpoint location,
I added an assertion to print_breakpoint_location, and ran the
testsuite. That caught a few places, unsurprisingly:
- setting a breakpoint by line number
- setting a breapoint by address
- ifunc resolving
Those are all fixed by this commit. I decided not to add the
assertion to block_linkage_function and leave the existing "if (sym)"
check in place, because it's plausible that we have symtabs with line
info but no symbols. I.e., that would not be a GDB bug, but
a peculiarity of debug info input.
gdb/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* blockframe.c (find_pc_sect_containing_function): New function.
* breakpoint.c (print_breakpoint_location): Don't call
find_pc_sect_function.
* linespec.c (create_sals_line_offset): Record the location's
symbol in the sal.
* linespec.c (convert_address_location_to_sals): Fill in sal's
symbol with find_pc_sect_containing_function.
* symtab.c (find_function_start_sal): Rename to ...
(find_function_start_sal_1): ... this.
(find_function_start_sal): Reimplement as wrapper around
find_function_start_sal_1, and use
find_pc_sect_containing_function to fill in the sal's symbol.
(find_function_start_sal(symbol*, bool)): Adjust.
* symtab.h (find_pc_function, find_pc_sect_function): Adjust
comments.
(find_pc_sect_containing_function): Declare.
gdb/testsuite/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* gdb.opt/inline-break.exp (line number, address): Add "info
break" tests.
Commit 61b04dd04a ("Change inline frame breakpoint skipping logic
(fix gdb.gdb/selftest.exp)") caused a GDB crash when you set a
breakpoint by line number in an inline function, and then run to the
breakpoint:
$ gdb -q test Reading symbols from test...done.
(gdb) b inline-break.c:32
Breakpoint 1 at 0x40062f: file inline-break.c, line 32.
(gdb) run
Starting program: /[...]/test
[1] 75618 segmentation fault /[...]/gdb -q test
The problem occurs because we assume that a bp_location's symbol is
not NULL, which is not true when we set the breakpoint with a linespec
location:
Program received signal SIGSEGV, Segmentation fault.
0x00000000006f42bb in stopped_by_user_bp_inline_frame (
stop_chain=<optimized out>, frame_block=<optimized out>)
at gdb/inline-frame.c:305
305 && frame_block == SYMBOL_BLOCK_VALUE (loc->symbol))
(gdb) p loc->symbol
$1 = (const symbol *) 0x0
The same thing happens if you run to a breakpoint set in an inline
function by address:
(gdb) b *0x40062f
Breakpoint 3 at 0x40062f: file inline-break.c, line 32.
To fix this, add a null pointer check, to avoid the crash, and make it
so that if there's no symbol for the location, then we present the
stop at the inline function. This preserves the previous behavior
when e.g., setting a breakpoint by address, with "b *ADDRESS".
gdb/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* inline-frame.c (stopped_by_user_bp_inline_frame): Return
true if the the location has no symbol.
gdb/testsuite/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* gdb.opt/inline-break.c (func1): Add "break here" marker.
* gdb.opt/inline-break.exp: Test setting breakpoints by line
number and address and running to them.
macOS requires that the gdb executable be signed in order to be able
to successfully use ptrace. This must be done after each link.
This patch adds a new --enable-codesign configure option so that this
step can be automated.
gdb/ChangeLog
2018-06-28 Tom Tromey <tom@tromey.com>
* NEWS: Mention --enable-codesign.
* silent-rules.mk (ECHO_SIGN): New variable.
* configure.ac: Add --enable-codesign.
* configure: Rebuild.
* Makefile.in (CODESIGN, CODESIGN_CERT): New variables.
(gdb$(EXEEXT)): Optionally invoke codesign.
In my multi-target work, I need to add a few more
scoped_restore_current_thread and switch_to_thread calls in some
places, and in some lower-level places I was fighting against the fact
that switch_to_thread reads/refreshes the stop_pc global.
Instead of piling on workarounds, let's just finally eliminate the
stop_pc global. We already have the per-thread
thread_info->suspend.stop_pc field, so it's mainly a matter of using
that more/instead.
gdb/ChangeLog:
2018-06-28 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct thread_suspend_state) <stop_pc>: Extend
comments.
(switch_to_thread_no_regs): Adjust comment.
* infcmd.c (stop_pc): Delete.
(post_create_inferior, info_program_command): Replace references
to stop_pc with references to thread_info->suspend.stop_pc.
* inferior.h (stop_pc): Delete declaration.
* infrun.c (proceed, handle_syscall_event, fill_in_stop_func)
(handle_inferior_event_1, handle_signal_stop)
(process_event_stop_test, keep_going_stepped_thread)
(handle_step_into_function, handle_step_into_function_backward)
(print_stop_location): Replace references to stop_pc with
references to thread_info->suspend.stop_pc.
(struct infcall_suspend_state) <stop_pc>: Delete field.
(save_infcall_suspend_state, restore_infcall_suspend_state):
Remove references to inf_stat->stop_pc.
* linux-fork.c (fork_load_infrun_state): Likewise.
* record-btrace.c (record_btrace_set_replay): Likewise.
* record-full.c (record_full_goto_entry): Likewise.
* remote.c (print_one_stopped_thread): Likewise.
* target.c (target_resume): Extend comment.
* thread.c (set_executing_thread): New.
(set_executing): Use it.
(switch_to_thread_no_regs, switch_to_no_thread, switch_to_thread):
Remove references to stop_pc.
After commit 00431a78b2 ("Use thread_info and inferior pointers more
throughout"), following an exec can result in gdb crashing. On some
systems, this is visible with gdb.multi/multi-arch-exec.exp and
gdb.base/foll-exec-mode.exp. E.g.:
$ make check TESTS="gdb.multi/multi-arch-exec.exp gdb.base/foll-exec-mode.exp"
[snip]
FAIL: gdb.multi/multi-arch-exec.exp: first_arch=1: selected_thread=1: follow_exec_mode=new: continue across exec that changes architecture (GDB internal error)
ERROR: : spawn id exp10 not open
while executing
Running multi-arch-exec under Valgrind we easily spot the problem:
process 16305 is executing new program: ..../gdb.multi/multi-arch-exec/1-multi-arch-exec-hello
[New inferior 2 (process 0)]
[New process 16305]
==16129== Invalid read of size 8
==16129== at 0x7FA14D: get_thread_regcache(thread_info*) (regcache.c:399)
==16129== by 0x75E54B: handle_inferior_event_1(execution_control_state*) (infrun.c:5292)
==16129== by 0x75E82D: handle_inferior_event(execution_control_state*) (infrun.c:5382)
==16129== by 0x75BC6A: fetch_inferior_event(void*) (infrun.c:3918)
==16129== by 0x748DA3: inferior_event_handler(inferior_event_type, void*) (inf-loop.c:43)
==16129== by 0x464B5D: handle_target_event(int, void*) (linux-nat.c:4359)
==16129== by 0x7047E0: handle_file_event(file_handler*, int) (event-loop.c:733)
==16129== by 0x704D83: gdb_wait_for_event(int) (event-loop.c:859)
==16129== by 0x703BF6: gdb_do_one_event() (event-loop.c:322)
==16129== by 0x703CA2: start_event_loop() (event-loop.c:371)
==16129== by 0x791D95: captured_command_loop() (main.c:330)
==16129== by 0x79311C: captured_main(void*) (main.c:1157)
==16129== Address 0x15a5bad0 is 32 bytes inside a block of size 600 free'd
==16129== at 0x4C2E1E8: operator delete(void*) (vg_replace_malloc.c:576)
==16129== by 0x8A15D0: delete_thread_1(thread_info*, bool) (thread.c:465)
==16129== by 0x8A15FA: delete_thread(thread_info*) (thread.c:476)
==16129== by 0x8A0D43: add_thread_silent(ptid_t) (thread.c:291)
==16129== by 0x8A0DF0: add_thread_with_info(ptid_t, private_thread_info*) (thread.c:317)
==16129== by 0x8A0E79: add_thread(ptid_t) (thread.c:331)
==16129== by 0x75764C: follow_exec(ptid_t, char*) (infrun.c:1233)
==16129== by 0x75E534: handle_inferior_event_1(execution_control_state*) (infrun.c:5290)
==16129== by 0x75E82D: handle_inferior_event(execution_control_state*) (infrun.c:5382)
==16129== by 0x75BC6A: fetch_inferior_event(void*) (infrun.c:3918)
==16129== by 0x748DA3: inferior_event_handler(inferior_event_type, void*) (inf-loop.c:43)
==16129== by 0x464B5D: handle_target_event(int, void*) (linux-nat.c:4359)
The problem is that handle_inferior_event_1 is reading the stop_pc off
of a thread that was deleted by follow_exec. Before commit
00431a78b2, we didn't crash because we were passing down a ptid to
get_thread_regcache instead of ecs->event_thread.
Fix this by simply moving the stop_pc reading until after
ecs->event_thread is refreshed.
gdb/ChangeLog:
2018-06-28 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event_1) <TARGET_WAITKIND_EXECD>:
Moving fetching stop_pc until after ecs->event_thread is refreshed.
I noticed that dwarf2_free_objfile can be made static, by changing it
to be a registry cleanup function. This simplifies the code, as well,
because now symbol readers don't have to explicitly call it.
Tested by the buildbot.
gdb/ChangeLog
2018-06-28 Tom Tromey <tom@tromey.com>
* coffread.c (coff_symfile_finish): Update.
* xcoffread.c (xcoff_symfile_finish): Update.
* elfread.c (elf_symfile_finish): Update.
* symfile.h (dwarf2_free_objfile): Don't declare.
* dwarf2read.c (_initialize_dwarf2_read): Use
register_objfile_data_with_cleanup.
(dwarf2_free_objfile): Now static. Change signature.
If all sections of a symbol file are loaded with a fixed offset, it
is easier to specify that offset than listing all sections
explicitly. There is also a similar option for "symbol-file".
gdb/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* symfile.c (add_symbol_file_command, _initialize_symfile): Add
option "-o" to add-symbol-file-load to add an offset to each
section's load address.
* symfile.c (set_objfile_default_section_offset): New function.
gdb/doc/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* gdb.texinfo (Files): Document "add-symbol-file -o offset".
gdb/testsuite/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* gdb.base/relocate.exp: Add test for "add-symbol-file -o ".
Symbol files may contain multiple sections with the same name.
Section addresses specified by add-symbol-file are assigned to the
corresponding BFD sections in addr_info_make_relative using sorted
indexes of both vectors. Since the sort algorithm is not inherently
stable, the comparison function uses sectindex to maintain the
original order. However, add_symbol_file_command uses zero for all
sections, so if the user specifies multiple sections with the same
name, they will be assigned randomly to symbol file sections with
the same name.
gdb/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* symfile.c (add_symbol_file_command): Make sure that sections
The (first) .text section must be always specified as the second
non-option argument. The documentation states that GDB cannot
figure out this address by itself. This is true if the object file
was indeed relocated, but it is also confusing, because all other
sections can be omitted and will use the address provided by BFD.
gdb/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* symfile.c (add_symbol_file_command, _initialize_symfile): Do not
require the second argument. If omitted, load sections at the
addresses specified in the file.
gdb/doc/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* gdb.texinfo (Files): The address argument for "add-symbol-file"
is no longer mandatory.
gdb/testsuite/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* gdb.base/relocate.exp: Test add-symbol-file behavior when the
address argument is omitted.
If the main file is relocated at runtime, all symbols are offset by
a fixed amount. Let the user specify this offset when loading a
symbol file.
gdb/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* symfile.c (symbol_file_command, symbol_file_add_main_1)
(_initialize_symfile): Add option "-o" to symbol-file to add an
offset to each section of the symbol file.
gdb/doc/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* gdb.texinfo (Files): Document "symbol-file -o offset".
gdb/testsuite/ChangeLog:
2018-06-28 Petr Tesarik <ptesarik@suse.cz>
* gdb.base/relocate.exp: Add test for "symbol-file -o ".
In my earlier series to change help text to follow the GNU standards
for metasyntactic variables, I missed one: the "func" command. This
patch updates its help text.
Tested by the buildbot.
gdb/ChangeLog
2018-06-27 Tom Tromey <tom@tromey.com>
* stack.c (_initialize_stack): Update "func" help text.
This removes a use of VEC from py-unwind.c, replacing it wit
std::vector. It also changes saved_regs to hold a gdbpy_ref<>,
simplifying the memory management.
Tested against gdb.python on x86-64 Fedora 26.
gdb/ChangeLog
2018-06-27 Tom Tromey <tom@tromey.com>
* python/py-unwind.c (unwind_info_object) <saved_regs>: Now a
std::vector.
(unwind_infopy_str, pyuw_create_unwind_info)
(unwind_infopy_add_saved_register, pyuw_sniffer)
(unwind_infopy_dealloc, unwind_infopy_add_saved_register):
Update.
(struct saved_reg): Add constructor.
<value>: Now a gdbpy_ref<>.
Tom Tromey
Jan Kratochvil
Simon Marchi
Tom de Vries
Joel Brobecker
Vyacheslav Barinov
Maciej W. Rozycki
Sebastian Huber
Pedro Alves
Petr Tesarik