Mark Wielaard [Tue, 2 May 2023 18:23:32 +0000 (20:23 +0200)]
Pass const frame_info_ptr reference for skip_[language_]trampoline
g++ 13.1.1 produces a -Werror=dangling-pointer=
In file included from ../../binutils-gdb/gdb/frame.h:75,
from ../../binutils-gdb/gdb/symtab.h:40,
from ../../binutils-gdb/gdb/language.c:33:
In member function ‘void intrusive_list<T, AsNode>::push_empty(T&) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’,
inlined from ‘void intrusive_list<T, AsNode>::push_back(reference) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’ at gdbsupport/intrusive_list.h:332:24,
inlined from ‘frame_info_ptr::frame_info_ptr(const frame_info_ptr&)’ at gdb/frame.h:241:26,
inlined from ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’ at gdb/language.c:530:49:
gdbsupport/intrusive_list.h:415:12: error: storing the address of local variable ‘<anonymous>’ in ‘frame_info_ptr::frame_list.intrusive_list<frame_info_ptr>::m_back’ [-Werror=dangling-pointer=]
415 | m_back = &elem;
| ~~~~~~~^~~~~~~
gdb/language.c: In function ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’:
gdb/language.c:530:49: note: ‘<anonymous>’ declared here
530 | CORE_ADDR real_pc = lang->skip_trampoline (frame, pc);
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
gdb/frame.h:359:41: note: ‘frame_info_ptr::frame_list’ declared here
359 | static intrusive_list<frame_info_ptr> frame_list;
| ^~~~~~~~~~
Each new frame_info_ptr is being pushed on a static frame list and g++
cannot see why that is safe in case the frame_info_ptr is created and
destroyed immediately when passed as value.
It isn't clear why only in this one place g++ sees the issue (probably
because it can inline enough code in this specific case).
Since passing the frame_info_ptr as const reference is cheaper, use
that as workaround for this warning.
Oleg Tolmatcev [Wed, 3 May 2023 14:36:43 +0000 (15:36 +0100)]
Improve the speed of computing checksums for COFF binaries.
* coffcode.h (coff_read_word_from_buffer): New function.
* coffcode.h (COFF_CHECKSUM_BUFFER_SIZE): New constant.
* coffcode.h (coff_compute_checksum): Improve speed by reducing the number of seeks and reads used.
Alan Modra [Sun, 30 Apr 2023 11:12:30 +0000 (20:42 +0930)]
Generated docs and include files
bfd/doc/chew.c extracts documentation from source code comments
annotated with keywords, and generates much of bfd.h and libbfd.h from
those same comments. The docs have suffered from people (me too)
adding things like CODE_FRAGMENT to the source to put code into bfd.h
without realising that CODE_FRAGMENT also puts @example around said
code into the docs. So we have random senseless things in the docs.
This patch fixes that problem (well, the senseless things from
CODE_FRAGMENT), moves most of the code out of bfd-in.h, and improves a
few chew.c features. libbfd.h now automatically gets ATTRIBUTE_HIDDEN
prototypes, and indentation in bfd.h and libbfd.h is better.
Alan Modra [Wed, 3 May 2023 03:30:11 +0000 (13:00 +0930)]
Move bfd_alloc, bfd_zalloc and bfd_release to libbfd.c
These functions don't belong in opncls.c.
* libbfd-in.h (bfd_release): Delete prototype.
* opncls.c (bfd_alloc, bfd_zalloc, bfd_release): Move to..
* libbfd.c: ..here. Include objalloc.c and provide bfd_release
with a FUNCTION comment.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.
Alan Modra [Wed, 3 May 2023 03:17:15 +0000 (12:47 +0930)]
Move bfd_elf_bfd_from_remote_memory to opncls.c
bfd_elf_bfd_from_remote_memory is just a wrapper, and the function
could be implemented for other formats. Move it to opncls.c because
it acts a little like some of the other bfd_open* routines. Also give
it the usual FUNCTION etc. comment so prototypes and docs are handled
automatically.
Alan Modra [Tue, 2 May 2023 11:00:38 +0000 (20:30 +0930)]
hash.c: replace some unsigned long with unsigned int
* hash.c (higher_prime_number): Use uint32_t param, return value,
tables and variables.
(bfd_default_hash_table_size): Make it an unsigned int.
(bfd_hash_set_default_size): Use unsigned int param and return.
* bfd-in.h (bfd_hash_set_default_size): Update prototype.
* bfd-in2.h: Regenerate.
Alan Modra [Sat, 29 Apr 2023 01:30:30 +0000 (11:00 +0930)]
_bfd_mips_elf_lo16_reloc vallo comment
This explains exactly why the high reloc adjustment is as it is,
replacing the rather nebulous existing comment. I've also changed the
expression from (lo+0x8000)&0xffff to (lo&0xffff)^0x8000 which better
matches part of the standard 16-bit sign extension (resulting in
exactly the same value), and hoisted the calculation out of the loop.
* elfxx-mips.c (_bfd_mips_elf_lo16_reloc): Expand vallo
comment. Hoist calculation out of loop.
Initialize wpoffset_to_wpnumto avoid TCL error which happens in some aarch64 types.
ERROR: in testcase /root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
ERROR: can't read "wpoffset_to_wpnum(1)": no such element in array
ERROR: tcl error code TCL READ VARNAME
ERROR: tcl error info:
can't read "wpoffset_to_wpnum(1)": no such element in array
while executing
Mark Wielaard [Sat, 29 Apr 2023 20:46:11 +0000 (22:46 +0200)]
xcoffread.c: Fix -Werror=dangling-pointer= issue with main_subfile.
GCC 13 points out that main_subfile has local function scope, but a
pointer to it is assigned to the global inclTable array subfile
element field:
In function ‘void process_linenos(CORE_ADDR, CORE_ADDR)’,
inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:727:19,
inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:720:1:
xcoffread.c:629:37: error: storing the address of local variable ‘main_subfile’ in ‘*inclTable.19_45 + _28._inclTable::subfile’ [-Werror=dangling-pointer=]
629 | inclTable[ii].subfile = &main_subfile;
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
xcoffread.c: In function ‘void aix_process_linenos(objfile*)’:
xcoffread.c:579:18: note: ‘main_subfile’ declared here
579 | struct subfile main_subfile;
| ^~~~~~~~~~~~
xcoffread.c:496:19: note: ‘inclTable’ declared here
496 | static InclTable *inclTable; /* global include table */
| ^~~~~~~~~
Fix this by making main_subfile file static. And allocate and
deallocated together with inclTable in allocate_include_entry and
xcoff_symfile_finish. Adjust the use of main_subfile in
process_linenos to take a pointer to the subfile.
Aditya Kamath [Tue, 2 May 2023 15:08:14 +0000 (10:08 -0500)]
Fix Assertion pid != 0 failure in AIX.
In AIX if there is a main and a thread created from it , then once the
program completed execution and goes to pd_disable () inferior_ptid
had pid 0 leading to an assertion failure while finding the thread's data
in aix-thread.c file.
Tom Tromey [Sun, 16 Apr 2023 18:40:33 +0000 (12:40 -0600)]
Remove error_stream
error_stream is trivial and only used in a couple of spots in
breakpoint.c. This patch removes it in favor of just writing it out
at the spots where it was used.
Andrew Burgess [Tue, 2 May 2023 10:48:46 +0000 (11:48 +0100)]
gdb/testsuite: compile gdb.linespec/cp-completion-aliases.exp as C++
Noticed in passing that the prepare_for_testing call in
gdb.linespec/cp-completion-aliases.exp does not pass the 'c++' flag,
despite this being a C++ test.
I guess, as the source file has the '.cc' extension, all the compilers
are doing the right thing anyway -- the source file uses templates, so
is definitely being compiled as C++.
I noticed this when I tried to set CXX_FOR_TARGET (but not
CC_FOR_TARGET) and spotted that this script was still using the C
compiler.
Fixed in this commit by adding the 'c++' flag for prepare_for_testing.
Tom Tromey [Fri, 14 Apr 2023 18:16:58 +0000 (12:16 -0600)]
Document DAP 'launch' parameter
The Debugger Adapter Protocol defines a "launch" request but leaves
the parameters up to the implementation:
Since launching is debugger/runtime specific, the arguments for
this request are not part of this specification.
This patch adds some documentation for the parameter GDB currently
defines. Note that I plan to add more parameters here, and perhaps
there will be other extensions in time as well.
Simon Marchi [Fri, 28 Apr 2023 18:27:13 +0000 (14:27 -0400)]
gdb: remove ui_interp_info
I don't think that having struct ui_interp_info separated from struct ui
is very useful. As of today, it looks like an unnecessary indirection
layer. Move the contents of ui_interp_info directly into struct ui, and
update all users.
Simon Marchi [Fri, 28 Apr 2023 18:27:11 +0000 (14:27 -0400)]
gdb: move struct ui and related things to ui.{c,h}
I'd like to move some things so they become methods on struct ui. But
first, I think that struct ui and the related things are big enough to
deserve their own file, instead of being scattered through top.{c,h} and
event-top.c.
Tom de Vries [Sun, 30 Apr 2023 11:06:23 +0000 (13:06 +0200)]
[gdb/tui] Fix TUI resizing for TERM=ansi
With TERM=ansi, when resizing a TUI window from LINES/COLUMNS 31/118
(maximized) to 20/78 (de-maximized), I get a garbled screen (that ^L doesn't
fix) and a message:
...
@@ resize done 0, size = 77x20
...
with the resulting width being 77 instead of the expected 78.
[ The discrepancy also manifests in CLI, filed as PR30346. ]
The discrepancy comes from tui_resize_all, where we ask readline for the
screen size:
...
rl_get_screen_size (&screenheight, &screenwidth);
...
As it happens, when TERM is set to ansi, readline decides that the terminal
cannot auto-wrap lines, and reserves one column to deal with that, and as a
result reports back one less than the actual screen width:
...
$ echo $COLUMNS
78
$ TERM=xterm gdb -ex "show width" -ex q
Number of characters gdb thinks are in a line is 78.
$ TERM=ansi gdb -ex "show width" -ex q
Number of characters gdb thinks are in a line is 77.
...
In tui_resize_all, we need the actual screen width, and using a screenwidth of
one less than the actual value garbles the screen.
This is currently not causing trouble in testing because we have a workaround
in place in proc Term::resize. If we disable the workaround:
...
- stty columns [expr {$_cols + 1}] < $::gdb_tty_name
+ stty columns $_cols < $::gdb_tty_name
...
and dump the screen we get the same type of screen garbling:
...
0 +---------------------------------------+|
1 ||
2 ||
3 ||
...
Another way to reproduce the problem is using command "maint info screen".
After starting gdb with TERM=ansi, entering TUI, and issuing the command, we
get:
...
Number of characters curses thinks are in a line is 78.
...
and after maximizing and demaximizing the window we get:
...
Number of characters curses thinks are in a line is 77.
...
If we use TERM=xterm, we do get the expected 78.
Fix this by:
- detecting when readline will report back less than the actual screen width,
- accordingly setting a new variable readline_hidden_cols,
- using readline_hidden_cols in tui_resize_all to fix the resize problem, and
- removing the workaround in Term::resize.
The test-case gdb.tui/empty.exp serves as regression test.
I've applied the same fix in tui_async_resize_screen, the new test-case
gdb.tui/resize-2.exp serves as a regression test for that change. Without
that fix, we have:
...
FAIL: gdb.tui/resize-2.exp: again: gdb width 80
...
Latest libc++[1] causes transitive include to <locale> when
<mutex> or <thread> header is included. This causes
gdb to not build[2] since <locale> defines isupper/islower etc.
functions that are explicitly macroed-out in safe-ctype.h to
prevent their use.
Use the suggestion from libc++ to include <locale> internally when
building in C++ mode to avoid build errors.
Use safe-gdb-ctype.h as the include instead of "safe-ctype.h"
to keep this isolated to gdb since rest of binutils
does not seem to use much C++.
Tom de Vries [Sat, 29 Apr 2023 06:57:07 +0000 (08:57 +0200)]
[gdb/testsuite] Fix gdb.ada/excep_handle.exp for updated gdb_test
Test-case gdb.ada/excep_handle.exp fails since commit e2f620135d9
("gdb/testsuite: change newline patterns used in gdb_test"):
...
(gdb) continue^M
Continuing.^M
^M
Catchpoint 2, exception at 0x00000000004020b6 in foo () at foo.adb:26^M
26 when Constraint_Error =>^M
(gdb) FAIL: gdb.ada/excep_handle.exp: continuing to first Constraint_Error \
exception handlers
...
The output is supposed to be matched by:
...
gdb_test "continue" \
"Continuing\.$eol$catchpoint_constraint_error_msg$eol.*" \
"continuing to first Constraint_Error exception handlers"
...
but the $eol bit no longer matches due to the stricter matching introduced
in aforementioned commit.
Tom de Vries [Sat, 29 Apr 2023 05:04:27 +0000 (07:04 +0200)]
[gdb/build] Fix build without ncurses in maintenance_info_screen
With a build without ncurses we run into:
...
src/gdb/utils.c: In function ‘void maintenance_info_screen(const char*, int)’:
src/gdb/utils.c:1310:7: error: ‘COLS’ was not declared in this scope
COLS);
^~~~
src/gdb/utils.c:1331:8: error: ‘LINES’ was not declared in this scope
LINES);
^~~~~
...
Tom de Vries [Sat, 29 Apr 2023 05:00:34 +0000 (07:00 +0200)]
[gdb/testsuite] Fix gdb.tui/main.exp without TUI
With a build with --disable-tui, we get:
...
(gdb) PASS: gdb.tui/main.exp: set interactive-mode off
maint set tui-left-margin-verbose on^M
Undefined maintenance set command: "tui-left-margin-verbose on". \
Try "help maintenance set".^M
(gdb) FAIL: gdb.tui/main.exp: maint set tui-left-margin-verbose on
...
Fix this by adding the missing "require allow_tui_tests".
Andrew Burgess [Fri, 3 Mar 2023 23:17:39 +0000 (23:17 +0000)]
gdb/mi: check thread exists when creating thread-specific b/p
I noticed the following behaviour:
$ gdb -q -i=mi /tmp/hello.x
=thread-group-added,id="i1"
=cmd-param-changed,param="print pretty",value="on"
~"Reading symbols from /tmp/hello.x...\n"
(gdb)
-break-insert -p 99 main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401198",func="main",file="/tmp/hello.c",fullname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"}
(gdb)
info breakpoints
&"info breakpoints\n"
~"Num Type Disp Enb Address What\n"
~"1 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18\n"
&"../../src/gdb/thread.c:1434: internal-error: print_thread_id: Assertion `thr != nullptr' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable."
&"\n"
&"----- Backtrace -----\n"
&"Backtrace unavailable\n"
&"---------------------\n"
&"\nThis is a bug, please report it."
&" For instructions, see:\n"
&"<https://www.gnu.org/software/gdb/bugs/>.\n\n"
Aborted (core dumped)
What we see here is that when using the MI a user can create
thread-specific breakpoints for non-existent threads. Then if we try
to use the CLI 'info breakpoints' command GDB throws an assertion.
The assert is a result of the print_thread_id call when trying to
build the 'stop only in thread xx.yy' line; print_thread_id requires a
valid thread_info pointer, which we can't have for a non-existent
thread.
In contrast, when using the CLI we see this behaviour:
$ gdb -q /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) break main thread 99
Unknown thread 99.
(gdb)
The CLI doesn't allow a breakpoint to be created for a non-existent
thread. So the 'info breakpoints' command is always fine.
Interestingly, the MI -break-info command doesn't crash, this is
because the MI uses global thread-ids, and so never calls
print_thread_id. However, GDB does support using CLI and MI in
parallel, so we need to solve this problem.
One option would be to change the CLI behaviour to allow printing
breakpoints for non-existent threads. This would preserve the current
MI behaviour.
The other option is to pull the MI into line with the CLI and prevent
breakpoints being created for non-existent threads. This is good for
consistency, but is a breaking change for the MI.
In the end I figured that it was probably better to retain the
consistent CLI behaviour, and just made the MI reject requests to
place a breakpoint on a non-existent thread. The only test we had
that depended on the old behaviour was
gdb.mi/mi-thread-specific-bp.exp, which was added by me in commit:
gdb: don't duplicate 'thread' field in MI breakpoint output
I certainly didn't intend for this test to rely on this feature of the
MI, so I propose to update this test to only create breakpoints for
threads that exist.
Actually, I've added a new test that checks the MI rejects creating a
breakpoint for a non-existent thread, and I've also extended the test
to run with the separate MI/CLI UIs, and then tested 'info
breakpoints' to ensure this command doesn't crash.
I've extended the documentation of the `-p` flag to explain the
constraints better.
I have also added a NEWS entry just in case someone runs into this
issue, at least then they'll know this change in behaviour was
intentional.
One thing that I did wonder about while writing this patch, is whether
we should treat requests like this, on both the MI and CLI, as another
form of pending breakpoint, something like:
(gdb) break foo thread 9
Thread 9 does not exist.
Make breakpoint pending on future thread creation? (y or [n]) y
Breakpoint 1 (foo thread 9) pending.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> foo thread 9
Don't know if folk think that would be a useful idea or not? Either
way, I think that would be a separate patch from this one.
Andrew Burgess [Tue, 4 Apr 2023 11:11:50 +0000 (12:11 +0100)]
gdb: make set/show inferior-tty work with $_gdb_setting_str
Like the previous two commits, this commit fixes set/show inferior-tty
to work with $_gdb_setting_str.
Instead of using a scratch variable which is then pushed into the
current inferior from a set callback, move to the API that allows for
getters and setters, and store the value directly within the current
inferior.
Update an existing test to check the inferior-tty setting.
Andrew Burgess [Fri, 28 Apr 2023 21:14:53 +0000 (22:14 +0100)]
gdb: make set/show cwd work with $_gdb_setting_str
The previous commit fixed set/show args when used with
$_gdb_setting_str, this commit fixes set/show cwd.
Instead of using a scratch variable which is then pushed into the
current inferior from a set callback, move to the API that allows for
getters and setters, and store the value directly within the current
inferior.
Update the existing test to check the cwd setting.
Andrew Burgess [Tue, 4 Apr 2023 08:56:00 +0000 (09:56 +0100)]
gdb: make set/show args work with $_gdb_setting_str
I noticed that $_gdb_setting_str was not working with 'args', e.g.:
$ gdb -q --args /tmp/hello.x arg1 arg2 arg3
Reading symbols from /tmp/hello.x...
(gdb) show args
Argument list to give program being debugged when it is started is "arg1 arg2 arg3".
(gdb) print $_gdb_setting_str("args")
$1 = ""
This is because the 'args' setting is implemented using a scratch
variable ('inferior_args_scratch') which is updated when the user does
'set args ...'. There is then a function 'set_args_command' which is
responsible for copying the scratch area into the current inferior.
However, when the user sets the arguments via the command line the
scratch variable is not updated, instead the arguments are pushed
straight into the current inferior.
There is a second problem, when the current inferior changes the
scratch area is not updated, which means that the value returned will
only ever reflect the last call to 'set args ...' regardless of which
inferior is currently selected.
Luckily, the fix is pretty easy, set/show variables have an
alternative API which requires we provide some getter and setter
functions. With this done the scratch variable can be removed and the
value returned will now always reflect the current inferior.
While working on set/show args I also rewrote show_args_command to
remove the use of deprecated_show_value_hack.
Andrew Burgess [Tue, 4 Apr 2023 08:34:54 +0000 (09:34 +0100)]
gdb: cleanup command creation in infcmd.c
In infcmd.c, in order to add command completion to some of the 'set'
commands, we are currently creating the command, then looking up the
command by calling lookup_cmd.
This is no longer necessary, we already return the relevant
cmd_list_element object when the set/show command is created, and we
can use that to set the command completion callback.
I don't know if there's actually any tests for completion of these
commands, but I manually checked, and each command still appears to
offer the expected filename completion.
There should be no user visible changes after this commit.
Simon Marchi [Thu, 27 Apr 2023 18:54:07 +0000 (14:54 -0400)]
gdb/record-full: disable range stepping when resuming threads
I see these failures, when running with the native-gdbserver of
native-extended-gdbserver boards:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ...
FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body
FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body
FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body
FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body
Let's use this simpler program to illustrate the problem:
int main()
{
int a = 362;
a = a * 17;
return a;
}
It compiles down to:
int a = 362;
401689: c7 45 fc 6a 01 00 00 movl $0x16a,-0x4(%rbp)
a = a * 17;
401690: 8b 55 fc mov -0x4(%rbp),%edx
401693: 89 d0 mov %edx,%eax
401695: c1 e0 04 shl $0x4,%eax
401698: 01 d0 add %edx,%eax
40169a: 89 45 fc mov %eax,-0x4(%rbp)
return a;
40169d: 8b 45 fc mov -0x4(%rbp),%eax
When single stepping these lines, debugging locally, while recording,
these are the recorded instructions (basically one for each instruction
shown above):
(gdb) maintenance print record-instruction 0
Register rdx changed: 140737488346728
Register rip changed: (void (*)()) 0x401690 <main+11>
(gdb) maintenance print record-instruction -1
4 bytes of memory at address 0x00007fffffffdc7c changed from: 00 00 00 00
Register rip changed: (void (*)()) 0x401689 <main+4>
(gdb) maintenance print record-instruction -2
Not enough recorded history
In this list, we only have entries for the beginning of each line. This
is because of the remote target's support for range stepping. The
record-full layer can only record instructions when the underlying
process target reports a stop. With range stepping, the remote target
single-steps multiple instructions at a time, so the record-full target
doesn't get to see and record them all.
Fix this by making the record-full layer disable range-stepping
before handing the resume request to the beneath layer, forcing the
remote target to report stops for each instruction.
Keith Seitz [Fri, 28 Apr 2023 17:43:20 +0000 (10:43 -0700)]
Allow strings with printf/eval
PR 13098 explains that if a user attempts to use a string with either
`printf' (or `eval'), gdb returns an error (inferior not running):
(gdb) printf "%s\n", "hello"
evaluation of this expression requires the target program to be active
However, the parser can certainly handle this case:
(gdb) p "hello"
$1 = "hello"
This discrepancy occurs because printf_c_string does not handle
this specific case. The passed-in value that we are attempting to print
as a string is TYPE_CODE_ARRAY but it's lval type is not_lval.
printf_c_string will only attempt to print a string from the value's
contents when !TYPE_CODE_PTR, lval is lval_internalvar, and the value's
type is considered a string type:
Otherwise, it attempts to read the value of the string from the target's
memory (which is what actually generates the "evaluation of this ..."
error message).
Tom Tromey [Thu, 27 Apr 2023 19:25:27 +0000 (13:25 -0600)]
Do not change type in get_discrete_low_bound
get_discrete_low_bound has this code:
/* Set unsigned indicator if warranted. */
if (low >= 0)
type->set_is_unsigned (true);
It's bad to modify a type in a getter like this, so this patch removes
this code. FWIW I looked and this code has been there since at least
1999 (it was in the initial sourceware import).
Types in general would benefit from const-ification, which would
probably reveal more code like this, but I haven't attempted that.
Tom Tromey [Thu, 6 Apr 2023 14:24:06 +0000 (08:24 -0600)]
Remove @var from @defun in Python documentation
Eli pointed out that @var isn't needed in @defun in Texinfo. This
patch removes the cases I found in python.texi. I also renamed some
variables in one spot, because "-" isn't valid in a Python variable
name.
gdb/testsuite: change newline patterns used in gdb_test
There were some regressions in gdb.trace/*.exp tests when run with the
native-gdbserver board. This commit fixes these regressions.
All the problems are caused by unnecessary trailing newline characters
included in the patterns passed to gdb_test. After the above commit
the testsuite is stricter when matching trailing newlines, and so the
additional trailing newline characters are now causing the test to
fail. Fix by removing all the excess trailing newline characters.
In some cases this cleanup means we should use gdb_test_no_output,
I've done that where appropriate. In a couple of other places I've
made use of multi_line to better build the expected output pattern.
Nelson Chu [Fri, 21 Apr 2023 08:28:39 +0000 (16:28 +0800)]
RISC-V: Enable x0 base relaxation for relax_pc even if --no-relax-gp.
Let --no-relax-gp only disable the gp relaxation for lui and pcrel
relaxations, since x0 base and gp relaxations are different optimizations
in fact, but just use the same function to handle.
bfd/
* elfnn-riscv.c (_bfd_riscv_relax_pc): Like _bfd_riscv_relax_lui,
set gp to zero when --no-relax-gp, then we should still keep the
x0 base relaxation.
(_bfd_riscv_relax_section): Enable _bfd_riscv_relax_pc when
--no-relax-gp, we will disable the gp relaxation in the
_bfd_riscv_relax_pc.
Nelson Chu [Fri, 21 Apr 2023 08:28:38 +0000 (16:28 +0800)]
RISC-V: Relax R_RISCV_[PCREL_]LO12_I/S to R_RISCV_GPREL_I/S for undefined weak.
bfd/
*elfnn-riscv.c (_bfd_riscv_relax_lui): For undefined weak symbol,
just relax the R_RISCV_LO12_I/S to R_RISCV_GPREL_I/S, and then don't
update the rs1 to zero until relocate_section.
(_bfd_riscv_relax_pc): Likewise, but for R_RISCV_PCREL_LO12_I/S.
Jan Beulich [Fri, 28 Apr 2023 06:19:53 +0000 (08:19 +0200)]
gas: move shift count check
... out of mainline code, grouping together the two case labels. This
then also make more obvious that the comment there applies to both forms
of shifts.
Jan Beulich [Fri, 28 Apr 2023 06:19:34 +0000 (08:19 +0200)]
x86: rework AMX control insn disassembly
Consistently do 64-bit first, VEX.L second, VEX.W third, ModR/M fourth,
and only then prefix, resulting in fewer table entries. Note that in the
course of the re-work
- TILEZERO has a previously missing decode step through rm_table[]
added,
- a wrong M_0 suffix for TILEZERO is also corrected to be M_1 (now an
infix).
Jan Beulich [Fri, 28 Apr 2023 06:19:19 +0000 (08:19 +0200)]
x86: rework AMX multiplication insn disassembly
Consistently do 64-bit first, ModR/M second, VEX.L third, VEX.W fourth,
and prefix last, resulting in fewer table entries. Note that in the
course of the re-work wrong M_0 suffixes are also corrected to be M_1
(partly infixes now).
Since it ended up confusing while testing the change, also adjust the
test name in x86-64-amx-bad.d (to be distinct from x86-64-amx.d's).
Alan Modra [Fri, 28 Apr 2023 01:41:09 +0000 (11:11 +0930)]
Re: Keeping track of rs6000-coff archive element pointers
Commit de7b90610e9e left a hole in the element checking, explained by
the comment added to _bfd_xcoff_openr_next_archived_file. While
fixing this, tidy some types used to hold unsigned values so that
casts are not needed to avoid signed/unsigned comparison warnings.
Also tidy a few things in xcoff.h.
bfd/
* coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Check
that we aren't pointing back at the last element. Make
filestart a ufile_ptr. Update for xcoff_artdata change.
(_bfd_strntol, _bfd_strntoll): Return unsigned values.
(_bfd_xcoff_slurp_armap): Make off a ufile_ptr.
(add_ranges): Update for xcoff_artdata change.
* libbfd-in.h (struct artdata): Make first_file_filepos a
ufile_ptr.
* libbfd.h: Regenerate.
include/
* coff/xcoff.h (struct xcoff_artdata): Replace min_elt with
ar_hdr_size.
(xcoff_big_format_p): In the !SMALL_ARCHIVE case return true
for anything but a small archive.
Michael Matz [Tue, 25 Apr 2023 15:10:05 +0000 (17:10 +0200)]
Fix PR30358, performance with --sort-section
since af31506c we only use the binary tree when section sorting is
required. While its unbalanced and hence can degrade to a linear list
it should otherwise have been equivalent to the old code relying on
insertion sort. Unfortunately it was not. The old code directly used
lang_add_section to populate the sorted list, the new code first
populates the tree and only then does lang_add_section on the sorted
result.
In the testcase we have very many linkonce section groups, and hence
lang_add_section won't actually insert anything for most of them. That
limited the to-be-sorted list length previously. The tree-sorting code
OTOH first created a tree of all candidates sections, including those
that wouldn't be inserted by lang_add_section, hence increasing the size
of the sorting problem. In the testcase the chain length went from
about 1500 to 106000, and in the degenerated case (as in the testcase)
that goes in quadratically.
This splits out most of the early-out code from lang_add_section to its
own function and uses the latter to avoid inserting into the tree. This
refactoring slightly changes the order of early-out tests (the ones
based on section flags is now done last, and only in lang_add_section).
The new function is not a pure predicate: it can give warnings and it
might change output_section, like the old early-out code did. I have
also added a skip-warning case in the first discard case, whose
non-existence seemed to have been an oversight.
PR 30358
* ldlang.c (wont_add_section_p): Split out from ...
(lang_add_section): ... here.
(output_section_callback_sort): Use wont_add_section_p to not
always add sections to the sort tree.
Andrew Burgess [Mon, 24 Apr 2023 14:27:27 +0000 (15:27 +0100)]
gdb/doc: extend the documentation of the jump command
This commit addresses PR gdb/7946. While checking for bugs relating
to the jump command I noticed a long standing bug that points out a
deficiency with GDB's documentation of the jump command.
The bug points out that 'jump 0x...' is not always the same as 'set
$pc = 0x...' and then 'continue'. Writing directly to the $pc
register does not update any auxiliary state, e.g. $npc on SPARC,
while using 'jump' does.
It felt like this would be an easy issue to address by adding a
paragraph to the docs, so I took a stab at writing something suitable.
Andrew Burgess [Wed, 29 Mar 2023 09:41:07 +0000 (10:41 +0100)]
gdb/testsuite: special case '^' in gdb_test pattern
In this commit I propose that we add special handling for the '^' when
used at the start of a gdb_test pattern. Consider this usage:
gdb_test "some_command" "^command output pattern"
I think the intention here is pretty clear - run 'some_command', and
the output from the command should be exactly 'command output
pattern'.
After the previous commit which tightened up how gdb_test matches the
final newline and prompt we know that the only thing after the output
pattern will be a single newline and prompt, and the leading '^'
ensures that there's no output before 'command output pattern', so
this will do what I want, right?
... except it doesn't. The command itself will also needs to be
matched, so I should really write:
but this all gets a bit verbose, so in most cases I simply don't
bother anchoring the output with a '^', and a quick scan of the
testsuite would indicate that most other folk don't both either.
What I propose is this: the *only* thing that can appear immediately
after the '^' is the command converted into a regexp, so lets do that
automatically, moving the work into gdb_test. Thus, when I write:
gdb_test "some_command" "^command output pattern"
Inside gdb_test we will spot the leading '^' in the pattern, and
inject the regexp version of the command after the '^', followed by a
'\r\n'.
My hope is that given this new ability, folk will be more inclined to
anchor their output patterns when this makes sense to do so. This
should increase our ability to catch any unexpected output from GDB
that appears as a result of running a particular command.
There is one problem case we need to consider, sometime people do
this:
gdb_test "" "^expected output pattern"
In this case no command is sent to GDB, but we are still expecting
some output from GDB. This might be a result of some asynchronous
event for example. As there is no command sent to GDB (from the
gdb_test) there will be no command text to parse.
In this case my proposed new feature injects the command regexp, which
is the empty string (as the command itself is empty), but still
injects the '\r\n' after the command regexp, thus we end up with this
pattern:
^\r\nexpected output pattern
This extra '\r\n' is not what we should expected here, and so there is
a special case inside gdb_test -- if the command is empty then don't
add anything after the '^' character.
There are a bunch of tests that do already use '^' followed by the
command, and these can all be simplified in this commit.
I've tried to run all the tests that I can to check this commit, but I
am certain that there will be some tests that I manage to miss.
Apologies for any regressions this commit causes, hopefully fixing the
regressions will not be too hard.
Andrew Burgess [Thu, 30 Mar 2023 12:26:25 +0000 (13:26 +0100)]
gdb/testsuite: change newline patterns used in gdb_test
This commit makes two changes to how we match newline characters in
the gdb_test proc.
First, for the newline pattern between the command output and the
prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'.
The old pattern would spot multiple newlines, and so there are a few
places where, as part of this commit, I've needed to add an extra
trailing '\r\n' to the pattern in the main test file, where GDB's
output actually includes a blank line.
But I think this is a good thing. If a command produces a blank line
then we should be checking for it, the current gdb_test doesn't do
that. But also, with the current gdb_test, if a blank line suddenly
appears in the output, this is going to be silently ignored, and I
think this is wrong, the test should fail in that case.
Additionally, the existing pattern will happily match a partial
newline. There are a strangely large number of tests that end with a
random '.' character. Not matching a literal period, but matching any
single character, this is then matching half of the trailing newline
sequence, while the \[\r\n\]+ in gdb_test is matching the other half
of the sequence. I can think of no reason why this would be
intentional, I suspect that the expected output at one time included a
period, which has since been remove, but I haven't bothered to check
on this. In this commit I've removed all these unneeded trailing '.'
characters.
The basic rule of gdb_test after this is that the expected pattern
needs to match everything up to, but not including the newline
sequence immediately before the GDB prompt. This is generally how the
proc is used anyway, so in almost all cases, this commit represents no
significant change.
Second, while I was cleaning up newline matching in gdb_test, I've
also removed the '[\r\n]*' that was added to the start of the pattern
passed to gdb_test_multiple.
The addition of this pattern adds no value. If the user pattern
matches at the start of a line then this would match against the
newline sequence. But, due to the '*', if the user pattern doesn't
match at the start of a line then this group doesn't care, it'll
happily match nothing.
As such, there's no value to it, it just adds more complexity for no
gain, so I'm removing it. No tests will need updating as a
consequence of this part of the patch.
Andrew Burgess [Thu, 30 Mar 2023 12:26:13 +0000 (13:26 +0100)]
gdb/testsuite: use 'return' in gdb_test_no_output
A TCL proc will return the return value of the last command executed
within the proc's body if there is no explicit return call, so
gdb_test_no_output is already returning the return value of
gdb_test_multiple.
However, I'm not a fan of (relying on) this implicit return value
behaviour -- I prefer to be explicit about what we are doing. So in
this commit I have extended the comment on gdb_test_no_output to
document the possible return values (just as gdb_test does), and
explicitly call return.
This should make no different to our testing, but I think it's clearer
now what the gdb_test_no_output proc is expected to do.
The two tests gdb.base/auxv.exp and gdb.base/list.exp both rely on the
return value of gdb_test_no_output, and continue to pass after this
change.
I also spotted that gdb.base/watchpoint.exp could be updated to make
use of gdb_test_no_output, so I did that.
Andrew Burgess [Thu, 30 Mar 2023 12:25:59 +0000 (13:25 +0100)]
gdb: remove some trailing newlines from warning messages
While working on a later patch in this series, which tightens up some
of our pattern matching when using gdb_test, I ran into some failures
caused by some warnings having a trailing newline character.
The warning function already adds a trailing newline, and it is my
understanding that we should not be adding a second by including a
newline at the end of any warning message.
The problem cases I found were in language.c and remote.c, in this
patch I fix the cases I hit, but I also checked all the other warning
calls in these two files and removed any additional trailing newlines
I found.
In remote.c the warning actually had a newline character in the middle
of the warning message (in addition to the trailing newline), which
I've removed. I don't think it's helpful to forcibly split a warning
as was done here -- in the middle of a sentence. Additionally, the
message isn't even that long (71 characters), so I think removing this
newline is an improvement.
None of the expected test result need updating with this commit,
currently the patterns in gdb_test will match one or more newline
sequences, so the tests are as happy with one newline (after this
commit) as they are with two newlines (before this commit). A later
commit will change gdb_test so that it is not so forgiving, and these
warnings would have caused some failures.
Andrew Burgess [Fri, 31 Mar 2023 15:41:27 +0000 (16:41 +0100)]
gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp
I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes
fail when run from a particular directory.
The test tries to find the number of the first internal breakpoint
using this proc:
proc get_first_maint_bp_num { } {
gdb_test_multiple "maint info break" "find first internal bp num" {
-re -wrap "(-\[0-9\]).*" {
return $expect_out(1,string)
}
}
return ""
}
The problem is, at the time we issue 'maint info break' there are both
internal breakpoint and non-internal (user created) breakpoints in
place. The user created breakpoints include the path to the source
file.
Sometimes, I'll be working from a directory that includes a number,
like '/tmp/blah-1/gdb/etc', in which case the pattern above actually
matches the '-1' from 'blah-1'. In this case there's no significant
problem as it turns out that -1 is the number of the first internal
breakpoint.
Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which
case the above pattern patches '-4' from 'blah-4'. It turns out this
is also not a problem -- the test doesn't actually need the first
internal breakpoint number, it just needs the number of any internal
breakpoint.
But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in
which case the pattern above matches '-0' from 'blah-0', and in this
case the test fails - there is no internal breakpoint '-0'.
Fix this by spotting that the internal breakpoint numbers always
occurs after a '\r\n', and that they never start with a 0. Our
pattern becomes:
Philipp Tomsich [Wed, 26 Apr 2023 20:09:34 +0000 (14:09 -0600)]
RISC-V: Support XVentanaCondOps extension
Ventana Micro has published the specification for their
XVentanaCondOps ("conditional ops") extension at
https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
which contains two new instructions
- vt.maskc
- vt.maskcn
that can be used in constructing branchless sequences for
various conditional-arithmetic, conditional-logical, and
conditional-select operations.
To support such vendor-defined instructions in the mainline binutils,
this change also adds a riscv_supported_vendor_x_ext secondary
dispatch table (but also keeps the behaviour of allowing any unknow
X-extension to be specified in addition to the known ones from this
table).
As discussed, this change already includes the planned/agreed future
requirements for X-extensions (which are likely to be captured in the
riscv-toolchain-conventions repository):
- a public specification document is available (see above) and is
referenced from the gas-documentation
- the naming follows chapter 27 of the RISC-V ISA specification
- instructions are prefixed by a vendor-prefix (vt for Ventana)
to ensure that they neither conflict with future standard
extensions nor clash with other vendors
* doc/c-riscv.texi: Add section to list custom extensions and
their documentation URLs.
* testsuite/gas/riscv/x-ventana-condops.d: New test.
* testsuite/gas/riscv/x-ventana-condops.s: New test.
This patch expands the GAS BPF testsuite in order to also test the
alternative pseudo-C syntax used in BPF assembly.
This includes three main changes:
- Some general GAS tests involving assignment and equality operands in
expressions (such as = and ==) are disabled in bpf-* targets,
because the syntax collides with the pseudo-C BPF assembly syntax.
- New tests are added to the BPF GAS testsuite that test the pseudo-c
syntax. Tests for all BPF instructions are included.
- New tests are added to the BPF GAS testsuite that test the support
for both syntaxes in the same source.
gas/ChangeLog:
2023-04-20 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
PR gas/29728
* testsuite/gas/all/assign-bad-recursive.d: Skip test in bpf-*
targets.
* testsuite/gas/all/eqv-dot.d: Likewise.
* testsuite/gas/all/gas.exp: Skip other assignment tests in bpf-*.
* testsuite/gas/bpf/alu-pseudoc.s: New file.
* testsuite/gas/bpf/pseudoc-normal.s: Likewise.
* testsuite/gas/bpf/pseudoc-normal.d: Likewise.
* testsuite/gas/bpf/pseudoc-normal-be.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
* testsuite/gas/bpf/lddw-pseudoc.s: Likewise.
* testsuite/gas/bpf/jump32-pseudoc.s: Likewise.
* testsuite/gas/bpf/jump-pseudoc.s: Likewise.
* testsuite/gas/bpf/indcall-1-pseudoc.s: Likewise.
* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
* testsuite/gas/bpf/*.d: Add -pseudoc variants of the tests.
This patch adds support to the GNU assembler for an alternative
assembly syntax used in BPF. This syntax is C-like and very
unconventional for an assembly language, but it is generated by
clang/llvm and is also used in inline asm templates in kernel code, so
we ought to support it.
After this patch, the assembler is able to parse instructions in both
supported syntax: the normal assembly-like syntax and the pseudo-C
syntax. Instruction formats can be mixed in the source program: the
assembler recognizes the right syntax to use.
gas/ChangeLog:
2023-04-20 Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
Tom de Vries [Wed, 26 Apr 2023 16:15:56 +0000 (18:15 +0200)]
[gdb/tui] Fix length of status line string
In commit 5d10a2041eb ("gdb: add string_file::release method") this was added:
...
+ std::string string_val = string.release ();
...
without updating subsequent uses of string.size (), which returns 0 after the
string.release () call.
Fix this by:
- using string_val.size () instead of string.size (), and
- adding an assert that would have caught this regression.
Tested on x86_64-linux.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
PR tui/30389
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30389
Tom Tromey [Mon, 17 Apr 2023 18:59:57 +0000 (12:59 -0600)]
Rewrite gdb_mpz::operator==
Simon pointed out that the recent changes to gdb_mpz caused a build
failure on amd64 macOS. It turns out to be somewhat difficult to
overload a method in a way that will work "naturally" for all integer
types; especially in a case like gdb_mpz::operator==, where it's
desirable to special case all integer types that are no wider than
'long'.
After a false start, I came up with this patch, which seems to work.
It applies the desirable GMP special cases directly in the body,
rather than via overloads.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Wed, 26 Apr 2023 01:01:01 +0000 (10:31 +0930)]
i386-dis.c UB shift and other tidies
1) i386-dis.c:12055:11: runtime error: left shift of negative value -1
Bit twiddling is best done unsigned, due to UB on overflow of signed
expressions. Fix this by using bfd_vma rather than bfd_signed_vma
everywhere in i386-dis.c except print_displacement.
2) Return get32s and get16 value in a bfd_vma, reducing the need for
temp variables.
3) Introduce get16s and get8s functions to simplify the code.
4) With some optimisation options gcc-13 legitimately complains about
a fall-through in OP_I. Fix that. OP_I also doesn't need to use
"mask" which was wrong for w_mode anyway.
5) Masking with & 0xffffffff is better than casting to unsigned. We
don't know for sure that unsigned int is 32-bit.
6) We also don't know that unsigned char is 8 bits. Mask codep
accesses everywhere. I don't expect binutils will work on anything
other than an 8-bit char host, but if we are masking codep accesses in
some places we might as well be consistent. (Better would be to use
stdint.h types more in binutils.)
Alan Modra [Wed, 26 Apr 2023 00:29:40 +0000 (09:59 +0930)]
binutils runtest $CC
I noticed in the binutile Makefile that runtest is being invoked with
CC, CC_FOR_BUILD and other compiler related flags in the environment.
That doesn't work. Those variables ought to be passed on the runtest
command line.
After fixing that I had some fails due to binutils testprog.c now
being compiled with the default "-g -O2" picked up in
CFLAGS_FOR_TARGET. Hack around that by passing -O0.
Also, with the binutils testsuite now taking notice of CC_FOR_TARGET,
I found a couple of debuginfod.exp fails with one of my compilers that
happened to be built without --debug-id being enabled by default.
* Makefile.am (check-DEJAGNU): Pass $CC and other variable on
the runtest command line rather than futilely in the
environment. Add -O0 to CFLAGS_FOR_TARGET.
* Makefile.in: Regenerate.
* testsuite/binutils-all/debuginfod.exp: Compile testprog.c
with -Wl,--build-id.
Tom Tromey [Mon, 24 Apr 2023 18:25:53 +0000 (12:25 -0600)]
Use scoped_restore in varobj.c
One spot in varobj.c should use scoped_restore to save and restore
input_radix. Note that the current code may fail to restore it on
error, so this patch fixes a latent bug.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Michael Matz [Tue, 18 Apr 2023 14:16:01 +0000 (16:16 +0200)]
section-select: Fix performance problem (PR30367)
when using many wild-statements with non-wildcard filenames we
were running into quadraticness via repeatedly using lookup_name
on a long list of loaded files. I've originally retained using
lookup_name because that preserved existing behaviour most obviously.
In particular in matching wild-statements when using a non-wildcard
filename it matches against local_sym_name, not the filename member.
If the wildspec would have an archive-spec or a wildcard it would use
the filename member, though. Also it would load the named file
(and ignore it, as being not equal to the currently considered
input-statement).
Rewrite this to not use lookup_name but retain the comparison
against local_sym_name with a comment to that effect.
PR 30367
* ldlang.c (walk_wild_section_match): Don't use lookup_name
but directly compare spec and local_sym_name.
Jan Beulich [Tue, 25 Apr 2023 09:19:18 +0000 (11:19 +0200)]
RISC-V: adjust logic to avoid register name symbols
Special casing GPR names in my_getSmallExpression() leads to a number of
inconsistencies. Generalize this by utilizing the md_parse_name() hook,
limited to when instruction operands are being parsed (really: probed).
Then both the GPR lookup there and the yet more ad hoc workaround for
PR/gas 29940 can be removed (including its extension needed for making
the compressed form JAL work again).
Jan Beulich [Tue, 25 Apr 2023 09:18:49 +0000 (11:18 +0200)]
RISC-V: test for expected / no unexpected symbols
Both the temporary workaround for PR/gas 29940 and the existing special
casing of GPRs in my_getSmallExpression() aren't really tested anywhere
(i.e. with the workarounds remove testing would still succeed). Nor is
there any test for uses of symbols with names matching GPRs, where such
is permitted. Before altering how this is to be dealt with, install two
testcases covering the expected behavior. (For now this includes only
known affected insns; re-ordering of entries in riscv_opcodes[] could,
however, yield more of them.)
Jan Beulich [Tue, 25 Apr 2023 09:17:19 +0000 (11:17 +0200)]
RISC-V: don't recognize bogus relocations
With my_getSmallExpression() consistently and silently failing on
relocation operators not fitting an insn, it is no longer necessary to
hand it percent_op_itype[] "just in case" (i.e. to avoid errors when a
subsequent parsing attempt for another operand combination might
succeed). This also eliminates the latent problem of percent_op_itype[]
and percent_op_stype[] growing a non-identical set of recognized
relocation operators.
Jan Beulich [Tue, 25 Apr 2023 09:16:44 +0000 (11:16 +0200)]
RISC-V: avoid redundant and misleading/wrong error messages
The use of a wrong (for the insn) relocation operator (or a future one
which simply isn't recognized by older gas yet) doesn't render the (rest
of the) expression "bad". Furthermore alongside the error from
expression() in most cases the parser would emit another error then
anyway. Suppress the call to my_getExpression() in such a case,
arranging for a guaranteed subsequent error message by marking the
expression "illegal".
Jan Beulich [Tue, 25 Apr 2023 09:16:07 +0000 (11:16 +0200)]
RISC-V: drop "percent_op" parameter from my_getOpcodeExpression()
Both callers check for no relocations, so there's no point parsing for
some. Have the function pass percent_op_null into
my_getSmallExpression(). Note that there's no point passing
percent_op_itype: Elsewhere, especially when processing compressed alias
insns ahead of non-alias ones, this has the effect of avoiding "bad
expression" errors when another parsing pass may follow (and succeed).
Here, however, all alternative forms of an insn type will again start
with the same O4 or O2, so avoiding errors earlier on doesn't really
help. Plus constructs with a relocation specifier (as percent_op_itype
would permit) can't be specified anyway, as the scrubber eats the
whitespace between .insn's type and the O4 or O2 expression when that
starts with % or ( - i.e. these will be seen as e.g. "i%lo(x)", and
riscv_ip() looks only for whitespace when finding the end of a mnemonic.
Jan Beulich [Tue, 25 Apr 2023 09:15:25 +0000 (11:15 +0200)]
RISC-V: minor effort reduction in relocation specifier parsing
The sole caller of parse_relocation() has already checked for the %
prefix, so there's no need to check for it again in the strncasecmp()
and there's also no reason to make the involved string literals longer
than necessary.
Tom de Vries [Tue, 25 Apr 2023 06:33:57 +0000 (08:33 +0200)]
[gdb/testsuite] Fix timeout in gdb.tui/empty.exp
In test-case gdb.tui/empty.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/empty.exp: src: 90x40: box 1
...
We timeout here in Term::resize:
...
# Due to the strange column resizing behavior, and because we
# don't care about this intermediate resize, we don't check
# the size here.
wait_for "@@ resize done $_resize_count"
...
because the string we're trying to match is split over two lines:
...
25 -----------------------------------------------------------------------------+No
26 ne No process In: L?? PC: ?? @@
27 resize done 0, size = 79x40
28 (gdb)
...
Tom de Vries [Tue, 25 Apr 2023 06:33:57 +0000 (08:33 +0200)]
[gdb/testsuite] Fix timeout in gdb.tui/completion.exp
With test-case gdb.tui/completion.exp, we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/completion.exp: check focus completions
...
The timeout happens in this command:
...
Term::command "layout src"
...
which waits for:
- "(gdb) layout src", and then
- "(gdb) ".
Because the "layout src" command enables the TUI there's just a prompt.
projects / thirdparty / binutils-gdb.git / log
