Assembler directives such as .float, or .double are handled by generic
code, but on Arm, their output can vary depeding on the type of FPU
begin targetted. When we remove FPA support we don't want to silently
generate different code for processors that previously defaulted to
the FPA, so redirect these directives through a wrapper function that
checks the FPU is enabled; we use the legacy -mno-fpu in the test to
catch this.
Also fix a few tests so that they won't start to fail on targets (eg
arm-wince-pe) where there is no default format for the FPU and we pick
this from the default processor type.
The logic here seems to be overly complex, so simplify it a bit. One
particular problem was that using the legacy -mno-fpu option was not
working properly, as this has all the feature bits set to zero causing
the code to then pick a different FPU as the default. Fix this by
only selecting an FPU as a fallback if the code has not otherwise
selected one: there was only one route by which this could happen.
This patch is really a pre-cursor to the following one where we want
to make no-fpu internally a fall-back position for some legacy
processors where previously we would have dropped back to the FPA.
From armv6 onwards a lot of cores started to come with a physical VFP
implementation; but many still did not and in some cases there are
both variants. For the cores that lacked a physical VFP we would fall
back to FPU_NONE if the platform/ABI did not mandate something else.
To make matters worse, FPU_NONE is internal state used to imply
soft-fpa (ie a mixed-endian double format), so any use of .double in
hand-written assembly is almost certainly generating incorrect output.
That's undesirable, all these cores should really default to a softvfp
model.
FPU_ARCH_VFP has always meant VFP floating-point format (natural FP
word order) but without any VFP instructions. But the name
FPU_ARCH_VFP is potentially confusing. This patch just changes the
name to make the meaning clearer.
1. Combined testcases into one if they use same extention name.
2. Likewise for the fail testcases.
3. Renamed with x-cv prefix, just like what other vendors did.
gas/
* testsuite/gas/riscv/cv-alu-*: Combined and renamed to
x-cv-alu. Likewise for fail testcases, to x-cv-alu-fail*.
* testsuite/gas/riscv/cv-bi-*: Likewise, but renamed to
x-cv-bi and x-cv-bi-fail.
* testsuite/gas/riscv/cv-elw-*: Likewise, but renamed to
x-cv-elw and x-cv-elw-fail.
* testsuite/gas/riscv/cv-mac-*: Likewise, but renamed to
x-cv-mac and x-cv-mac-fail.
* testsuite/gas/riscv/cv-mem-*: Likewise, but renamed to
x-cv-mem and x-cv-mem-fail.
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
Contributors:
Mary Bennett <mary.bennett682@gmail.com>
Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Pietra Ferreira <pietra.ferreira@embecosm.com>
Charlie Keaney
Jessica Mills
Craig Blackmore <craig.blackmore@embecosm.com>
Simon Cook <simon.cook@embecosm.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
Helene Chelin <helene.chelin@embecosm.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvmem`
instruction class.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* doc/c-riscv.texi: Note XCVmem as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/cv-mem-fail-march.d: New test.
* testsuite/gas/riscv/cv-mem-fail-march.l: New test.
* testsuite/gas/riscv/cv-mem-fail-march.s: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-01.d: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-01.l: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-01.s: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-02.d: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-02.l: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-02.s: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-03.d: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-03.l: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-03.s: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-04.d: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-04.l: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-04.s: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-05.d: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-05.l: New test.
* testsuite/gas/riscv/cv-mem-fail-operand-05.s: New test.
* testsuite/gas/riscv/cv-mem-lbpost.d: New test.
* testsuite/gas/riscv/cv-mem-lbpost.s: New test.
* testsuite/gas/riscv/cv-mem-lbrr.d: New test.
* testsuite/gas/riscv/cv-mem-lbrr.s: New test.
* testsuite/gas/riscv/cv-mem-lbrrpost.d: New test.
* testsuite/gas/riscv/cv-mem-lbrrpost.s: New test.
* testsuite/gas/riscv/cv-mem-lbupost.d: New test.
* testsuite/gas/riscv/cv-mem-lbupost.s: New test.
* testsuite/gas/riscv/cv-mem-lburr.d: New test.
* testsuite/gas/riscv/cv-mem-lburr.s: New test.
* testsuite/gas/riscv/cv-mem-lburrpost.d: New test.
* testsuite/gas/riscv/cv-mem-lburrpost.s: New test.
* testsuite/gas/riscv/cv-mem-lhpost.d: New test.
* testsuite/gas/riscv/cv-mem-lhpost.s: New test.
* testsuite/gas/riscv/cv-mem-lhrr.d: New test.
* testsuite/gas/riscv/cv-mem-lhrr.s: New test.
* testsuite/gas/riscv/cv-mem-lhrrpost.d: New test.
* testsuite/gas/riscv/cv-mem-lhrrpost.s: New test.
* testsuite/gas/riscv/cv-mem-lhupost.d: New test.
* testsuite/gas/riscv/cv-mem-lhupost.s: New test.
* testsuite/gas/riscv/cv-mem-lhurr.d: New test.
* testsuite/gas/riscv/cv-mem-lhurr.s: New test.
* testsuite/gas/riscv/cv-mem-lhurrpost.d: New test.
* testsuite/gas/riscv/cv-mem-lhurrpost.s: New test.
* testsuite/gas/riscv/cv-mem-lwpost.d: New test.
* testsuite/gas/riscv/cv-mem-lwpost.s: New test.
* testsuite/gas/riscv/cv-mem-lwrr.d: New test.
* testsuite/gas/riscv/cv-mem-lwrr.s: New test.
* testsuite/gas/riscv/cv-mem-lwrrpost.d: New test.
* testsuite/gas/riscv/cv-mem-lwrrpost.s: New test.
* testsuite/gas/riscv/cv-mem-sbpost.d: New test.
* testsuite/gas/riscv/cv-mem-sbpost.s: New test.
* testsuite/gas/riscv/cv-mem-sbrr.d: New test.
* testsuite/gas/riscv/cv-mem-sbrr.s: New test.
* testsuite/gas/riscv/cv-mem-sbrrpost.d: New test.
* testsuite/gas/riscv/cv-mem-sbrrpost.s: New test.
* testsuite/gas/riscv/cv-mem-shpost.d: New test.
* testsuite/gas/riscv/cv-mem-shpost.s: New test.
* testsuite/gas/riscv/cv-mem-shrr.d: New test.
* testsuite/gas/riscv/cv-mem-shrr.s: New test.
* testsuite/gas/riscv/cv-mem-shrrpost.d: New test.
* testsuite/gas/riscv/cv-mem-shrrpost.s: New test.
* testsuite/gas/riscv/cv-mem-swpost.d: New test.
* testsuite/gas/riscv/cv-mem-swpost.s: New test.
* testsuite/gas/riscv/cv-mem-swrr.d: New test.
* testsuite/gas/riscv/cv-mem-swrr.s: New test.
* testsuite/gas/riscv/cv-mem-swrrpost.d: New test.
* testsuite/gas/riscv/cv-mem-swrrpost.s: New test.
* testsuite/gas/riscv/march-help.l: Add xcvmem string.
include/ChangeLog:
* opcode/riscv-opc.h: Add corresponding MATCH and MASK macros
for XCVmem.
* opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros
for XCVmem.
(enum riscv_insn_class): Add the XCVmem instruction class.
opcodes/ChangeLog:
* riscv-opc.c: Add XCVmem instructions.
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
Contributors:
Mary Bennett <mary.bennett682@gmail.com>
Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Pietra Ferreira <pietra.ferreira@embecosm.com>
Charlie Keaney
Jessica Mills
Craig Blackmore <craig.blackmore@embecosm.com>
Simon Cook <simon.cook@embecosm.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
Helene Chelin <helene.chelin@embecosm.com>
Nazareno Bruschi <nazareno.bruschi@embecosm.com>
Lin Sinan
include/ChangeLog:
* opcode/riscv-opc.h: Add corresponding MATCH and MASK
macros for XCVbi.
* opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros
for XCVbi.
(enum riscv_insn_class): Add the XCVbi instruction class.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Add the necessary
operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Note XCVbi as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/cv-bi-beqimm.d: New test.
* testsuite/gas/riscv/cv-bi-beqimm.s: New test.
* testsuite/gas/riscv/cv-bi-bneimm.d: New test.
* testsuite/gas/riscv/cv-bi-bneimm.s: New test.
* testsuite/gas/riscv/cv-bi-fail-march.d: New test.
* testsuite/gas/riscv/cv-bi-fail-march.l: New test.
* testsuite/gas/riscv/cv-bi-fail-march.s: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-01.d: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-01.l: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-01.s: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-02.d: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-02.l: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-02.s: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-03.d: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-03.l: New test.
* testsuite/gas/riscv/cv-bi-fail-operand-03.s: New test.
* testsuite/gas/riscv/march-help.l: Add xcvbi string.
include/ChangeLog:
* opcode/riscv-opc.h: Add corresponding MATCH and MASK
macros for XCVbi.
* opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros
for XCVbi.
(enum riscv_insn_class): Add the XCVbi instruction class.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Add disassembly for new operand.
* riscv-opc.c: Add XCVbi instructions.
I noticed that the value returned by rust_llvm_version had a trailing
carriage return. I don't think this is causing any problems right
now, but looking at the code I don't think this was the desired
behaviour.
The current code runs 'rustc --version --verbose', splits the output
at each '\n' and then loops over every line looking for the line that
contains the LLVM version.
There are two problems here. First, at the end of each captured line
we have '\r\n', so when we split the lines on '\n', each of the lines
will still end with a '\r' character.
Second, though we loop over the lines, when we try to compare the line
contents we actually compare the unsplit full output. Luckily this
still finds the match, but this renders the loop over lines redundant.
This commit makes two fixes:
1. I use regsub to convert all '\r\n' sequences to '\n'; now when we
split on '\n' the lines will not end in '\r'.
2. Within the loop over lines block I now check the line contents
rather than the unsplit full output; now we capture a value
without a trailing '\r'.
There's only one test (gdb.rust/simple.exp) that uses
rust_llvm_version, and it doesn't care if there's a trailing '\r' or
not, so this change should make no difference there.
Approved-By: Tom Tromey <tom@tromey.com>
I spotted a few more places where we could apply filename styling in
remote.c and target.c. Other than the styling, there should be no
user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
A co-worker requested that the DAP code emit a scope for global
variables. It's not really practical to do this for all globals, but
it seemed reasonable to do this for globals coming from the frame's
compilation unit. For Ada in particular, this is convenient as it
exposes package-scoped variables.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
In subsequent patches, it's handy if gdb.Block is hashable, so it can
be stored in a set or a dictionary. However, doing this in a
straightforward way is not really possible, because a block isn't
truly immutable -- it can be invalidated. And, while this isn't a
real problem for my use case (in DAP the maps are only used during a
single stop), it seemed error-prone.
This patch instead takes the approach of using the gdb.Block's own
object identity to allow hashing. This seems fine because the
contents don't affect the hashing. In order for this to work, though,
the blocks have to be memoized -- two requests for the same block must
return the same object.
This also allows (actually, requires) the simplification of the
rich-compare method for blocks.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
I noticed a FIXME comment in the DAP code about adding a "source"
field to a scope. This is easy to implement; I don't know why I
didn't do this originally.
The bcache uses memcpy to make copies of the data passed to it. In
C++, this is only safe for trivially-copyable types.
This patch changes bcache to require this property, and slightly
changes the API to make it easier to use when copying a single object.
It also makes the new 'insert' template methods return the correct
type.
This patch changes some spots in psymtab.[ch] to use 'const'. This is
just preparation for a subsequent patch. Note that psymbols are
conceptually const, and since they were changed to be
objfile-indepdendent, they are truly never modified -- which is what
makes this patch reasonably short.
Add tests for looking up debug information within the sysroot via both
build-id and gnu_debuglink.
I wanted to ensure that the gnu_debuglink test couldn't make use of
build-ids, so I added the 'no-build-id' flag to gdb_compile.
As these tests rely on setting the sysroot, if I'm running a
dynamically linked executable, GDB will try to find all shared
libraries within the sysroot. This would mean I'd have to figure out
and copy all shared libraries the executable uses, certainly possible,
but a bit of a pain.
So instead, I've just compiled the test executable as a static binary.
Now there are no shared library dependencies.
I can now split the debug information out from the test binary, and
place it within the sysroot. When GDB is started and the executable
loaded, we can check that GDB is finding the debug information within
the sysroot.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
Approved-By: Tom de Vries <tdevries@suse.de>
While writing a test I realised that the default behaviour of
gdb_gnu_strip_debug doesn't match its comment.
The comment says that the function takes a FILENAME, and splits the
file into FILENAME.stripped and FILENAME.debug, leaving FILENAME
unchanged. The comment says that a .gnu_debuglink will be added to
FILENAME.stripped.
However, this is not true, FILENAME.stripped is created, with no debug
information. FILENAME.debug is created containing the debug
information.
But, when adding the .gnu_debuglink we take FILENAME.stripped as the
input, and then overwrite FILENAME with the output. As a result,
FILENAME.stripped does not include a .gnu_debuglink, while FILENAME
contains the .gnu_debuglink and no debug information!
The users of gdb_gnu_strip_debug can be split into two groups, those
who are using the .gnu_debuglink, these tests are all written assuming
that FILENAME is updated.
Then there are some tests that only rely on gdb_gnu_strip_debug's
ability to split out the debug information, these tests are then going
to do a lookup based on the build-id, these tests don't require the
.gnu_debuglink. These tests use the FILENAME.stripped output file.
This all seems too confused to me.
As most uses of gdb_gnu_strip_debug assume that FILENAME is updated, I
propose that we just make that the actual, advertised behaviour of
this proc.
So now, gdb_gnu_strip_debug will take FILENAME, and will split the
debug information out into FILENAME.debug. The debug information will
then be stripped from FILENAME, and by default a .gnu_debuglink will
be added to FILENAME pointing to FILENAME.debug.
I've updated the two tests that actually relied on FILENAME.stripped
to instead just use FILENAME.
One of the tests was doing a build-id based lookup, but was still
allowing the .gnu_debuglink to be added to FILENAME, I've updated this
test to pass the no-debuglink flag to gdb_gnu_strip_debug, which stops
the .gnu_debuglink from being added.
All of the tests that call gdb_gnu_strip_debug still pass for me.
Acked-By: Tom de Vries <tdevries@suse.de>
When building in a fresh directory we'll see some output like this:
/bin/sh ../../src/gdb/../mkinstalldirs arch/.deps
mkdir -p -- arch/.deps
/bin/sh ../../src/gdb/../mkinstalldirs cli/.deps
mkdir -p -- cli/.deps
/bin/sh ../../src/gdb/../mkinstalldirs dwarf2/.deps
mkdir -p -- dwarf2/.deps
... etc ...
this commit uses silent-rules.mk to silence this output, now we'll
see:
GEN arch/.deps
GEN cli/.deps
GEN dwarf2/.deps
... etc ...
The recipe that currently generates these directories uses
mkinstalldirs, as I mention in commit 032e5e0c0c, mkinstalldirs
is deprecated and 'install-sh -d' should be used instead. This
silences the 'mkdir -p -- ...' part of the output.
There should be no change in what is actually built after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
R_LARCH_ALIGN (psABI v2.30) requires a symbol index. The symbol is only
created at the first time to handle alignment directive. This means that
all other sections may use this symbol. If the section of this symbol is
discarded, there may be problems. Search it in its own section.
Remove elf_backend_data.is_rela_normal() function added at commit daeda14191.
Co-authored-by: Jinyang He <hejinyang@loongson.cn>
Reported-by: WANG Xuerui <git@xen0n.name>
Link: https://lore.kernel.org/loongarch/2abbb633-a10e-71cc-a5e1-4d9e39074066@loongson.cn/T/#t
A couple of the tests in the testsuite were at some point in the past
committed with DOS-style CRLF line endings. This potentially causes
email problems if the tests are touched in the middle of a large patch
series so convert them to standard Un*x line endings.
This removes a call to can_box from
tui_source_window_base::show_source_content. can_box will always
return true here.
Approved-By: Andrew Burgess <aburgess@redhat.com>
I noticed one spot where deprecate_cmd is called with a second
argument that is not a command name. This patch fixes the problem.
Regression tested on x86-64 Fedora 38.
If you try to use the overloaded subscript operator of a class
in python, it fails like this:
(gdb) py print(gdb.parse_and_eval('b')[5])
Traceback (most recent call last):
File "<string>", line 1, in <module>
gdb.error: Cannot subscript requested type.
Error while executing Python code.
This simply checks if such an operator exists, and calls it
instead, making this possible:
(gdb) py print(gdb.parse_and_eval('b')[5])
102 'f'
Approved-By: Tom Tromey <tom@tromey.com>
As mentioned in PR13326, currently when you try to call a
convenience function with python, you get this error:
(gdb) py print(gdb.convenience_variable("_isvoid")(3))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD).
Error while executing Python code.
So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as
well, making this possible:
(gdb) py print(gdb.convenience_variable("_isvoid")(3))
0
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326
Approved-By: Tom Tromey <tom@tromey.com>
Use parallel compression to create the xz archive.
On my machine (using 4 cores) this reduces the time to create
binutils-2.42.50.tar.xz from 1 minute 40 seconds to 56 seconds.
xz has supported -T0 since version 5.2.0 (released 2014-12-21).
When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run
into:
...
tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable
^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout)
...
The test-case does "Term::resize 24 80 0" while having the settings of an
earlier "Term::resize 40 90", so both dimensions change.
When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc:
- calls stty to change one dimension,
- waits for the message (enabled by "maint set tui-resize-message on")
confirming the resize has happened,
- calls stty to change the other dimension, and again
- waits for the message confirming the resize has happened.
Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the
message is not printed, so stty is called twice, and afterwards we check for
the results of the two resizes, which is the test that is failing.
The problem is that not waiting for a response after each stty call opens up
the possibility of the responses being merged.
Fix this by calling Term::resize twice, changing one dimension at a time, and
waiting for a single prompt redisplay after each one.
Tested on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
PR testsuite/31822
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822
Printing the value of 'errno' from GDB is sometimes problematic. The
situation has improved in recent years, though there are still
scenarios for which "print errno" doesn't work.
The test, gdb.base/errno.exp, introduced by this commit, tests whether
or not GDB can print errno using a binary compiled in the following
different ways:
- default: no switches aside from -g (and whatever else is added by the
testing framework)
- macros: macro info is included in the debuginfo; this is enabled by
using -g3 when using gcc or clang
- static: statically linked binary
- static-macros: statically linked binary w/ macro definitions included
in debuginfo
- pthreads: libpthread linked binary
- pthreads-macros: libpthread linked binary w/ macro definitions included
in debuginfo
- pthreads-static: Statically linked against libpthread
- pthreads-static-macros: Statically linked against libpthread w/ macro
definitions
For each of these, the test also creates a corefile, then loads the
corefile and attempts to print errno again.
Additionally, the test checks that a "masking" errno declared as a
local variable will print correctly.
On Linux, if the machine is missing glibc debuginfo (or you have
debuginfod disabled), it's likely you'll see:
(gdb) print errno
'errno' has unknown type; cast it to its declared type
But if you add a cast, the value of errno is often available:
(gdb) print (int) errno
$1 = 42
The test detects this situation along with several others and does
'setup_xfail' for tests that will almost certainly fail. It could be
argued that some of these ought to be KFAILs due to deficiencies in
GDB, but I'm not entirely certain which, if any, are fixable yet.
On Fedora 39, without glibc debuginfo, there are no failures, but
I do see the following XFAILS:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
On Fedora 39, with glibc debug info, but without libc.a (for static
linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED
tests.
So, even when testing in less than ideal conditions, either due to lack
of glibc debuginfo or lack of a libc to link against to make a static
binary, there are no failures.
With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40,
Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs:
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
On FreeBSD 13.1, the total number of XFAILs are fewer, and could be
even better still if it had debug info for glibc:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
Starting with glibc-2.34, most of the pthreads library has been
incorporated into libc, so finding thread-local variables using
libthread_db is possible for several scenarios in which it previously
wasn't. But, prior to this, accessing errno for the default scenario
was a problem. This is borne out by running this new test on Fedora
34, which uses glibc-2.33:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
In the v3 version of this test, Tom de Vries tested on openSUSE Leap
15.5 and found a number of cases which showed a FAIL instead of an
XFAIL. The v4 version of this test fixed those problems. On Leap
15.5, which uses glibc-2.31, with glibc debug info, I now see:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
On Leap 15.5, with glibc debuginfo missing, the results are a little
worse:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
The v5 version of this test fixed failures when testing with
check-read1. (Thanks to Linaro CI for finding these.) I revised the
regular expressions being used so that the failures were eliminated,
but the results mentioned above have not changed.
The v6 version of this test fixes some nits pointed out by both Tom
de Vries and Pedro Alves. One of Pedro's suggestions was to rename the
test from check-errno.exp to errno.exp, so in v5, the name has
changed. Tom also noticed that there were failures when using
--target_board=native-extended-gdbserver. For v6, I've tested on 10
different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o
static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o
glibc debuginfo, and Fedora 34) using "make check" and "make check-read1"
using target boards "unix", "native-extended-gdbserver", and
"native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for
a total of 12 distinct test runs on each machine. I've also tested the
native-only cases on FreeBSD. (Attempting to test against gdbserver
on FreeBSD resulted in hangs while running the test suite.)
The v7 version of this test simplifies the REs used in the uses of
gdb_test_multiple by adding -wrap and removing parts of the REs which
match the GDB prompt. In cases where there was a leading '.*', those
were removed too. Thanks to Pedro for explaining how to use -wrap.
So, bottom line, this test does not introduce any new failures on the
platforms on which I've tested, but the XFAILs are certainly unfortunate.
Some aren't fixable - e.g. when attempting to make a function call while
debugging a core file - but I think that some of them are. I'm using
this new test case as a starting point for investigating problems with
printing errno.
Co-Authored-By: Jan Kratochvil
Approved-By: Tom de Vries <tdevries@suse.de>
Some dejagnu files use regexes rather than specific encodings. This
change replaces them with the explicit encodings we expect.
Tested against aarch64-unknown-linux-gnu and aarch64-none-elf.
Making two cleanups that came out of the comments from my previous
patches:
1. Fixing `c-aarch64.texi` file so that the AArch64 architecture
extensions are ordered alphabetically.
2. Fixing faminmax test cases so that they follow the existing test
conventions.
dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader,
so this field can be moved to mapped_gdb_index instead. Then,
cooked_index_functions::find_per_cu can be removed in favor of a
method on the index object.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The logic to decide if an input relocation for a symbol becomes a
particular kind of output relocation is one of the hard to maintain
parts of the bfd ld backend, since it is partially repeated across
elfNN_aarch64_check_relocs (where dynamic relocations are counted per
symbol and input section),
elfNN_aarch64_late_size_sections (where relocation sections are sized
and GOT offsets assigned),
elfNN_aarch64_relocate_section (where most relocations are applied and
output to a relocation section),
elfNN_aarch64_finish_dynamic_symbol (where some of the GOT
relocations are applied and output).
The DT_RELR support adds another layer to this complexity: after the
output relocation sections are sized, so all dynamic relocations are
accounted (in elfNN_aarch64_late_size_sections), we scan the symbols
and input relocations again to decide which ones become relative
relocations that can be packed. The sizes of the relocation sections
are updated accordingly. This logic must be consistent with the code
that applies the relocs later so each relative relocation is emitted
exactly once: either in .rela.* or packed in .relr.dyn.
Sizing of .relr.dyn is done via elfNN_aarch64_size_relative_relocs that
may be called repeatedly whenever the layout changes since an address
change can affect the size of the packed format. Then the final content
is emitted in elfNN_aarch64_finish_relative_relocs, that is called
after the layout is final and before relocations are applied and
emitted. These hooks are only called if DT_RELR is enabled.
We only pack relative relocs that are known to be aligned in the output
during .relr.dyn sizing, the potentially unaligned relative relocs are
emitted normally (in .rela.*, not packed), because the format requires
aligned addresses.
These run after template matching. Therefore it is quite pointless for
them to check all operands, when operand sizes matching across operands
is already known. Exit the loops early in such cases.
In check_byte_reg() also drop a long-stale part of a comment.
These structs are not referenced anywhere anymore and seemed to have been
missed at some point when their usage was removed.
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
Approved-By: Tom Tromey <tom@tromey.com>
org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the
docs yet. Fix that.
In addition the documentation describes xmm registers with an `h`
(e.g. xmm16h). I am assuming that we follow the register xml files here,
which don't have the h suffix. So this removes that as well.
Approved-By: Eli Zaretskii <eliz@gnu.org>
