FreeBSD's kernel has recently added two new ELF auxiliary vector
entries to describe the location of the user stack for the initial
thread in a process.
This change displays the proper name and description of these entries
in 'info auxv'.
This patch adds support for the Zawrs ISA extension
("wrs.nto" and "wrs.sto" instructions).
The specification can be found here:
https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
The test gdb.tui/tui-missing-src.exp fails on my CI machine, and I
concluded that it is caused by the long source directory name:
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb
The long name causes some particular redrawing that doesn't happen for
shorter directories, and causes a Term::command call to return too
early.
This can be reproduced by cloning the binutils-gdb repo in a directory
with a name similar to the one shown above.
$ pwd
/home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/build/gdb
$ make check-read1 TESTS="gdb.tui/tui-missing-src.exp"
FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
FAIL: gdb.tui/tui-missing-src.exp: f2.c must be displayed in source window
FAIL: gdb.tui/tui-missing-src.exp: check source box is empty after return
FAIL: gdb.tui/tui-missing-src.exp: Back in main
Note that using "make check" instead of "make check-read1" only shows
the last 2 failures for me.
When running gdb.tui/tui-missing-src.exp in a directory with a shorter
name, the terminal looks like this by the time the "checking if inside
f2" test runs:
Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 23):
0 +-...ld/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-missing-src/f2.c-+
1 | 1 |
2 | 2 int |
3 | 3 f2 (int x) |
4 | 4 { |
5 | > 5 x <<= 1; |
6 | 6 return x+5; |
7 | 7 } |
8 | 8 |
9 | 9 |
10 | 10 |
11 | 11 |
12 | 12 |
13 | 13 |
14 +------------------------------------------------------------------------------+
15 multi-thre Thread 0x7ffff7cc07 In: f2 L5 PC: 0x555555555143
16 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
17 missing-src/main.c:6
18 (gdb) next
19 (gdb) step
20 f2 (x=4)
21 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
22 missing-src/f2.c:5
23 (gdb)
PASS: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
When running the `Term::command "step"` just before, GDB writes the
"step", which makes the `wait_for` proc go in the "looking for the
prompt" mode, to know when the command's execution is complete. As some
new output appears, lines that must disappear are deleted using the
"Delete Line" operation [1] and some new ones are drawn. The source
window gets redrawn with the contents of the f2.c file. Then, GDB
writes the prompt (at line 23 above), which satisfies `wait_for`, which
then returns. The state of the terminal is therefore correct for the
"check if inside f2" and "f2.c must be displayed in the source window"
tests.
In the non-working case, the terminal looks like this by the time the
"check if inside f2" test runs:
Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 17):
0 +------------------------------------------------------------------------------+
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | [ No Source Available ] |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 +------------------------------------------------------------------------------+
15 multi-thre Thread 0x7ffff7cc1b In: main L7 PC: 0x555555555128
16 sing-src/main.c:6
17 (gdb) ary breakpoint 1, main ()
18 at /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd6
19 4/target_board/unix/src/binutils-gdb/build/gdb/testsuite/outputs/gdb.tui/tui-mis
20 sing-src/main.c:6
21 (gdb) next
22 (gdb) step
23
FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
What happened is: GDB wrote the "step" command, which make the
`wait_for` proc go in its "looking for the prompt" mode. However,
curses decided to redraw whatever scrolled up to line 17 using some
standard character insertion operations:
+++ Cursor Down (1), cursor: (16, 0) -> (17, 0)
+++ Inserting string '('
+++ Inserted char '(', cursor: (17, 0) -> (17, 1)
+++ Inserted string '(', cursor: (17, 0) -> (17, 1)
+++ Inserting string 'g'
+++ Inserted char 'g', cursor: (17, 1) -> (17, 2)
+++ Inserted string 'g', cursor: (17, 1) -> (17, 2)
+++ Inserting string 'd'
+++ Inserted char 'd', cursor: (17, 2) -> (17, 3)
+++ Inserted string 'd', cursor: (17, 2) -> (17, 3)
+++ Inserting string 'b'
+++ Inserted char 'b', cursor: (17, 3) -> (17, 4)
+++ Inserted string 'b', cursor: (17, 3) -> (17, 4)
+++ Inserting string ')'
+++ Inserted char ')', cursor: (17, 4) -> (17, 5)
+++ Inserted string ')', cursor: (17, 4) -> (17, 5)
+++ Inserting string ' '
+++ Inserted char ' ', cursor: (17, 5) -> (17, 6)
+++ Inserted string ' ', cursor: (17, 5) -> (17, 6)
And that causes `wait_for` to think the "step" command is complete.
This is wrong, as the prompt at line 17 isn't the prompt drawn after the
completion of the "step" command. The subsequent tests now run with a
partially updated screen (what is shown above) and obviously fail.
The ideal way to fix this would be for `wait_for` to be smarter, to
avoid it confusing the different prompts drawn.
However, I would also like to reduce the variations in TUI test results
due to the directories (source and build) in which tests are ran. TUI
tests are more prone to differences in test results due to variations in
directory names than other tests, as it makes curses take different
redrawing decisions. So in this patch, I propose to make TUI tests use
"set filename-display basename", which makes GDB omit directory names
when it prints file names. This way, regardless of where you run the
tests, you should get the same results (all other things being equal).
Doing this happens to fix my failures and makes my CI happy (which in
turns makes me happy). To be clear, I understand that this does not fix
the root issue of `proc wait_for` being confused. However, it makes TUI
test runs be more similar for everyone, such that there's less chance of
TUI tests randomly failing for somebody. If some other change triggers
the `wait_for` problem again in the future, hopefully everybody will see
the problem and we can work on getting it fixed more easily than if just
one unlucky person sees the problem.
Note that there are other reasons why TUI tests could vary, like
different curses library versions taking different re-drawing decisions.
However, I think my change is a good step towards more stable test
results.
[1] https://vt100.net/docs/vt510-rm/DL.html
Change-Id: Ib18da83317e7b78a46f77892af0d2e39bd261bf5
Every format that might appear inside a generic archive needs to call
_bfd_generic_close_and_cleanup, so that the archive element lookup
htab can be tidied on closing an element. Otherwise you get stale
entries in the htab pointing at freed and perhaps reused memory,
resulting in segfaults when the archive is closed.
Calling _bfd_generic_close_and_cleanup on close means tdata needs to
be set up too, since pdb claims to be of format bfd_archive.
* pdb.c (pdb_close_and_cleanup): Define as
_bfd_generic_close_and_cleanup.
(pdb_archive_p): Set up tdata for bfd_archive format.
It doesn't make sense to try to compress a section without contents
since those sections take no space on disk. Compression can only
increase the disk image size.
* coffgen.c (make_a_section_from_file): Exclude !SEC_HAS_CONTENTS
sections from compression and decompression.
* elf.c (_bfd_elf_make_section_from_shdr): Likewise.
GDB's testsuite can override dejagnu's default_target_compile if the
system provided dejagnu installation does not provide support to compile
languages GDB needs.
Recent version of dejagnu (1.6.3, installed on RHEL-9) includes ba60272
"Establish a default C compiler by evaluating [find_gcc] if no other
compiler is given."[1]. This commit removed calls such as
`set_board_info compiler "[find_gcc]"` from the various baseboards
and has default_target_compile call `find_gcc` itself to find a compiler
if none was specified by the board description.
On systems with dejagnu-1.6.3, if GDB's overrides is needed to support
languages still unknown to dejagnu, we end up in the following
situation:
- The system board files do not set the C compiler anymore,
- GDB's replacement for default_target_compile assumes that the
compiler should have been set up by the board file.
In this situation, no one sets the C compiler for the board and as a
result many test are not compiled and not executed:
[...]
Running .../gdb/testsuite/gdb.base/bt-on-error-and-warning.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
Running .../gdb/testsuite/gdb.base/dprintf-non-stop.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
Running .../gdb/testsuite/gdb.base/structs3.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
[...]
We are observing this error with ROCgdb[2], a downstream port of GDB
supporting AMD GPUs. This port needs to use GDB's override of
default_target_compile to compile HIP programs since dejagnu does not
provide support for this language yet.
This patch changes gdb_default_target_compile_1 in a similar way
default_target_compile has been updated so both implementations remain
compatible. Even if this is not strictly required by GDB just yet,
I believe keeping both implementations in sync desirable.
Using board files provided with dejagnu <=1.6.2 is still supported: if
the compiler is set by the board file, gdb_default_target_compile_1 uses
it and does not need `find_gcc`.
Patch tested on x86_64 RHEL-9 and ubuntu-20.04 on top of GDB and ROCgdb.
[1] http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=ba60272a5ac6f6a7012acca03f596a6ed003f044
[2] https://github.com/ROCm-Developer-Tools/ROCgdb
Change-Id: Ibff52684d9cab8243a7c6748ecbd29f50c37e669
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the XTheadMemPair extension, a collection of T-Head specific
two-GP-register memory operations.
The 'th' prefix and the "XTheadMemPair" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
This patch introduces support for arbitrary literal instruction
arguments, that are not encoded in the opcode.
A typical use case for this feature would be an instruction that
applies an implicit shift by a constant value on an immediate
(that is a real operand). With this patch it is possible to make
this shift visible in the dissasembly and support such artificial
parameter as part of the asssembly code.
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the XTheadMemIdx extension, a collection of T-Head specific
GPR memory access instructions.
The 'th' prefix and the "XTheadMemIdx" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).
In total XTheadCmo introduces the following 44 instructions
(BU,HU,WU only for loads (zero-extend instead of sign-extend)):
* {L,S}{D,W,WU,H,HU,B,BU}{IA,IB} rd, rs1, imm5, imm2
* {L,S}R{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2
* {L,S}UR{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the XTheadFMemIdx extension, a collection of
T-Head-specific floating-point memory access instructions.
The 'th' prefix and the "XTheadFMemIdx" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the XTheadMac extension, a collection of
T-Head-specific multiply-accumulate instructions.
The 'th' prefix and the "XTheadMac" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the XTheadCondMov extension, a collection of
T-Head-specific conditional move instructions.
The 'th' prefix and the "XTheadCondMov" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the XThead{Ba,Bb,Bs} extensions, a collection of
T-Head-specific bitmanipulation instructions.
The 'th' prefix and the "XThead{Ba,Bb,Bs}" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
This patch introduces support for arbitrary signed or unsigned immediate
encoding formats. The formats have the form "XsN@S" and "XuN@S" with N
being the number of bits and S the LSB position.
For example an immediate field of 5 bytes that encodes a signed value
and is stored in the bits 24-20 of the instruction word can use the
format specifier "Xs5@20".
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the XTheadSync extension, a collection of
T-Head-specific multi-processor synchronization instructions.
The 'th' prefix and the "XTheadSync" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the XTheadCmo extension, a collection of T-Head specific
cache management operations.
The 'th' prefix and the "XTheadCmo" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).
In total XTheadCmo introduces the following 21 instructions:
* DCACHE.{C,CI,I}ALL
* DCACHE.{C,CI,I}{PA,VA,SW} rs1
* DCACHE.C{PAL1,VAL1} rs1
* ICACHE.I{ALL,ALLS}
* ICACHE.I{PA,VA} rs1
* L2CACHE.{C,CI,I}ALL
Contrary to Zicbom, the XTheadCmo instructions don't have a constant
displacement, therefore we have a different syntax for the arguments.
To clarify this is intended behaviour, there is a set of negative test
for Zicbom-style arguments in x-thead-cmo-fail.s.
[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
v2:
- Add missing DECLARE_INSN() list
- Fix ordering
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
This patch introduces changes that allow the integration of vendor ISA
extensions:
* Define a list of vendor extensions (riscv_supported_vendor_x_ext)
where vendor extensions can be added
* Introduce a section with a table in the documentation where vendor
extensions can be added
To add a vendor extension that consists of instructions only,
the following things need to be done:
* Add the extension to the riscv_supported_vendor_x_ext list
* Add lookup entry in riscv_multi_subset_supports
* Documenting the extension in c-riscv.texti
* Add test cases for all instructions
* Add MATCH*/MASK* constants and DECLARE_INSN() for all instructions
* Add new instruction class to enum riscv_insn_class
* Define the instructions in riscv_opcodes
* Additional changes if necessary (depending on the instructions)
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Add all_comp_units/all_type_units views on all_units.
Having the views allows us to:
- easily get the number of CUs or TUs in all_units, and
- easily access the nth CU or TU.
This minimizes the use of tu_stats.nr_tus.
Tested on x86_64-linux.
"-Wunused-but-set-variable" warning option can be helpful to track variables
that are written but not read thereafter. But it can be harmful if some of
the code is auto-generated and we have no ways to deal with it.
The particular example is Bison-generated code.
The new DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro can be helpful on
such cases. A typical use of this macro is to place this macro before the
end of user prologues on Bison (.y) files.
include/ChangeLog:
* diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE): New.
User-defined warnings (on Clang, "-Wuser-defined-warnings") can be harmful
if we have specified "-Werror" and we have no control to disable the warning
ourself. The particular example is Gnulib.
Gnulib generates a warning if the system version of certain functions
are used (to redirect the developer to use Gnulib version). However,
it can be harmful if we cannot easily replace them (e.g. the target is in
the standard C++ library).
The new DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS macro can be helpful on such
cases. A typical use of this macro is to place this macro before including
certain system headers.
include/ChangeLog:
* diagnostics.h (DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS): New.
I noticed that, from Python, I could register a new TUI window that
had whitespace in its name, like this:
gdb.register_window_type('my window', MyWindowType)
however, it is not possible to then use this window in a new TUI
layout, e.g.:
(gdb) tui new-layout foo my window 1 cmd 1
Unknown window "my"
(gdb) tui new-layout foo "my window" 1 cmd 1
Unknown window ""my"
(gdb) tui new-layout foo my\ window 1 cmd 1
Unknown window "my\"
GDB clearly uses the whitespace to split the incoming command line.
I could fix this by trying to add a mechanism by which we can use
whitespace within a window name, but it seems like an easier solution
if we just forbid whitespace within a window name. Not only is this
easier, but I think this is probably the better solution, identifier
names with spaces in would mean we'd need to audit all the places a
window name could be printed and ensure that the use of a space didn't
make the output ambiguous.
So, having decided to disallow whitespace, I then thought about other
special characters. We currently accept anything as a window name,
and I wondered if this was a good idea.
My concerns were about how special characters used in a window name
might cause confusion, for example, we allow '$' in window names,
which is maybe fine now, but what if one day we wanted to allow
variable expansion when creating new layouts? Or what about starting
a window name with '-'? We already support a '-horizontal' option,
what if we want to add more in the future? Or use of the special
character '{' which has special meaning within a new layout?
In the end I figured it might make sense to place some restrictive
rules in place, and then relax the rules later if/when users complain,
we can consider each relaxation as its requested.
So, I propose that window names should match this regular expression:
[a-zA-Z][-_.a-zA-Z0-9]*
There is a chance that there is user code in the wild which will break
with the addition of this change, but hopefully adapting to the new
restrictions shouldn't be too difficult.
The testsuite implicitly tests GDB's ability to step through epilogues
in multiple tests, without doing it explicitly anywhere. This is
unfortunate, as clang does not emit epilogue information, so using clang
on our testsuite makes many tests fail. This patch adds a central,
explicit test for walking through the epilogue so we can safely remove
this from other tests and have them working with clang.
The test created attempts to step through a simple epilogue, an
epilogue that ends on another epilogue, and epilogues leading to other
function calls.
gdb.base/skip.exp was making use of a fixed number of step commands to
exit some functions. This caused some problems when using clang to test
GDB, as GDB would need fewer steps to reach the desired spots. For
instance, when testing in the section "step after disabling 3", the log
looks like this:
Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
(gdb) step
bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
21 return 1;
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1
step
foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
42 return 0;
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2
step
main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34
34 test_skip_file_and_function ();
(gdb) step
test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59
59 test_skip ();
(gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3
step
test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48
48 }
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4
step
test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60
60 skip1_test_skip_file_and_function ();
(gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5
This shows that the feature is working but because the inferior lands in
a different location, it registers as a failure. Seeing as along with
this difference, there are also some differences that depend on gcc
versions (where gdb might stop back at line 32 before entering foo), it
would not be easy to test for this behavior using steps and analzing
where the inferior stops at each point. On the other hand, using
gdb_step_until is not feasible because we'd possibly gloss over stepping
into baz and rendering the whole test useless. Instead, skip.exp now
uses finish to leave functions, synchronizing through compilers and
compiler versions. Some test names were also changed to be a bit more
descriptive. The new log looks like this, independently of compiler used:
Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
(gdb) step
bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
21 return 1;
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar
finish
Run till exit from #0 bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
Value returned is $2 = 1
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar
step
foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
42 return 0;
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo
finish
Run till exit from #0 foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
Value returned is $3 = 0
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo
step
34 test_skip_file_and_function ();
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz
When using clang as the compiler for the target, gdb.base/jit-elf.exp
was failing because the filename displayed when GDB attached to the
inferior was only showing up as with a relative path, like so:
(gdb) attach 3674146
Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146
Reading symbols from /lib64/libm.so.6...
Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
(No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
(gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
While gcc's output is as follows:
(gdb) attach 3592961
Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961
Reading symbols from /lib64/libm.so.6...
Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
(No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
(gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
This difference only happens when GDB's configure is ran using a
relative path, but seeing as testing the full path is not important for
this specific test, it feels worth fixing anyway. To fix the false
positive, the regexp for checking where gdb has stopped was relaxed a
little to allow the relative path.
When trying to test gdb.base/msym-bp-shl.exp using clang, it would have
many failures because one of the version of the foo function was being
optimized away. Adding __attribute__ ((used)) to it fixed this.
When testing gdb.base/skip-inline.exp using clang, we get failures
when trying to step out of functions, since clang requires one fewer
step when compared to gcc. The inferior gets increasingly out of sync
as the test continues because of this difference, which generates those
failures.
This commit fixes this by switching those hardcoded steps to
gdb_step_until, to guarantee that the inferior is always synced to what
the test expects. This approach does not work for the parts that use
step 2 or step 3, so when we identify that clang is being used, those
tests are skipped.
When running gdb.base/skip-solib.exp, the backtrace tests could fail with
compilers that associated epilogue instructions with the last statement
line of the function, instead of associating it with the closing brace,
despite the feature being fully functional. As an example, when testing
skipping the function square, the testsuite would show
Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5
5 return square(0);
(gdb) step
0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
(gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step
bt
#0 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
#1 0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6
#2 0x0000000000401065 in _start ()
(gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt
Which means that the feature is working, the testsuite is just
mis-identifying it. To avoid this problem, the skipped function calls
have been sent to a line before `return`, so epilogues won't factor in.
Different compilers link the epilogue of functions to different lines.
As an example, gcc links it to the closing brace of the function,
whereas clang links it to the last statement of the function. This
difference is important for the testsuite, since the where GDB will land
after a step can be wildly different. Where possible, this dependency
should be side-stepped in the testsuite, but it isn't always possible,
so this commit adds a gdb_caching_proc that is able to detect where the
epilogue is linked, so tests can react accordingly.
Add a new variable "ld_testsuite_tmpdir" to enable manual configuration
of the -B flag added to gcc calls. This flag ensure that gcc is invoking
the linker and the assembler we want to test.
When launching the testsuite outside of the build tree, the links made
by the testsuite in tmpdir/ld will point to nothing. Thus, even with the
PATH correctly setup towards the linker directory, gcc might end up
falling back to its default linker. Hence this variable to ensure that
gcc, whatever happens, is using the linker we want.
ld/ChangeLog:
* testsuite/config/default.exp: Allow to change -B flag with
ld_testsuite_bindir variable.
OFILES are normally provided through an environment variable set by
Makefiles. However, when launching the testsuite directly through
runtest outside the build tree, it can be hard to retrieve them.
Thus, they can be missing.
Instead of letting tcl raise an error when trying to access this
OFILES variable, skip bootstrap.exp if it doesn't exist.
ld/ChangeLog:
* testsuite/ld-bootstrap/bootstrap.exp: Skip if OFILES is
missing
There are a few operand types not used by any RISC-V instructions.
- Cx
- Vf
- Ve
- [
- ]
- b
But most of them has a reasoning to keep them:
- Cx : Same as "Ct" except it has a constraint to have rd == rs2
(similar to "Cw"). Although it hasn't used, its role is clear
enough to implement a new instruction with this operand type.
- Vf, Ve : Used by vector AMO instructions (not ratified and real
instructions are not upstreamed yet).
- [, ] : Unused tokenization symbols. Reserving them is not harmful
and a vendor may use this symbol for special purposes.
... except "b". I could not have found any reference to this operand type
except it works like the "s" operand type. Historically, it seems... it's
just unused from the beginning. Its role is not clear either.
On such cases, we should vacate this room for the new operand type with
much clearer roles.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Remove 'b' operand type.
Although they are not (and should not be) reachable, following macro-only
operands are parsed in the `validate_riscv_insn' function and ignored.
That function also notes that they are macro-only.
- "A"
- "B"
- "I"
Following this convention, this commit adds three remaining macro-only
operands to this function. By doing this, we could instead choose to reject
those operands from appearing in regular instructions later.
- "c" (used by call, tail and jump macros)
- "VM" (used by vmsge.vx and vmsgeu.vx macros)
- "VT" (likewise)
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Add "c", "VM" and "VT"
macro-only operand types.
A file that consists of a list of files doesn't depend on those files
being built. This patch came from trying to avoid a maintainer-mode
make -j bug, where the recipe for targmatch.h was being run twice in
parallel. Typical output shown below.
make[2]: Entering directory '/build/gas/all/bfd'
GEN bfdver.h
GEN elf32-target.h
GEN elf64-target.h
GEN targmatch.h
Making info in po
make[3]: Entering directory '/build/gas/all/bfd/po'
cd .. && make po/SRC-POTFILES.in
cd .. && make po/BLD-POTFILES.in
make[4]: Entering directory '/build/gas/all/bfd'
GEN elf32-aarch64.c
GEN elf64-aarch64.c
GEN elf32-ia64.c
GEN elf64-ia64.c
GEN elf32-loongarch.c
GEN elf64-loongarch.c
GEN elf32-riscv.c
GEN elf64-riscv.c
GEN peigen.c
GEN pepigen.c
GEN pex64igen.c
GEN pe-aarch64igen.c
GEN targmatch.h
make[4]: Entering directory '/build/gas/all/bfd'
CCLD doc/chew.stamp
mv: cannot stat 'targmatch.new': No such file or directory
make[4]: *** [Makefile:2325: targmatch.h] Error 1
* Makefile.am (po/BLD-POTFILES.in): Don't depend on $(BLD_POTFILES).
(po/SRC-POTFILES.in): Don't depend on $(SRC_POTFILES).
gdb_bfd.c and remote.c contain identical implementations of a
fileio_error -> errno function. Factor that out to
gdbsupport/fileio.{h,cc}.
Rename it fileio_error_to_host, for symmetry with host_to_fileio_error.
Change-Id: Ib9b8807683de2f809c94a5303e708acc2251a0df
Converting from free-form macros to an enum gives a bit of type-safety.
This caught places where we would assign host error numbers to what
should contain a target fileio error number, for instance in
target_fileio_pread.
I added the FILEIO_SUCCESS enumerator, because
remote.c:remote_hostio_parse_result initializes the remote_errno output
variable to 0. It seems better to have an explicit enumerator than to
assign a value for which there is no enumerator. I considered
initializing this variable to FILEIO_EUNKNOWN instead, such that if the
remote side replies with an error and omits the errno value, we'll get
an errno that represents an error instead of 0 (which reprensents no
error). But it's not clear what the consequences of that change would
be, so I prefer to err on the side of caution and just keep the existing
behavior (there is no intended change in behavior with this patch).
Note that remote_hostio_parse_resul still reads blindly what the remote
side sends as a target errno into this variable, so we can still end up
with a nonsensical value here. It's not good, but out of the scope of
this patch.
Convert host_to_fileio_error and fileio_errno_to_host to return / accept
a fileio_error instead of an int, and cascade the change in the whole
chain that uses that.
Change-Id: I454b0e3fcf0732447bc872252fa8e57d138b0e03
I don't see why include/gdb/fileio.h is placed there. It's not
installed by "make install", and it's not included by anything outside
of gdb/gdbserver/gdbsupport.
Move its content back to gdbsupport/fileio.h. I have omitted the bits
inside an `#if 0`, since it's obviously not used, as well as the
"limits" constants, which are also unused.
Change-Id: I6fbc2ea10fbe4cfcf15f9f76006b31b99c20e5a9
When a GDB built with -D_GLIBCXX_DEBUG=1 reads a binary with a single
character name, we hit this assertion failure:
$ ./gdb -q --data-directory=data-directory -nx ./x
/usr/include/c++/12.1.0/string_view:239: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed.
The backtrace:
#3 0x00007ffff6c0f002 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60
#4 0x000055555da8a864 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffcc30, __pos=1) at /usr/include/c++/12.1.0/string_view:239
#5 0x00005555609dcb88 in path_join[abi:cxx11](gdb::array_view<std::basic_string_view<char, std::char_traits<char> > const>) (paths=...) at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:203
#6 0x000055555e0443f4 in path_join<char const*, char const*> () at /home/simark/src/binutils-gdb/gdb/../gdbsupport/pathstuff.h:84
#7 0x00005555609dc336 in gdb_realpath_keepfile[abi:cxx11](char const*) (filename=0x6060000a8d40 "/home/simark/build/binutils-gdb-one-target/gdb/./x") at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:122
#8 0x000055555ebd2794 in exec_file_attach (filename=0x7fffffffe0f9 "./x", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:471
#9 0x000055555f2b3fb0 in catch_command_errors (command=0x55555ebd1ab6 <exec_file_attach(char const*, int)>, arg=0x7fffffffe0f9 "./x", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:513
#10 0x000055555f2b7e11 in captured_main_1 (context=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1209
#11 0x000055555f2b9144 in captured_main (data=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1319
#12 0x000055555f2b9226 in gdb_main (args=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1344
#13 0x000055555d938c5e in main (argc=5, argv=0x7fffffffdcf8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
The problem is this line in path_join:
gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path));
... where `path` is "x". IS_ABSOLUTE_PATH eventually calls
HAS_DRIVE_SPEC_1:
#define HAS_DRIVE_SPEC_1(dos_based, f) \
((f)[0] && ((f)[1] == ':') && (dos_based))
This macro accesses indices 0 and 1 of the input string. However, `f`
is a string_view of length 1, so it's incorrect to try to access index
1. We know that the string_view's underlying object is a null-terminated
string, so in practice there's no harm. But as far as the string_view
is concerned, index 1 is considered out of bounds.
This patch makes the easy fix, that is to change the path_join parameter
from a vector of to a vector of `const char *`. Another solution would
be to introduce a non-standard gdb::cstring_view class, which would be a
view over a null-terminated string. With that class, it would be
correct to access index 1, it would yield the NUL character. If there
is interest in having this class (it has been mentioned a few times in
the past) I can do it and use it here.
This was found by running tests such as gdb.ada/arrayidx.exp, which
produce 1-char long filenames, so adding a new test is not necessary.
Change-Id: Ia41a16c7243614636b18754fd98a41860756f7af
Add the `length` and `set_length` methods on `struct type`, in order to remove
the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the
getter, so all the call sites of the macro that are used as a setter are
changed to use the setter method directly. The next patch will remove the
macro completely.
Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
Add the `target_type` and `set_target_type` methods on `struct type`, in order
to remove the `TYPE_TARGET_TYPE` macro. In this patch, the macro is changed to
use the getter, so all the call sites of the macro that are used as a setter
are changed to use the setter method directly. The next patch will remove the
macro completely.
Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161
To avoid -Werror=strict-prototypes, this commit changes () to (void).
This is because "()" possibly means a function prototype with indeterminate
arguments on old C standards.
gas/ChangeLog:
* config/tc-riscv.c (riscv_set_tso): Fix declaration.
Allow and ignore an empty section.
PR 29566
* elf.c (bfd_section_from_shdr): Don't set elf_dynverdef or
elf_dynverref for empty sections.
(_bfd_elf_slurp_version_tables): Remove now redundant tests.
