forget_cached_source_info_for_objfile does some objfile-specific work
and then calls objfile::forget_cached_source_info. It seems better to
me to just have the method do all the work.
I ran across the attribute reprocessing code recently and noticed that
it unconditionally sets members of the CU when reading a DIE. Also,
each spot reading attributes needs to be careful to "reprocess" them
as a separate step.
This seemed excessive to me, because while reprocessing applies to any
DIE, setting the CU members is only necessary for the toplevel DIE in
any given CU.
This patch introduces a new read_toplevel_die function and changes a
few spots to call it. This is easily done because reading the
toplevel DIE is already special.
I left the reprocessing flag and associated checks in attribute. It
could be stripped out, but I am not sure it would provide much value
(maybe some iota of performance).
Regression tested on x86-64 Fedora 36.
This field is never initialized, it seems to me like it would be a good
idea to initialize it to nullptr to avoid bad surprises.
Change-Id: I8c04319d564f5d385d8bf0acee758f6ce28b4447
Reviewed-By: Tom Tromey <tom@tromey.com>
I realized that the memory for interp names does not need to be
allocated. The name used to register interp factory functions is always
a literal string, so has static storage duration. If we change
interp_lookup to pass that name instead of the string that it receives
as a parameter (which does not always have static storage duration),
then interps can simply store pointers to the name.
So, change interp_lookup to pass `factory.name` rather than `name`.
Change interp::m_name to be a `const char *` rather than an std::string.
Change-Id: I0474d1f7b3512e7d172ccd73018aea927def3188
Reviewed-By: Tom Tromey <tom@tromey.com>
get_interp_info and get_current_interp_info always return non-nullptr,
so they can return a reference instead of a pointer.
Since we don't need to copy it, make ui_interp_info non-copyiable, to
avoid a copying it in a local variable, instead of getting a reference.
Change-Id: I6d8dea92dc26a58ea340d04862db6b8d9cf906a0
Reviewed-By: Tom Tromey <tom@tromey.com>
Simon points out that the new maint command, intended to fix a
regression, also introduces a new regression in "maint selftest".
This patch fixes the error. I did a full regression test on x86-64
Fedora 36.
gprofng reads Dwarf to find function names, sources, and line numbers.
gprofng skips other debug information.
I fixed three places in gprofng Dwarf reader:
- parsing the compilation unit header.
- parsing the line number table header.
- parsing new DW_FORMs.
Tested on aarch64-linux/x86_64-linux.
gprofng/ChangeLog
2023-03-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30195
gprofng/src/Dwarf.cc: Support Dwarf-5.
gprofng/src/DwarfLib.cc: Likewise.
gprofng/src/Dwarf.h: Likewise.
gprofng/src/DwarfLib.h: Likewise.
gprofng/src/collctrl.cc: Don't read freed memory.
Commit 5218fa9e89, "gdb: use libtool in
GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment,
this caused the configure check "checking for ELF support in BFD" to stop
working causing build failures as we need our LDFLAGS to be used for
correct linking.
That change also meant the code failed to match the comments. Add back the
missing LDFLAGS preservation, fix our builds and match the comment.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com>
Now that index cache files are written in the background, one test in
index-cache.exp is racy -- it assumes that the cache file will have
been written during startup.
This patch fixes the problem by introducing a new maintenance command
to wait for all pending writes to the index cache.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
In test-case gdb.base/skip-solib.exp the linking against a shared library is
done manually:
...
if {[gdb_compile "${binfile_main}.o" "${binfile_main}" executable \
[list debug "additional_flags=-L$testobjdir" \
"additional_flags=-l${test}" \
"ldflags=-Wl,-rpath=$testobjdir"]] != ""} {
...
Instead, use the shlib gdb_compile option such that we simply have:
...
[list debug shlib=$binfile_lib]] != ""} {
...
Tested on x86_64-linux.
Fix test-case gdb.base/fork-no-detach-follow-child-dlopen.exp for target board
remote-gdbserver-on-localhost.exp by using gdb_download_shlib and gdb_locate_shlib.
Tested on x86_64-linux.
With test-case gdb.base/break-probes.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.
Fix these by adding the missing gdb_download_shlib and gdb_locate_shlib.
Tested on x86_64-linux.
The Makefile.in was generated using automake
after adding a few files.
When adding the ldreflect.* files, the autotools
versions were wrong.
After upgrading the host OS, autotools were upgraded to 2.71
reinstalling the desired 2.69 still generates a lot of changes.
Makefile.ini has therefore been manually edited.
Signed-off-by: Ulf Samuelsson <ulf@emagii.com>
With test-case gdb.base/signals-state-child.exp on target board
remote-gdbserver-on-localhost I run into:
...
builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
$outputs/gdb.base/signals-state-child/signals-state-child-standalone^M
bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \
Permission denied^M
Connection to localhost closed.^M^M
FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
...
The problem is that we're trying to run an executable on the target board using
a host path.
After fixing this by downloading the exec to the target board, we run into:
...
builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
signals-state-child-standalone^M
bash: signals-state-child-standalone: command not found^M
Connection to localhost closed.^M^M
FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
...
Fix this by using an absolute path name for the exec on the target board.
The dejagnu proc standard_file does not support op == "absolute" for target
boards, so add an implementation in remote-gdbserver-on-localhost.exp.
Also:
- fix a PATH-in-test-name issue
- cleanup gdb.txt and standalone.txt on target board
Tested on x86_64-linux.
Test-case gdb.cp/breakpoint-shlib-func.exp fails with target board
remote-gdbserver-on-localhost.
Fix this by adding the missing gdb_load_shlib.
Tested on x86_64-linux.
On AIX, the debugger cannot access vector registers before they
are first used by the inferior. Hence we change the test case
such that some vector registers are accessed by the variable 'x' in AIX
and other targets are not affected as a consequence of the same.
When running test-cases gdb.mi/*.exp with target board
remote-gdbserver-on-localhost, we run into a few fails.
Fix these (and make things more similar to the gdb.exp procs) by:
- factoring out mi_load_shlib out of mi_load_shlibs
- making mi_load_shlib use gdb_download_shlib, like
gdb_load_shlib
- factoring out mi_locate_shlib out of mi_load_shlib
- making mi_locate_shlib check for mi_spawn_id, like
gdb_locate_shlib
- using gdb_download_shlib and mi_locate_shlib in the test-cases.
Tested on x86_64-linux, with and without target board
remote-gdbserver-on-localhost.
When building with clang 16, I see:
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:338:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.load_args = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:345:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.critical = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:351:37: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.interrupt = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:367:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.fp_sdcc = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:375:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.fp_sdcc = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:380:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.fp_sdcc = 1;
^ ~
Fix that by using "unsigned int" as the bitfield's underlying type.
Change-Id: I3550a0112f993865dc70b18f02ab11bb5012693d
When building with clang 16, we get:
CXX gdb.o
In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19:
In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65:
/home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion]
integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
^
The error message does not make it clear in the context of which enum
flag this fails (i.e. what is T in this context), but it doesn't really
matter, we have similar warning/errors for many of them, if we let the
build go through.
clang is right that the value -1 is invalid for the enum type we cast -1
to. However, we do need this expression in order to select an integer
type with the appropriate signedness. That is, with the same signedness
as the underlying type of the enum.
I first wondered if that was really needed, if we couldn't use
std::underlying_type for that. It turns out that the comment just above
says:
/* Note that std::underlying_type<enum_type> is not what we want here,
since that returns unsigned int even when the enum decays to signed
int. */
I was surprised, because std::is_signed<std::underlying_type<enum_type>>
returns the right thing. So I tried replacing all this with
std::underlying_type, see if that would work. Doing so causes some
build failures in unittests/enum-flags-selftests.c:
CXX unittests/enum-flags-selftests.o
/home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same<selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<s
elftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selftests::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_fla
gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<selftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selfte
sts::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_flags_tests::URE, unsigned int>>::value == true':
CHECK_VALID (true, int, true ? EF () : EF2 ())
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID'
CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6'
CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2, \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT'
static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>, \
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a bit hard to decode, but basically enumerations have the
following funny property that they decay into a signed int, even if
their implicit underlying type is unsigned. This code:
enum A {};
enum B {};
int main() {
std::cout << std::is_signed<std::underlying_type<A>::type>::value
<< std::endl;
std::cout << std::is_signed<std::underlying_type<B>::type>::value
<< std::endl;
auto result = true ? A() : B();
std::cout << std::is_signed<decltype(result)>::value << std::endl;
}
produces:
0
0
1
So, the "CHECK_VALID" above checks that this property works for enum flags the
same way as it would if you were using their underlying enum types. And
somehow, changing integer_for_size to use std::underlying_type breaks that.
Since the current code does what we want, and I don't see any way of doing it
differently, ignore -Wenum-constexpr-conversion around it.
Change-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2
- Some OS's use a different syscall for exit(). For example, the
BSD's use SYS_exit rather than SYS_exit_group. Update the C source
file and the expect script to support SYS_exit as an alternative to
SYS_exit_group.
- The cross-arch syscall number tests are all Linux-specific with
hardcoded syscall numbers specific to Linux kernels. Skip these
tests on non-Linux systems. FreeBSD kernels for example use the
same system call numbers on all platforms, so the test is also not
relevant on FreeBSD.
Setting the stack size to 2*PTHREAD_STACK_MIN actually lowered the
stack on FreeBSD rather than raising it causing non-main threads in
the test program to overflow their stack and crash. Double the
existing stack size rather than assuming that the initial stack size
is PTHREAD_STACK_MIN.
These registers can be changed directly in userspace, and similar
registers to support TLS on other architectures (tpidr* on ARM and
AArch64, tp on RISC-V) are treated as general purpose registers.
Reviewed-By: Tom Tromey <tom@tromey.com>
The orig_rax pseudo-register is Linux-specific and isn't relevant to
this test. The fs_base and gs_base registers are also not treated as
system registers in other OS ABIs. This allows the test to pass on
FreeBSD.
Reviewed-By: Tom Tromey <tom@tromey.com>
As of 2023-02-13 "gdb/python: deallocate tui window factories at Python
shut down" (9ae4519da9), a TUI-less build fails with:
$src/gdb/python/py-tui.c: In function ‘void gdbpy_finalize_tui()’:
$src/gdb/python/py-tui.c:621:3: error: ‘gdbpy_tui_window_maker’ has not been declared
621 | gdbpy_tui_window_maker::invalidate_all ();
| ^~~~~~~~~~~~~~~~~~~~~~
Since gdbpy_tui_window_maker is only defined under #ifdef TUI, add an
#ifdef guard in gdbpy_finalize_tui as well.
Test-case gdb.base/gdb-caching-proc.exp doesn't really test gdb, but it tests
the gdb_caching_procs in the testsuite, so it belongs in gdb.testsuite rather
than gdb.base.
Move test-case gdb.base/gdb-caching-proc.exp to gdb.testsuite, renaming it to
gdb.testsuite/gdb-caching-proc-consistency.exp to not clash with
recently added gdb.testsuite/gdb-caching-proc.exp.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Test-case gdb.base/morestack.exp contains:
...
require {have_compile_flag -fsplit-stack}
...
and I want to cache the result of have_compile_flag.
Currently gdb_caching_proc doesn't allow args, so I could add:
...
gdb_caching_proc have_compile_flag_fsplit_stack {
return [have_compile_flag -fsplit-stack]
}
...
and then use that proc instead, but I find this cumbersome and
maintenance-unfriendly.
Instead, allow args in a gdb_caching_proc, such that I can simply do:
...
-proc have_compile_flag { flag } {
+gdb_caching_proc have_compile_flag { flag } {
...
Note that gdb_caching_procs with args do not work with the
gdb.base/gdb-caching-procs.exp test-case, so those procs are skipped.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
A regular tcl proc with no args looks like:
...
proc foo {} {
return 1
}
...
but a gdb_caching_proc deviates from that syntax by dropping the explicit no
args bit:
...
gdb_caching_proc foo {
return 1
}
...
Make the gdb_caching_proc use the same syntax as regular procs, such that we
have instead:
...
gdb_caching_proc foo {} {
return 1
}
...
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
The DAP stackTrace implementation did not fully account for frames
without debuginfo. Attemping this would yield a result like:
{"request_seq": 5, "type": "response", "command": "stackTrace", "success": false, "message": "'NoneType' object has no attribute 'filename'", "seq": 11}
This patch fixes the problem by adding another check for None.
exception_catchpoint::resources_needed has a FIXME comment that I
think makes this method obsolete. Also, I note that similar
catchpoints, for example Ada catchpoints, don't have this method.
This patch removes the method. Regression tested on x86-64 Fedora 36.
The recent work to have gdb link via libtool means that there are a
couple more generated files in the build directory that should be
removed by "distclean".
Note that gdb can't really fully implement distclean due to the desire
to put certain generated files into the distribution. Still, it can
get pretty close.
The main problem here was not returning -1 from canonicalize_symtab on
an error, leaving the vector of relocs only partly initialised and one
with a null sym_ptr_ptr.
* mach-o.c (bfd_mach_o_canonicalize_symtab): Return -1 on error,
not 0.
(bfd_mach_o_pre_canonicalize_one_reloc): Init sym_ptr_ptr to
undefined section sym.
PR 30198
* coff-x86_64.c (coff_amd64_reloc): Set *error_message when
returning bfd_reloc_dangerous. Also check that __ImageBase is
defined before accessing h->u.def.
