The common code already calls this, so no need to do so in arch dirs.
We leave the calls that disable -Werror. This will help unify the
configure scripts.
The current setting assumes that gnulib is only used by dirs
immediately under the source root. Trying to build it two or
more levels deep fails. Switch GNULIB_BUILDDIR to a relative
GNULIB_PARENT_DIR so that it can be used to construct both the
build & source paths.
Use procctl(2) with PROC_ASLR_CTL to disable address space
randomization in the current gdb process before forking a child
process for a new inferior when address space randomization is
disabled.
gdb/ChangeLog:
* configure.ac: Check for <sys/procctl.h>.
* config.in, configure: Regenerate.
* fbsd-nat.c: Include <sys/procctl.h> if present.
[PROC_ASLR_CTL] (maybe_disable_address_space_randomization): New.
(fbsd_nat_target::create_inferior)
(fbsd_nat_target::supports_disable_randomization): New.
* fbsd-nat.h (fbsd_nat_target::create_inferior)
(fbsd_nat_target::supports_disable_randomization): New.
This commit fixes a test coverage regression caused by:
commit b001de2320
Author: Andrew Burgess <andrew.burgess@embecosm.com>
AuthorDate: Mon Nov 26 17:56:39 2018 +0000
Commit: Andrew Burgess <andrew.burgess@embecosm.com>
CommitDate: Wed Dec 12 17:33:52 2018 +0000
gdb: Update test pattern to deal with native-extended-gdbserver
While looking at a regression caused by a local patch I was working
on, I noticed this:
pre-prompt
(gdb)
prompt
PASS: gdb.base/annota1.exp: breakpoint info
PASS: gdb.base/annota1.exp: run until main breakpoint
run
post-prompt
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.base/annota1/annota1
next
Note how above, we get the "run until main breakpoint" pass even
before "run" shows up in the log! The issue is that the test isn't
really testing anything, it always passes regardless of the gdb
output.
There are a few problems here, fixed by this commit:
- using {} to build the list for [join], when the strings we're
joining include variable names that must be expanded. Such list
need to be built with [list] instead.
- [join] joins strings with a space character by default. We need to
pass the empty string as second parameter so that it just concats
the strings.
- doing too much in a "-re" (calling procedures), which doesn't work
correctly. I've seen this before and never digged deeper into why.
Probably something to do with how gdb_test_multiple is implemented.
Regardless, easy and clear enough to build the pattern first into a
variable.
gdb/testsuite/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* gdb.base/annota1.exp: Build list using [list] instead of {}.
Tell [join] to join with no character. Build expected pattern in
separate variable instead of in the -re expression directly.
Change-Id: Ib3c89290f0e9ae4a0a43422853fcd4a7a7e12b18
If you look at the type used for implicit_const objects in binutils/dwarf.c,
you'll get sometimes bfd_signed_vma and sometimes dwarf_signed_vma.
They are the same on 64-bit hosts, but not on 32-bit hosts, and the latter
discrepancy, in particular in process_abbrev_set, is responsible for the
following error issued by objdump on some object files containing DWARF 5:
binutils/dwarf.c:1108: read LEB value is too large to store in destination
variable
binutis/
* dwarf.c (struct abbrev_attr): Change type of implicit_const.
(add_abbrev_attr): Likewise.
(process_abbrev_set): Likewise.
(display_debug_abbrev): Adjust to above change.
This allows binutils to build with musl gettext rather than falling
back to the bundled version.
[0] https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=b67399b4
2021-06-13 Michael Forney <mforney@mforney.org>
config/ChangeLog:
* gettext.m4 (AM_GNU_GETTEXT): Skip checks for the internal
symbols _nl_msg_cat_cntr, _nl_domain_bindings, and
_nl_expand_alias, if __GNU_GETTEXT_SUPPORTED_REVISION is defined.
Backport of gettext serial 68 patch.
intl/ChangeLog:
* configure: Regenerate.
---
Thi
I've been repeatedly confused by, in particular, the .dc.a potable[]
entry being conditional. Grepping in gas/config/ reveals only very few
targets actually #define-ing it. But as of 7be1c4891a the symbol is
always defined, so #ifdef-s are pointless (and, as said, potentially
confusing).
Also adjust documentation to reflect this.
The common sim-profile option controls whether to keep track of
runtime execution (like cycle count), so switch the rx-specific
cycle-stats option over to that.
Currently, the sim-config module will abort if alignment settings
haven't been specified by the port's configure.ac. This is a bit
weird when we've allowed SIM_AC_OPTION_ALIGNMENT to seem like it's
optional to use. Thus everyone invokes it.
There are 4 alignment settings, but really only 2 matters: strict
and nonstrict. The "mixed" setting is just the default ("unset"),
and "forced" isn't used directly by anyone (it's available as a
runtime option for some ports).
The m4 macro has 2 args: the "wire" settings (which represents the
hardwired port behavior), and the default settings (which are used
if nothing else is specified). If none are specified, then the
build won't work (see above as if SIM_AC_OPTION_ALIGNMENT wasn't
called). If default settings are provided, then that is used, but
we allow the user to override at runtime. Otherwise, the "wire"
settings are used and user runtime options to change are ignored.
Most ports specify a default, or set the "wire" to nonstrict. A
few set "wire" to strict, but it's not clear that's necessary as
it doesn't make the code behavior, by default, any different. It
might make things a little faster, but we should provide the user
the choice of the compromises to make: force a specific mode at
compile time for faster runtime, or allow the choice at runtime.
More likely it seems like an oversight when these ports were
initially created, and/or copied & pasted from existing ports.
With all that backstory, let's get to what this commit does.
First kill off the idea of a compile-time default alignment and
set it to nonstrict in the common code. For any ports that want
strict alignment by default, that code is moved to sim_open while
initializing the sim. That means WITH_DEFAULT_ALIGNMENT can be
completely removed.
Moving the default alignment to the runtime also allows removal
of setting the "wire" settings at configure time. Which allows
removing of all arguments to SIM_AC_OPTION_ALIGNMENT and moving
that call to common code.
The macro logic can be reworked to not pass WITH_ALIGNMENT as -D
CPPFLAG and instead move it to config.h.
All of these taken together mean we can hoist the macro up to the
top level and share it among all sims so behavior is consistent
among all the ports.
Move these options up to the common dir so we only test & export
them once across all ports. The AC_INIT macro does a lot of the
heavy lifting already which allows further simplification.
Move these options up to the common dir so we only test & export
them once across all ports.
The ppc code needs a little extra care with its trace settings as
it's not exactly the same API as the common code. The other knobs
are the same though.
Since ppc now shares a config.h with the top-level, move all of its
relevant settings up a level. The ppc port tests a lot more funcs,
but that's because its syscall emulation is a lot more complete.
We'll probably utilize some of these in the common code too.
gdb/remote.c:14541:5: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation]
if (current_inferior ()->in_initial_library_scan)
^
gdb/remote.c:14527:3: note: previous statement is here
if (remote == nullptr)
^
gdb/ChangeLog:
* remote.c (remote_new_objfile): Fix indentation.
The ppc port doesn't share a lot of the common logic, but there are
a few bits that bleed across. Have it use the common configure for
environment settings too to avoid duplicate define errors after the
recent unification with the other ports.
Move the various platform tests up a level to avoid duplication
across the ports. When building multiple versions, this speeds
things up a bit.
For now we move the obvious stuff up a level, but we don't turn
own the config.h entirely just yet -- we still have some tests
related to libraries that need consideration.
Fix commit 4de91c10cd, which cached the single section header read
to pick up file header extension fields. Also, testing e_shoff in
get_section_headers opened a hole for fuzzers where we'd end up with
segfaults due to non-zero e_shnum but NULL section_headers.
* readelf.c (get_section_headers): Don't test e_shoff here, leave
that to get_32bit_section_headers or get_64bit_section_headers.
(process_object): Throw away section header read to print file
header extension.
Loading libc.so's symbols increased the amount of time needed for
114-symbol-info-function to fetch symbols, causing a timeout during my
testing. I enclosed the entire block with a "with_timeout_factor 4",
which fixes the problem for me. (Using 2 also fixed it for me, but it
might not be enough when running this test on slower machines.)
gdb/testsuite/ChangeLog:
* gdb.mi/mi-sym-info.exp (114-symbol-info-function test): Increase
timeout.
One consequence of changing libpthread_name_p() in solib.c to (also)
match libc is that the symbols for libc will now be loaded by
solib_add() in solib.c. I think this is mostly harmless because
we'll likely want these symbols to be loaded anyway, but it did cause
two failures in gdb.base/print-symbol-loading.exp.
Specifically...
1)
sharedlibrary .*
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
now looks like this:
sharedlibrary .*
Symbols already loaded for /lib64/libc.so.6
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
2)
sharedlibrary .*
Loading symbols for shared libraries: .*
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib brief: load shared-lib
now looks like this:
sharedlibrary .*
Loading symbols for shared libraries: .*
Symbols already loaded for /lib64/libc.so.6
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib brief: load shared-lib
Fixing case #2 ended up being easier than #1. #1 had been using
gdb_test_no_output to correctly match this no-output case. I
ended up replacing it with gdb_test_multiple, matching the exact
expected output for each of the two now acceptable cases.
For case #2, I simply added an optional non-capturing group
for the potential new output.
gdb/testsuite/ChangeLog:
* gdb.base/print-symbol-loading.exp (proc test_load_shlib):
Allow "Symbols already loaded for..." messages.
When using glibc-2.34, we now see messages related to the loading of
the thread library for non-thread programs. E.g. for the test case,
gdb.base/execl-update-breakpoints.exp, we will see the following when
starting the program:
(gdb) break -qualified main
Breakpoint 1 at 0x100118c: file /ironwood1/sourceware-git/f34-2-glibc244_fix/bld/../../worktree-glibc244_fix/gdb/testsuite/gdb.base/execl-update-breakpoints.c, line 34.
(gdb) run
Starting program: [...]/execl-update-breakpoints1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
The two lines of output related to libthread_db are new; we didn't see
these in the past. This is a side effect of libc now containing the
pthread API - we can no longer tell whether the program is
multi-threaded by simply looking for libpthread.so. That said, I
think that we now want to load libthread_db anyway since it's used to
resolve TLS variables; i.e. we need it for correctly determining the
value of errno.
This commit adds the necessary regular expressions to match this
(optional) additional output in the two tests which were failing
without it.
gdb/testsuite/ChangeLog:
* gdb.base/execl-update-breakpoints.exp: Add regular
expression for optionally matching output related to
libthread_db.
* gdb.base/fork-print-inferior-events.exp: Likewise.
This commit makes some adjustments to accomodate the upcoming
glibc-2.34 release. Beginning with glibc-2.34, functionality formerly
contained in libpthread has been moved to libc. For the time being,
libpthread.so still exists in the file system, but it won't show up in
ldd output and therefore won't be able to trigger initialization of
libthread_db related code. E.g...
Fedora 34 / glibc-2.33.9000:
[kev@f34-2 gdb]$ ldd testsuite/outputs/gdb.threads/tls/tls
linux-vdso.so.1 (0x00007ffcf94fa000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff0ba9af000)
libm.so.6 => /lib64/libm.so.6 (0x00007ff0ba8d4000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff0ba8b9000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff0ba6c6000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff0babf0000)
Fedora 34 / glibc-2.33:
[kev@f34-1 gdb]$ ldd testsuite/outputs/gdb.threads/tls/tls
linux-vdso.so.1 (0x00007fff32dc0000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f815f6de000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f815f4bf000)
libm.so.6 => /lib64/libm.so.6 (0x00007f815f37b000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f815f360000)
libc.so.6 => /lib64/libc.so.6 (0x00007f815f191000)
/lib64/ld-linux-x86-64.so.2 (0x00007f815f721000)
Note that libpthread is missing from the ldd output for the
glibc-2.33.9000 machine.
This means that (unless we happen to think of some entirely different
mechanism), we'll now need to potentially match "libc" in addition to
"libpthread" as libraries which might be thread libraries. This
accounts for the change made in solib.c. Note that the new code
attempts to match "/libc." via strstr(). That trailing dot (".")
avoids inadvertently matching libraries such as libcrypt (and
all the other many libraries which begin with "libc").
To avoid attempts to load libthread_db when encountering older
versions of libc, we now attempt to find "pthread_create" (which is a
symbol that we'd expect to be in any pthread library) in the
associated objfile. This accounts for the changes in
linux-thread-db.c.
I think that other small adjustments will need to be made elsewhere
too. I've been working through regressions on my glibc-2.33.9000
machine; I've fixed some fairly "obvious" changes in the testsuite
(which are in other commits). For the rest, it's not yet clear to me
whether the handful of remaining failures represent a problem in glibc
or gdb. I'm still investigating, however, I'll note that these are
problems that I only see on my glibc-2.33.9000 machine.
gdb/ChangeLog:
* solib.c (libpthread_name_p): Match "libc" in addition
to "libpthread".
* linux-thread-db.c (libpthread_objfile_p): New function.
(libpthread_name_p): Adjust preexisting callers to use
libpthread_objfile_p().
This is unused (and was event when it was introduced). Remove it.
gdb/ChangeLog:
* dwarf2/loc.h (struct call_site_stuff): Remove.
Change-Id: Iaa82cb7cfd9768998553b4c9211aca7529eb402f
mi-var-child-f.exp uses array.f as the inferior, which uses an unnamed
main function. This causes false positive fails for Intel compilers, as
they emit the following DWARF:
~~~
0x0000002a: DW_TAG_subprogram
DW_AT_low_pc (0x0000000000404800)
DW_AT_high_pc (0x000000000040484c)
DW_AT_frame_base (DW_OP_reg6 RBP)
DW_AT_linkage_name ("MAIN__")
DW_AT_name ("_unnamed_main$$")
DW_AT_decl_file ("array.f")
DW_AT_decl_line (16)
DW_AT_external (true)
DW_AT_main_subprogram (true)
~~~
The testsuite for fortran uses test_compiler_info to determine a hardcoded
string which is used to run to main and as a testing regex:
~~~
proc fortran_main {} {
if {[test_compiler_info {gcc-4-[012]-*}]
|| [test_compiler_info {gcc-*}]
|| [test_compiler_info {icc-*}] {
return "MAIN__"
} elseif {[test_compiler_info {clang-*}]} {
return "MAIN_"
} else {
return "unknown"
}
}
~~~
GDB however uses DW_AT_name mostly in its output, which fails the regex.
To fix this testcase immediately, I modernized array.f and gave it a named
main. There was no specific reason it was unnamed anyway. Fixing
the testsuite properly is not straightforward. fortran_main and
test_compiler_info would need some changes, which has broader influences.
I might look at this later down the road.
gdb/testsuite/ChangeLog:
2021-06-11 Felix Willgerodt <felix.willgerodt@intel.com>
* gdb.mi/array.f: Convert into...
* gdb.mi/array.f90: ...this.
* gdb.mi/mi-var-child-f.exp: Use array.f90.
This patch implements Rust raw identifiers in the lexer in gdb. There
was an earlier patch to do this, but the contributor didn't reply to
my email asking whether he had sorted out his copyright assignment.
This is relatively straightforward, but a small test suite addition
was needd to ensure that the new test is skipped on older versions of
rustc -- ones that predate the introduction of raw identifiers.
gdb/ChangeLog
2021-06-11 Tom Tromey <tom@tromey.com>
PR rust/23427
* rust-parse.c (rust_parser::lex_identifier): Handle raw
identifiers.
(rust_lex_tests): Add raw identifier tests.
gdb/testsuite/ChangeLog
2021-06-11 Tom Tromey <tom@tromey.com>
PR rust/23427
* lib/rust-support.exp (rust_compiler_version): New caching proc.
* gdb.rust/rawids.exp: New file.
* gdb.rust/rawids.rs: New file.
Always define TC_PARSE_CONS_EXPRESSION to properly wrap constants for
all x86 targets.
* config/tc-i386.c (x86_cons): Handle GOT/PLT relocations only
if needed.
* config/tc-i386.h (TC_PARSE_CONS_EXPRESSION): Always define.
We also need to update the riscv_opts.[rvc|rve] for elf attributes.
Otherwise, the following case will fail,
$ cat cadd.s
.attribute arch, "rv64gc"
c.add a0, a1
$ riscv64-unknown-elf-as cadd.s -o cadd.o
cadd.s: Assembler messages:
cadd.s:2: Error: illegal operands `c.add a0,a1
After applying this patch,
$ riscv64-unknown-elf-as cadd.s -o cadd.o
$ riscv64-unknown-elf-objdump -d cadd.o
cadd.o: file format elf64-littleriscv
Disassembly of section .text:
0000000000000000 <.text>:
0: 952e add a0,a0,a1
...
gas/
* config/tc-riscv.c (riscv_set_arch): Call riscv_set_rvc
and riscv_set_rve both for -march and elf attributes.
(riscv_after_parse_args): Likewise.
A number of filedata entries were not cleared. Make sure they are
all cleared out, except the ones needed for archive handling.
* readelf.c (struct filedata): Move archive_file_offset and
archive_file_size earlier.
(free_filedata): Clear using memset.
This is a followup to git commit 8ff66993e0, a patch aimed at
segfaults found invoking readelf multiple times with fuzzed objects.
In that patch I added code to clear more stashed data early in
process_section_headers, along with any stashed section headers. This
patch instead relies on clearing out the stash at the end of
process_object, making sure that process_object doesn't exit early.
The patch also introduces some new wrapper functions.
* readelf.c (GET_ELF_SYMBOLS): Delete. Replace with..
(get_elf_symbols): ..this new function throughout.
(get_32bit_section_headers): Don't free section_headers.
(get_64bit_section_headers): Likewise.
(get_section_headers): New function, use throughout in place of
32bit and 64bit variants.
(get_dynamic_section): Similarly.
(process_section_headers): Don't free filedata memory here.
(get_file_header): Don't get section headers here..
(process_object): ..Read them here instead. Don't exit without
freeing filedata memory.
This patch adds a new elf_tdata flag, is_pie, set during the linker's
open_input_bfds processing. The flag is then used to reject attempts
to link a PIE as if it were a shared library.
bfd/
PR 27952
* elf-bfd.h (struct elf_obj_tdata): Add is_pie.
* elflink.c (elf_link_add_object_symbols): Set is_pie.
ld/
PR 27952
* ldelf.c (ldelf_after_open): Error on input PIEs too.
The TUI test gdb.tui/empty.exp fails with the native-extended-gdbserver
board, and takes a very long time to run due to numerous timeouts. The
symptom, when looking at the logs, is that the TUI windows that we
expect to be resized are not resized. Digging down, I found that GDB
didn't receive any SIGWINCH that should have resulted from
Term::resize's stty calls.
The reason for this is:
- The native-extended-gdbserver overrides gdb_start to first start GDB,
then start GDBserver with --multi, then connect GDB to GDBserver.
This means that two TCL "spawn"s are done, one for GDB and one for
GDBserver.
- The TUI test framework wants to know GDB's TTY name, so it can pass
it to stty, to fake terminal resizes. To do so, it overrides the
spawn built-in proc to capture the tty name from the internals of the
built-in proc. It saves the TTY name to the gdb_spawn_name global
variable.
- Because the native-extended-gdbserver boards starts both GDB and
GDBserver, the final value of gdb_spawn_name is the name of
GDBserver's TTY.
- When the TUI test framework attempts to resize GDB's terminal, it in
fact resizes GDBserver's terminal. So obviously, GDB doesn't get the
SIGWINCH, and we don't get the expected TUI redraw.
Fix that by moving the hack to lib/gdb.exp, overriding the builtin spawn
all the time. The override saves the TTY name in the
last_spawn_tty_name global. The default_gdb_spawn proc then saves it in
the gdb_tty_name global. This way, we specifically capture GDB's TTY
name in gdb_tty_name, not the TTY name of other spawned processes.
Remove tuiterm_env_init and tuiterm_env_finish, since they are now
empty. In turn, the gdb_finish_hooks mechanism is now unused, remove it
as well. It would be easy to add them back if needed.
gdb/ChangeLog:
* lib/gdb.exp (default_gdb_exit): Unset gdb_tty_name.
(spawn_capture_tty_name): New, override builtin spawn.
(default_gdb_spawn): Capture GDB's TTY name.
* lib/tuiterm.exp (tuiterm_spawn): Remove.
(tuiterm_env_init, tuiterm_env_finish): Remove spawn override.
(Term) <resize>: Use new variable name.
(tuiterm_env_init, tuiterm_env_finish): Remove.
(tuiterm_env): Don't call tuiterm_env_init and register
tuiterm_env_finish in gdb_finish_hooks.
(gdb_finish_hooks): Remove.
(gdb_finish): Don't call finish hooks.
Change-Id: Ia5ab74184a52a996416022308f8d0cc523355a78
When running test-case gdb.mi/user-selected-context-sync.exp with gcc-11, we
get:
...
continue^M
Continuing.^M
FAIL: gdb.mi/user-selected-context-sync.exp: mode=all-stop: test_setup: \
inferior 1: continue to breakpoint: continue thread 1.2 to infinite \
loop breakpoint (timeout)
...
This is a regression since commit aa33ea6833 "testsuite, mi: avoid a clang
bug in 'user-selected-context-sync.exp'", which fixes a similar hang when
using clang.
The source before the commit contains:
...
while (1);
...
and after the commit:
...
int spin = 1;
while (spin);
...
[ FWIW, I've filed a PR gcc/101011 - Inconsistent debug info for "while (1);"
to mention that gcc-11 has different behaviour for these two loops. ]
The problem is that:
- the test-case expects the behaviour that a breakpoint set
on the while line will trigger on every iteration, and
- that is not guaranteed by either version of the loop.
Fix this by using a while loop with a dummy body:
...
volatile int dummy = 0;
while (1)
dummy = !dummy;
...
and setting the breakpoint in the body.
Tested on x86_64-linux with clang 10.0.1, gcc-4.8, gcc 7.5.0 and gcc 11.1.1.
gdb/testsuite/ChangeLog:
2021-06-10 Tom de Vries <tdevries@suse.de>
* gdb.mi/user-selected-context-sync.c (child_sub_function, main):
Rewrite while (1) using dummy loop body.
