Fix test-case gdb.threads/pending-fork-event-detach.exp for target board
remote-gdbserver-on-localhost using gdb_remote_download for $touch_file_bin.
Then, fix the test-case for target board remote-stdio-gdbserver with
REMOTE_TMPDIR=~/tmp.remote-stdio-gdbserver by creating $touch_file_path
on target using remote_download, and using the resulting path.
Tested on x86_64-linux.
objdump's read_section is never used for bss-style sections, so to
plug a hole that fuzzers have found, exclude sections without
SEC_HAS_CONTENTS.
* objdump.c (read_section): Report and return an error on
a no contents section.
This:
.struct -1
x:
.fill 1
y:
results in an internal error in frag_new due to abs_section_offset
wrapping from -1 to 0. Frags in the absolute section don't do much so
I think we can allow the address wrap.
* frags.c (frag_new): Allow address wrap in absolute section.
With test-case gdb.threads/multiple-successive-infcall.exp and target board
native-gdbserver I run into:
...
(gdb) continue^M
Continuing.^M
[New Thread 758.759]^M
^M
Thread 1 "multiple-succes" hit Breakpoint 2, main () at \
multiple-successive-infcall.c:97^M
97 thread_ids[tid] = tid + 2; /* prethreadcreationmarker */^M
(gdb) FAIL: gdb.threads/multiple-successive-infcall.exp: thread=5: \
created new thread
...
The problem is that the new thread message doesn't match the regexp, which
expects something like this instead:
...
[New Thread 0x7ffff746e700 (LWP 570)]^M
...
Fix this by accepting this form of new thread message.
Tested on x86_64-linux.
With test-case gdb.threads/thread-specific-bp.exp and target board
native-gdbserver I run into:
...
(gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=off: thread 1 selected
continue^M
Continuing.^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
^M
Thread 1 "thread-specific" hit Breakpoint 4, end () at \
thread-specific-bp.c:29^M
29 }^M
(gdb) FAIL: gdb.threads/thread-specific-bp.exp: non_stop=off: \
continue to end (timeout)
...
The problem is that the test-case tries to match the "[Thread ... exited]"
message which we do see with native testing:
...
Continuing.^M
[Thread 0x7ffff746e700 (LWP 7047) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
...
The fact that the message is missing was reported as PR remote/30129.
We could add a KFAIL for this, but the functionality the test-case is trying
to test has nothing to do with the message, so it should pass. I only added
matching of the message in commit 2e5843d87c ("[gdb/testsuite] Fix
gdb.threads/thread-specific-bp.exp") to handle a race, not realizing doing so
broke testing on native-gdbserver.
Fix this by matching the "Thread-specific breakpoint $decimal deleted" message
instead.
Tested on x86_64-linux.
With test-case gdb.server/unittest.exp and a build with --disable-unit-tests I
get:
...
(gdb) builtin_spawn /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver \
--selftest^M
Selftests have been disabled for this build.^M
UNSUPPORTED: gdb.server/unittest.exp: unit tests
...
but with target board remote-stdio-gdbserver I get instead:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
/data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
Selftests have been disabled for this build.^M
Connection to localhost closed.^M^M
FAIL: gdb.server/unittest.exp: unit tests
...
Fix this by making the regexp less strict.
Tested on x86_64-linux.
With test-case gdb.server/unittest.exp and target board remote-stdio-gdbserver
I run into:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost /usr/bin/gdbserver \
--selftest^M
Selftests have been disabled for this build.^M
UNSUPPORTED: gdb.server/unittest.exp: unit tests
...
due to using the system gdbserver /usr/bin/gdbserver rather than the one from
the build.
Fix this by removing the hard-coding of /usr/bin/gdbserver in
remote-stdio-gdbserver, allowing find_gdbserver to do its work, such that we
have instead:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
/data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
Running selftest remote_memory_tagging.^M
Ran 1 unit tests, 0 failed^M
Connection to localhost closed.^M^M
PASS: gdb.server/unittest.exp: unit tests
...
Tested on x86_64-linux.
Fix test-case gdb.server/sysroot.exp with target board
remote-gdbserver-on-localhost, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host.
Tested on x86_64-linux.
Test-case gdb.server/multi-ui-errors.exp fails for target board
remote-gdbserver-on-localhost with REMOTE_TARGET_USERNAME=remote-target:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 6447 (timeout = 300)
builtin_spawn [open ...]^M
XYZ1ZYX
sh: line 0: kill: (6447) - Operation not permitted
...
The problem is that the kill command:
...
remote_exec target "kill -9 $gdbserver_pid"
...
intended to kill gdbserver instead tries to kill the ssh client session in
which the gdbserver runs, and fails because it's trying as the remote target
user (remote-target on localhost) to kill a pid owned by the the build user
($USER on localhost).
Fix this by getting the gdbserver pid using the ppid trick from
server-kill.exp.
Likewise in gdb.server/server-kill-python.exp.
Tested on x86_64-linux.
In commit 80dc83fd0e ("gdb/remote: handle target dying just before a stepi")
an observation is made that test-case gdb.server/server-kill.exp claims to
kill gdbserver, but actually kills the inferior. Consequently, the commit
adds testing of killing gdbserver alongside.
The problem is that:
- the original observation is incorrect (possibly caused by misreading getppid
as getpid)
- consequently, the test-case doesn't test killing the inferior, instead it
tests killing gdbserver twice
- the method to get the gdbserver PID added in the commit doesn't work
for target board remote-gdbserver-on-localhost, it returns the
PID of the ssh client session instead.
Fixing the method for getting the inferior PID gives us fails, and there's no
evidence that killing the inferior ever worked.
So, fix this by reverting the commit and just killing gdbserver, using the
original method of getting the gdbserver PID which does work for target board
remote-gdbserver-on-localhost.
Tested on x86_64-linux.
Test-case gdb.server/connect-with-no-symbol-file.exp fails with target board
remote-gdbserver-on-localhost.
The problem is here:
...
set target_exec [gdb_remote_download target $binfile.bak $binfile]
...
A "gdb_remote_download target" copies from build to target. So $binfile is
assumed to be a target path, but it's actually a build path.
Fix this by:
- fist copying $binfile.bak to $binfile, and
- simply doing [gdb_remote_download target $binfile].
Then, $binfile.bak is created here:
...
# Make sure we have the original symbol file in a safe place to copy from.
gdb_remote_download host $binfile $binfile.bak
...
and since "gdb_remote_download host" copies from build to host, $binfile.bak
is assumed to be a host path, but it's actually a build path. This happens to
cause no problems in this configuration (because build == host), but it would
for a remote host configuration.
So let's fix this by making build rather than host the "safe place to copy
from".
Tested on x86_64-linux.
OBJF_REORDERED is set for nearly every object format. And, despite
the ominous warnings here and there, it does not seem very expensive.
This patch removes the flag entirely.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
The test fails on Power 10 with the RHEL9 distro. It also fails on
Power 9.
The test set a the breakpoint in main that stops at line:
a = 9; /* start here */. The test then sets a break point at the same
line where it wants to start the test and does a continue. GDB does not
stop again on the same line where it is stopped, but rather continues to
the end of the program.
Initialize variable A to zero so the break on main will stop before setting
a break point on line a = 9; /* start here */.
Make the match on the breakpoint number generic.
Patch has been tested on Power 10 with RHEL 9, Power 10 with Ubuntu 22.04,
and Power 9 with Fedora 36 with no regression failures.
* peicode.h (ILF section, pe_ILF_object_p): Correct comments
and update the reference to Microsoft's docs.
(pe_ILF_build_a_bfd): Move all symbol creation before flipping
the bfd over to in-memory.
Correct test target/skip lines to fix fails on alpha-dec-vms,
alpha-linux-gnuecoff, i386-bsd, i386-msdos, ns32k-openbsd,
ns32k-pc532-mach, pdp11-dec-aout, rs6000-aix*, tic4x-coff, and
tic54x-coff.
Commit e3f450f393 resulted in a nm -l segfault on object files
without undefined symbols. Fix that, and be paranoid about bfd
section count changing.
* nm.c (struct lineno_cache): Add seccount.
(free_lineno_cache): Don't segfault on NULL lc->relocs.
(print_symbol): Stash section count when creating arrays.
The AMD GPU support has been merged shortly after commit 4e1d2f5814
("Add new overload of gdbarch_return_value"), which made it mandatory
for architectures to provide either a return_value or
return_value_as_value implementation. Because of my failure to test
properly after rebasing and before pushing, we get this with the current
master:
$ gdb ./gdb -nx --data-directory=data-directory -q -ex "set arch amdgcn:gfx1010" -batch
/home/simark/src/binutils-gdb/gdb/gdbarch.c:517: internal-error: verify_gdbarch: the following are invalid ...
return_value_as_value
I started trying to change GDB to not force architectures to provide a
return_value or return_value_as_value implementation, but Andrew pointed
out that any serious port will have an implementation one day or
another, and it's easy to add a dummy implementation in the mean time.
So it's better to not complicate the core of GDB to know how to deal
with this.
There is an implementation of return_value in the downstream ROCgdb port
(which we'll need to convert to the new return_value_as_value), which
we'll contribute soon-ish. In the mean time, add a dummy implementation
of return_value_as_value to avoid the failed assertion.
Change-Id: I26edf441b511170aa64068fd248ab6201158bb63
Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
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>
