bfd/ChangeLog:
* bfd-in.h (bfd_hash_set_default_size): Add COMPRESS_UNKNOWN
enum value.
(struct compressed_type_tuple): New.
* bfd-in2.h (bfd_hash_set_default_size): Regenerate.
(struct compressed_type_tuple): Likewise.
* libbfd.c (ARRAY_SIZE): New macro.
(bfd_get_compression_algorithm): New function.
(bfd_get_compression_algorithm_name): Likewise.
gas/ChangeLog:
* as.c: Do not special-case, use the new functions.
ld/ChangeLog:
* emultempl/elf.em: Do not special-case, use the new functions.
* lexsup.c (elf_static_list_options): Likewise.
After this commit:
commit 0938b032da
Date: Wed Feb 2 10:06:15 2022 +0900
RISC-V: Add 'Zmmul' extension in assembler.
some instructions in the RISC-V simulator stopped working as a new
instruction class 'INSN_CLASS_ZMMUL' was added, and some existing
instructions were moved into this class.
The simulator doesn't currently handle this instruction class, and so
the instructions will now cause an illegal instruction trap.
This commit adds support for INSN_CLASS_ZMMUL, and adds a test that
ensures the affected instructions can be executed by the simulator.
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
Because sim/moxie/moxie-gdb.dtb is neither a program nor a library, automake
does not generate dirstamp file ($builddir/sim/moxie/.dirstamp) for it.
When maintainer mode is enabled, it tries to rebuild sim/moxie/moxie-gdb.dtb
but fails because there's no rules for automake-generated dirstamp file
which moxie-gdb.dtb depends.
This commit adds its own rule for the directory stamp (modified copy of the
automake output) and adds the directory stamp file to DISTCLEANFILES to
mimic automake-generated behavior (although "make distclean" does not work
when maintainer mode is enabled).
The python black formatter was complaining about formatting on the
script gdb.python/pretty-print-call-by-hand.py. This commit changed
the offending lines to make the formatter happy.
I noticed in capture_command_output that the output of a single command is
matched using two gdb_test_multiples:
- the first one matching the echoed command and skipping an optional prefix,
- the second one matching the output and the prompt.
This is error-prone, because the first gdb_test_multiple has implicit
clauses which may consume the prompt.
The problem is easy to spot with an example. First consider:
...
set output [capture_command_output "print 1" "\\\$1 = "]
gdb_assert { [string equal $output "1"] }
...
for which we get:
...
PASS: [string equal $output "1"]
...
If we change the prefix string to a no-match, say "1 = ", and update the
output string match accordingly, we get instead:
...
FAIL: capture_command_output for print 1
FAIL: [string equal $output "\$1 = 1"]
...
The first FAIL is produced by the first gdb_test_multiple, consuming the prompt.
The second gdb_test_multiple then silently times out waiting for another prompt,
after which the second FAIL is produced. Note that the timeout is silent
because the gdb_test_multiple is called with an empty message argument.
The second FAIL is because capture_command_output returns "", given that all
the command output was consumed by the first gdb_test_multiple.
Fix this by rewriting capture_command_output to use only a single
gdb_test_multiple.
Tested on x86_64-linux.
gprofng/ChangeLog
2022-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/29465
PR gprofng/29667
* doc/Makefile.am: No need to build version.texi.
* doc/Makefile.in: Rebuild.
gprofng/ChangeLog
2022-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/29107
* testsuite/config/default.exp: Set up environment to run gprofng tests
without installation.
* testsuite/lib/Makefile.skel: Likewise.
* testsuite/lib/display-lib.exp: Likewise.
I see some random failures in this test:
FAIL: gdb.base/async-shell.exp: run & (timeout)
It can be reliably reproduced on a recent enough GNU/Linux with this
change:
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 44cc28b30051..2a3c8253ba5a 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -1301,6 +1301,7 @@ proc gdb_test_multiple { command message args } {
}
set gdb_test_name "$message"
+ sleep 2
set result 0
set code [catch {gdb_expect $code} string]
"recent enough" means a system where libpthread.so was merged with
libc.so, so at least glibc 2.34.
The problem is that the `run &` command prints some things after the
prompt:
(gdb) [Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
If expect is quick enough, it will consume only up to the prompt. But
if it is slow enough, it will consume those messages at the same time as
the prompt, in which case the gdb_test used for "run &" won't match. By
default, the prompt used by gdb_test uses a `$` to anchor the match at
the end of the buffer. If there's anything following the prompt, it
won't match.
The diff above adds a delay between sending the command and consuming
the output, giving GDB more time to output the messages, giving a good
chance that expect consumes them at the same time as the prompt.
This is normally handled by using gdb_test_multiple and specifying a
pattern that ends with "$gdb_prompt", but not a trailing $. I think
this is common enough that it deserves its own gdb_test option.
Therefore, add the -no-anchor-prompt option to gdb_test, and
gdb_test_no_output for completeness. Use it in
gdb.base/async-shell.exp.
Change-Id: I9051d8800d1c10a2e95db1a575991f7723492f1b
Approved-By: Tom de Vries <tdevries@suse.de>
print_wchar keeps track of when escape sequences are emitted, to force
an escape sequence if needed by a subsequent character. For example
for the string concatenation "\0" "1", gdb will print "\000\061" --
because printing "\0001" might be confusing.
However, this code has two errors. First, this logic is not needed
for octal escapes, because there is a length limit of 3 for octal
escapes, and gdb always prints these with "%.3o". Second, though,
this *is* needed for hex escapes, because those do not have a length
limit.
This patch fixes these problems and adds the appropriate tests.
print_wchar uses wchar_printable, but this isn't needed -- all the
relevant cases are already handled by the 'switch'. This changes the
code to use gdb_iswprint, and removes a somewhat confusing comment
related to this code.
generic_printstr prints an empty string like:
fputs_filtered ("\"\"", stream);
However, this seems wrong to me if the quote character is something
other than double quote. This patch fixes this latent bug. Thanks to
Andrew for the test case.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
The frame_info_ptr patches broke the build with Guile. This patch
fixes the problem. In mos cases I chose to preserve the use of
frame_info_ptr, at least where I could be sure that the object
lifetime did not interact with Guile's longjmp-based exception scheme.
Tested on x86-64 Fedora 34.
I noticed that the error message in gdb_test_multiple about trailing newline
in a command does not mention the offending command, nor the word command:
...
if [string match "*\[\r\n\]" $command] {
error "Invalid trailing newline in \"$message\" test"
}
...
Fix this by using instead:
...
error "Invalid trailing newline in \"$command\" command"
...
Also add a test-case to trigger this: gdb.testsuite/gdb-test.exp.
Tested on x86_64-linux.
The struct target_buffer (in gdb_bfd.c) is used to hold information
about an in-memory BFD object created by GDB. For now this mechanism
is used by GDB when loading information about JIT symfiles.
This commit updates target_buffer (in gdb_bfd.c) to be more C++ like,
and, at the same time, adds the base address of the symfile into the
BFD filename.
Right now, every in-memory BFD is given the filename "<in-memory>".
This filename is visible in things like 'maint info symtabs' and
'maint info line-table'. If there are multiple in-memory BFD objects
then it can be hard to match keep track if which BFD is which. This
commit changes the name to be "<in-memory@ADDRESS>" where ADDRESS is
replaced with the base address for where the in-memory symbol file was
read from.
As an example of how this is useful, here's the output of 'maint info
jit' showing a single loaded JIT symfile:
(gdb) maintenance info jit
jit_code_entry address symfile address symfile size
0x00000000004056b0 0x0000000007000000 17320
And here's part of the output from 'maint info symtabs':
(gdb) maintenance info symtabs
...snip...
{ objfile <in-memory@0x7000000> ((struct objfile *) 0x5258250)
{ ((struct compunit_symtab *) 0x4f0afb0)
debugformat DWARF 4
producer GNU C17 9.3.1 20200408 (Red Hat 9.3.1-2) -mtune=generic -march=x86-64 -g -fno-stack-protector -fpic
name jit-elf-solib.c
dirname /tmp/binutils-gdb/build/gdb/testsuite
blockvector ((struct blockvector *) 0x5477850)
user ((struct compunit_symtab *) (null))
{ symtab /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/jit-elf-solib.c ((struct symtab *) 0x4f0b030)
fullname (null)
linetable ((struct linetable *) 0x5477880)
}
}
}
I've added a new test that checks the new in-memory file names are
generated correctly, and also checks that the in-memory JIT files can
be dumped back out using 'dump binary memory'.
The filename argument to gdb_bfd_open_from_target_memory was never
used; this argument had a default value of nullptr, and the only call
to this function, in jit.c, relied on the default value.
In the next commit I'm going to make some changes to the
gdb_bfd_open_from_target_memory function, and, though I could take
account of a filename parameter, it seems pointless to maintain an
unused argument.
This commit removes the filename argument.
There should be no user visible changes after this commit.
Add two new commands:
set debug infcall on|off
show debug infcall
These enable some new debugging related to when GDB makes inferior
function calls. I've added some basic debugging for what I think are
the major steps in the inferior function call process, but I'm sure we
might want to add more later.
This commit switches to use INFRUN_SCOPED_DEBUG_START_END in the
infrun_debug_show_threads function, which means the output will get an
extra level of indentation, this looks a little nicer I think.
* src-release.sh: Add "-r <date>" option to create reproducible
tarballs based upon a fixed timestamp of <date>.
* binutils/README-how-to-make-a-release: Add a line showing how to
use -r <date> when creating a binutils release.
Currently, despite having a smart pointer for frame_infos, GDB may
attempt to use an invalidated frame_info_ptr, which would cause internal
errors to happen. One such example has been documented as PR
python/28856, that happened when printing frame arguments calls an
inferior function.
To avoid failures, the smart wrapper was changed to also cache the frame
id, so the pointer can be reinflated later. For this to work, the
frame-id stuff had to be moved to their own .h file, which is included
by frame-info.h.
Frame_id caching is done explicitly using the prepare_reinflate method.
Caching is done manually so that only the pointers that need to be saved
will be, and reinflating has to be done manually using the reinflate
method because the get method and the -> operator must not change
the internals of the class. Finally, attempting to reinflate when the
pointer is being invalidated causes the following assertion errors:
check_ptrace_stopped_lwp_gone: assertion `lp->stopped` failed.
get_frame_pc: Assertion `frame->next != NULL` failed.
As for performance concerns, my personal testing with `time make
chec-perf GDB_PERFTEST_MODE=run` showed an actual reduction of around
10% of time running.
This commit also adds a testcase that exercises the python/28856 bug with
7 different triggers, run, continue, step, backtrace, finish, up and down.
Some of them can seem to be testing the same thing twice, but since this
test relies on stale pointers, there is always a chance that GDB got lucky
when testing, so better to test extra.
Regression tested on x86_64, using both gcc and clang.
Approved-by: Tom Tomey <tom@tromey.com>
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
This adds frame_info_ptr, a smart pointer class. Every instance of
the class is kept on an intrusive list. When reinit_frame_cache is
called, the list is traversed and all the pointers are invalidated.
This should help catch the typical GDB bug of keeping a frame_info
pointer alive where a frame ID was needed instead.
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
This replaces frame_id_eq with operator== and operator!=. I wrote
this for a version of this series that I later abandoned; but since it
simplifies the code, I left this patch in.
Approved-by: Tom Tomey <tom@tromey.com>
Within the testsuite, use the keyword 'end' to terminate blocks of
Python code being sent to GDB, rather than sending \004. I could only
find three instances of this, all in tests that I originally wrote. I
have no memory of there being any special reason why I used \004
instead of 'end' - I assume I copied this from somewhere else that has
since changed.
Non of the tests being changed here are specifically about whether
\004 can be used to terminate a Python block, so I think switching to
the more standard 'end' keyword is the right choice.
I get this diff when re-generating configure, probably leftover from
67d1991b78 ("egrep in binutils").
Change-Id: I759c88c2bad648736d33ff98089db45c9b686356
To merge with gcc's copy of configure.ac we need to revert changes to
configure.ac in the following gcc commits:
dc832fb39fc0 2022-08-25
fc259b522c0f 2022-06-25
Then reapply configure.ac changes in binutils from these binutils
commits:
50ad1254d5 2021-01-09
bb368aad29 2022-03-11
e5f2f7d901 2022-07-26
2cac01e3ff 2022-09-26
Plus copy over gcc's config/ax_cxx_compile_stdcxx.m4, then regenerate
configure.
The class debug_names has two 'insert' overloads, but only one of them
is ever called externally, and it simply forwards to the other
implementation. It seems cleaner to me to have a single method, so
this patch merges the two.
With native and target boards native-gdbserver, remote-gdbserver-on-localhost and
remote-stdio-gdbserver I have for gdb.server/connect-with-no-symbol-file.exp:
...
# of expected passes 8
...
but with native-extended-gdbserver I have instead:
...
# of expected passes 8
# of unexpected failures 4
...
The extra FAILs are of the form:
...
(gdb) detach^M
Detaching from pid process 28985^M
[Inferior 1 (process 28985) detached]^M
(gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
action=permission: connection to GDBserver succeeded
...
and are due to the fact that the actual gdb output doesn't match the regexp:
...
gdb_test "detach" \
".*Detaching from program: , process.*Ending remote debugging.*" \
"connection to GDBserver succeeded"
...
With native, the actual gdb output is:
...
(gdb) detach^M
Detaching from pid process 29657^M
Ending remote debugging.^M
[Inferior 1 (process 29657) detached]^M
(gdb) Remote debugging from host ::1, port 51028^M
...
and because the regexp doesn't match, it triggers an implicit clause for
"Ending remote debugging" in gdb_test_multiple, which has the consequence
that the FAIL is silent.
Fix:
- the regexp by making it less strict
- the silent fail by rewriting into a gdb_test_multiple, and adding an
explicit fail clause.
Tested on x86_64-linux, using native and aforementioned target boards.
On ubuntu 22.04 with the libc6-dbg package installed, I have the
following failure:
where
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at .../gdb/testsuite/gdb.threads/linux-dp.c:105
#1 0x000055555555576a in philosopher (data=0x55555555937c) at .../gdb/testsuite/gdb.threads/linux-dp.c:148
#2 0x00007ffff7e11b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#3 0x00007ffff7ea3a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
The regex for this test accounts for different situations (with /
without debug symbol) but assumes that if debug info is present the
backtrace shows execution under pthread_create. However, for the
implementation under test, we are under start_thread.
Update the regex to accept start_thread.
Tested on Ubuntu-22.04 x86_64 with and without libc6-dbg debug symbols
available.
Change-Id: I1e1536279890bca2cd07f038e026b41e46af44e0
When running test-case gdb.server/abspath.exp with host board
local-remote-host-notty, I get:
...
$ git sti
...
deleted: gdb/testsuite/gdb.xml/trivial.xml
...
This happens as follows. The test-case calls skip_gdbserver_test, which calls
gdb_skip_xml_test, which does:
...
set xml_file [gdb_remote_download host "${srcdir}/gdb.xml/trivial.xml"]
...
Then proc gdb_remote_download appends $xml_file (which for this particular
host board happens to be ${srcdir}/gdb.xml/trivial.xml) to cleanfiles, which
ends up being handled in gdb_finish by:
...
eval remote_file target delete $cleanfiles
...
The problem is that a host file is deleted using target delete.
Fix this by splitting cleanfiles up in cleanfiles_target and cleanfiles_host.
Tested on x86_64-linux.
When running test-case gdb.base/default.exp with target board
native-gdbserver, we get:
...
WARNING: Skipping backtrace and break tests because of GDB stub.
...
There's no need for such a warning, so remove it.
Tested on x86_64-linux with native and target board native-gdbserver.
With target board remote-gdbserver-on-localhost and gdb.arch/i386-mpx-call.exp
I run into:
...
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
...
This is due to the have_mpx test which should return 0, but instead returns 1
because the captured output:
...
No MPX support
No MPX support
...
does not match the used regexp:
...
set status [expr ($status == 0) \
&& ![regexp "^No MPX support\r\n" $output]]
...
which does match the captured output with native:
...
No MPX support^M
No MPX support^M
...
Fix this by making the \r in the regexp optional.
Tested on x86_64-linux, with native and target board
remote-gdbserver-on-localhost.
Fix some DUPLICATEs that we run into with target board
remote-gdbserver-on-localhost, by using test_with_prefix.
Tested on x86_64-linux, with native and target board
remote-gdbserver-on-localhost.
When running test-case gdb.server/solib-list.exp with target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) set solib-search-path $outputs/gdb.server/solib-list^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: \
set solib-search-path $outputs/gdb.server/solib-list
PATH: gdb.server/solib-list.exp: non-stop 0: \
set solib-search-path $outputs/gdb.server/solib-list
...
This is due to this code in gdb_load_shlib:
...
gdb_test "set solib-search-path [file dirname $file]" "" ""
...
Fix this by setting an explicit test name.
Tested on x86_64-linux, with native and target boards
remote-gdbserver-on-localhost, native-gdbserver and native-extended-gdbserver.
_bfd_check_format functions should not print errors or warnings if
they return NULL. A NULL return means the particular target under
test does not match, so there isn't any reason to make a complaint
about the target. In fact there isn't a good reason to warn even if
the target matches, except via the _bfd_per_xvec_warn mechanism; Some
other target might be a better match.
This patch tidies pe_bfd_object_p with the above in mind, and
restricts the PE optional header SectionAlignment and FileAlignment
fields somewhat. I chose to warn on nonsense values rather than
refusing to match. Refusing to match would be OK too.
PR 29653
* peXXigen.c (_bfd_XXi_swap_aouthdr_in): Don't emit error about
invalid NumberOfRvaAndSizes here. Limit loop copying data
directory to IMAGE_NUMBEROF_DIRECTORY_ENTRIES.
* peicode.h (pe_bfd_object_p): Don't clear and test bfd_error
around bfd_coff_swap_aouthdr_in. Warn on invalid SectionAlignment,
FileAlignment and NumberOfRvaAndSizes. Don't return NULL on
invalid NumberOfRvaAndSizes.
Read LSPEN, ASPEN and LSPACT bits from FPCCR and use them together
with FPCAR to identify if lazy FPU state preservation is active for
the current frame. See "Lazy context save of FP state", in B1.5.7,
also ARM AN298, supported by Cortex-M4F architecture for details on
lazy FPU register stacking. The same conditions are valid for other
Cortex-M cores with FPU.
This patch has been verified on a STM32F4-Discovery board by:
a) writing a non-zero value (lets use 0x1122334455667788 as an
example) to all the D-registers in the main function
b) configured the SysTick to fire
c) in the SysTick_Handler, write some other value (lets use
0x0022446688aaccee as an example) to one of the D-registers (D0 as
an example) and then do "SVC #0"
d) in the SVC_Handler, write some other value (lets use
0x0099aabbccddeeff) to one of the D-registers (D0 as an example)
In GDB, suspend the execution in the SVC_Handler function and compare
the value of the D-registers for the SVC_handler frame and the
SysTick_Handler frame. With the patch, the value of the modified
D-register (D0) should be the new value (0x009..eff) on the
SVC_Handler frame, and the intermediate value (0x002..cee) for the
SysTick_Handler frame. Now compare the D-register value for the
SysTick_Handler frame and the main frame. The main frame should
have the initial value (0x112..788).
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan ROUX <yvan.roux@foss.st.com>
After committing 8ba677d356 ("[gdb/symtab] Don't complain about function
decls") I noticed that quite a bit of code in read_func_scope is used to decide
whether to issue the "cannot get low and high bounds for subprogram DIE at
$hex" complaint, which executes unnecessarily if we have the default
"set complaints 0".
Fix this by (NFC):
- factoring out new static function have_complaint from macro complaint, and
- using it to wrap the relevant code in read_func_scope.
Tested on x86_64-linux.
