There are two new debug architecture version entries. I updated the
code for Linux, but fbsd also needs updating.
This patch does this, and should be pretty straightforward.
I can't test this on native fbsd, but I'm fairly confident it should
work.
Signed-off-by: Luis Machado <luis.machado@arm.com>
Teach gdb about a new debug architecture version for AArch64 (0x11).
No user-visible changes.
Regression-tested on aarch64-linux Ubuntu 20.04/22.04.
Signed-off-by: Luis Machado <luis.machado@arm.com>
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.)
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.
write.c:415:7: error: dangling pointer ‘prev_frag’ to ‘dummy’ may be used
* write.c (chain_frchains_together_1): Rewrite loop as a do
while to avoid false positive -Wdangling-pointer.
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>
parser_state::push_dollar has some unnecessary "goto"s. Replacing
them cleans up the code. Regression tested on x86-64 Fedora 36.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
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.
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).
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.)
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.
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".
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.
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.
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)
...
Fix this by dropping the "@@ " prefix.
Tested on x86_64-linux.
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.
Fix this by using Term::command_no_prompt_prefix.
Tested on x86_64-linux.
With test-case gdb.tui/main.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/main.exp: show main after file
...
The problem is that this command:
...
Term::command "file [standard_output_file $testfile]"
...
tries to match "(gdb) $cmd", but due to the long file name, $cmd is split up
over two lines:
...
16 (gdb) file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/main/ma
17 in
18 Reading symbols from /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.t
19 ui/main/main...
20 (gdb)
...
Fix this by matching "Reading symbols from" instead.
Tested on x86_64-linux.
With test-case gdb.tui/corefile-run.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/corefile-run.exp: load corefile
...
The timeout happens in this command:
...
Term::command "core-file $core"
...
because it tries to match "(gdb) $cmd" but $cmd is split over two lines:
...
16 (gdb) core-file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/co
17 refile-run/corefile-run.core
18 [New LWP 5370]
19 Core was generated by `/data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb
20 .tui/corefile-run/coref'.
21 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
22 #0 main () at tui-layout.c:21
23 (gdb)
...
Fix this by using send_gdb "$cmd\n" and wait_for "Program terminated" instead.
Tested on x86_64-linux.
The semantics of wait_for are non-trivial, and a bit hard to understand
sometimes.
Add some debug prints in wait_for that make it clear:
- what regexps we're trying to match,
- what strings we compare to the regexps, and
- whether there's a match or mismatch.
I've added this ad-hoc a couple of times, and it seems that it's worth having
readily available.
The debug prints are enabled by adding DEBUG_TUI_MATCHING=1 to the
RUNTESTFLAGS:
...
$ make check RUNTESTFLAGS="gdb.tui/empty.exp DEBUG_TUI_MATCHING=1"
...
Tested on x86_64-linux.
In accept_gdb_output we have:
...
timeout {
# Assume a timeout means we somehow missed the
# expected result, and carry on.
return 0
}
...
The timeout is silent, and though in some places the return value is checked,
this is not done consistently, and consequently there are silent timeouts
when running the TUI testsuite (gdb.tui/*.exp and gdb.python/tui*.exp).
Each timeout is 10 seconds, and there are 5 in total in the TUI tests, taking
50 seconds overall:
...
real 1m0.275s
user 0m10.440s
sys 0m1.343s
...
With an entire testsuite run taking about 30 minutes, that is about 2.5% of
the time spent waiting in TUI tests.
Let's make the timeouts visible using a warning, such that they can be fixed.
Tested on x86_64-linux.
When editing gdb.gdb/python-helper.exp, auto-indent is broken in my editor
(emacs).
The problem is that this:
...
if { 1 } {
foo "{" "}"<ENTER>bar
}
...
produces this:
...
if { 1 } {
foo "{" "}"
bar
}
...
Note that this doesn't happen for "{}".
Fix this by using "\{" and "\}".
Tested on x86_64-linux.
On openSUSE Leap 15.4, with gcc 7.5.0, when building gdb with
-O2 -g -flto=auto, I run into:
...
FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info
FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...
Fix the first two FAILs by using $bkptno_numopt_re.
The last FAIL is due to:
...
(outer-gdb) print *type->main_type^M
A syntax error in expression, near `->main_type'.^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...
because:
...
(outer-gdb) print type^M
Attempt to use a type name as an expression^M
...
Fix this by making the test unresolved if "print type" or
"print type->main_type" doesn't succeed.
On openSUSE Tumbleweed, with gcc 13.0.1, when building gdb with
-O2 -g -flto=auto, I run into timeouts due to the breakpoint in c_print_type
not hitting. Fix this by detecting the situation and bailing out.
Tested on x86_64-linux.
While writing a gdb_test_multiple call in a test-case I tried to use -wrap in
combination with -prompt and found out that it doesn't work, because -wrap uses
"$gdb_prompt $" instead of $prompt_regexp.
Fix this by making -wrap use $prompt_regexp.
Tested on x86_64-linux.
I noticed that this observable was never notified, which means we can
probably safely remove it. The notification was removed in:
commit 243a925328
Author: Pedro Alves <palves@redhat.com>
Date: Wed Sep 9 18:23:24 2015 +0100
Replace "struct continuation" mechanism by something more extensible
print_end_stepping_range_reason in turn becomes unused, so remote it as
well.
Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a
When using a compiler defaulting to -std=gnu90, we run into:
...
Running gdb.server/attach-flag.exp ...
gdb compile failed, attach-flag.c: In function 'main':
attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \
in C99 or C11 mode
for (int i = 0; i < NTHREADS; i++)
^~~
attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \
-std=gnu11 to compile your code
...
Fix this by using -std=gnu99.
Tested on x86_64-linux.
When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into:
...
Running gdb/testsuite/gdb.multi/multi-arch.exp ...
gdb compile failed, In file included from /usr/include/features.h:399:0,
from /usr/include/stdio.h:27,
from gdb/testsuite/gdb.multi/hangout.c:18:
/usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \
No such file or directory
# include <gnu/stubs-32.h>
^
compilation terminated.
...
The problem is that the test-case attempts to use gcc -m32 to produce an
executable while that's not available.
Fix this by:
- introduce a new caching proc have_compile_and_link_flag, and
- using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp.
Tested on:
- x86_64-linux (openSUSE Leap 15.4), and
- powerpc64le-linux (CentOS-7).
With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp.
ERROR: invalid command name "lmap"
while executing
"::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \
dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }"
...
Fix this by adding basic lmap support for tcl version < 8.6.
Tested on x86_64-linux.
Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat:
...
set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }]
...
but that's only supported starting tcl 8.6.
Fix this by using "expr" instead:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...
Tested on x86_64-linux.
opcodes/i386-dis.c: In function ‘print_insn’:
opcodes/i386-dis.c:9865:22: error: storing the address of local
variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=]
* i386-dis.c (print_insn): Clear info->private_data before
returning.
The testcase managed to trigger creation of a wild pointer in
coff_slurp_symbol_table. Stop that happening, and fix an unrelated
problem I happened to see in bfd_coff_get_syment.
* coff-bfd.c (bfd_coff_get_syment): Clear fix_value after
converting n_value from a pointer to an index.
* coffcode.h (coff_slurp_symbol_table <C_BSTAT>): Sanity check
symbol value before converting to a pointer.
This makes sure the input element bfd is closed before exiting the
loop copying elements.
* objcopy.c (copy_archive): Rename output_bfd to output_element.
Localise last_element. Close this_element in more error cases.
When running the dap tests on a system with tcl 8.5, we run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp.
ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \
digit, double, false, graph, integer, list, lower, print, punct, space, \
true, upper, wideinteger, wordchar, or xdigit
while executing
"string is entier $num"
(procedure "num" line 16)
invoked from within
...
Fix this by:
- requiring tcl 8.6 in allow_dap_tests, and
- adding the missing require allow_dap_tests in gdb.dap/memory.exp.
Tested on x86_64-linux.
For quite come time print_insn() has been storing the address of a local
variable into info->private_data. Since the compiler can't know that the
field won't be accessed again after print_insn() returns, it may kind of
legitimately diagnose this. And recent enough gcc does as of the
introduction of the fetch_error() return paths (replacing setjmp()-based
error handling).
Utilizing that neither prefix_name() nor i386_dis_printf() actually use
info->private_data, zap the pointer in fetch_error(), after having
retrieved it for local use.
-mfix-looongson3-llsc may add sync instructions not needed on some
asm code with lots of debug info.
PR: 30153
* gas/config/tc-mips.c(fix_loongson3_llsc): clear logistic.
If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output
r6 objects by default.
The triples with vendor `img` should do same.
The examples include:
as xx.s -o xx.o
ld -r -b binary xx.dat -o xx.o
For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
used as the cpu name in triple.
Let's recognize them by `mips*64*(el)`.
For 64bit Ports, like Debian's mips64el and mips64r6el ports,
`gnuabi64` is used as the abi section.
Let's use N64 abi by default for the triple with gnuabi64.
When running the gdb.dlang test-cases, and forcing gdb_find_gdc to be used
rather than dejagnu's copy (mimicing what happens with an older dejagnu
without find_gdc), I run into these debug prints:
...
Tool Root: /data/vries/gdb/leap-15-4/build
CC: gdc
...
Remove these.
Tested on x86_64-linux.
[ Changes in v2:
- rebase on trunk
Changes in v3:
- add test-case ]
We should exclude matches to the ending PC to prevent false matches with the
next function, as prologue_end is located at the end PC.
<fun1>:
0x00: ... <-- start_pc
0x04: ...
0x08: ... <-- breakpoint
0x0c: ret
<fun2>:
0x10: ret <-- end_pc | prologue_end of fun2
Tested on x86_64-linux.
Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1])
Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case)
Approved-by: Kevin Buettner <kevinb@redhat.com>
[1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html
PR symtab/30369
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369
I think that the language_auto enumerator and the auto_language class
can be removed. There isn't really an "auto" language, it's only a
construct of the "set language" command to say "pick the appropriate
language automatically". But "auto" is never the current language. The
`current_language` points to the current effective language, and the
fact that we're in "auto language" mode is noted by the language_mode
global.
- Change set_language to handle the "auto" (and "local", which is a
synonym) early, instead of in the for loop. I think it makes the two
cases (auto vs explicit language) more clearly separated anyway.
- Adjust add_set_language_command to hard-code the "auto" string,
instead of using the "auto" language definition.
- Remove auto_language, rename auto_or_unknown_language to
unknown_language and move the bits of the existing unknown_language
in there.
- Remove the set_language at the end of _initialize_language. I think
it's not needed, because we call set_language in gdb_init, after all
_initialize functions are called. There is some chance that an
_initialize function that runs after _initialize_language implicitly
depends on current_language being set, but my testsuite runs haven't
found anything like that.
- Use language_unknown instead of language_auto when creating a minimal
symbol (minimal_symbol_reader::record_full). I think that this value
is used to indicate that we don't know the symbol of the minimal
symbol (yet), so language_unknown makes sense to me. Update a
condition accordingly in ada-lang.c. symbol_find_demangled_name also
appears to "normalize" this value from "unknown" to "auto", remove
that part and update the condition to just check for
language_unknown.
Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034
Reviewed-By: Tom Tromey <tom@tromey.com>
The `language` global variable is mostly a scratch variable used for the
setting. The source of truth is really current_language and
language_mode (auto vs manual), which are set by the
set_language_command callback.
Switch the setting to use the add_setshow_enum_cmd overload that takes a
value getter and setter.
Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b
Reviewed-By: Tom Tromey <tom@tromey.com>
