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.
This is a minor fix to commit 96462b0129
("RISC-V: Implement Ztso extension"). Currently, it sets EF_RISCV_TSO ELF
flag when initial ISA string contains the 'Ztso' extension. However, GAS
has a way to update the ISA string: ".option arch".
When the architecture is updated by ".option arch", EF_RISCV_RVC ELF flag
is set when the 'C' extension is detected. Analogously, this commit sets
the EF_RISCV_TSO when the 'Ztso' extension is detected.
gas/ChangeLog:
* config/tc-riscv.c (s_riscv_option): Set TSO ELF flag if the
'Ztso' extension is specified via ".option arch" directive.
The DWARF standard is clear that DW_AT_linkage_name is optional.
Compilers may not provide the attribute on functions and variables,
even though the language mangles names. g++ does not for local
variables and functions. Without DW_AT_linkage_name, mangled object
file symbols can't be directly matched against the source-level
DW_AT_name in DWARF info. One possibility is demangling the object
file symbols, but that comes with its own set of problems:
1) A demangler might not be available for the compiler/language.
2) Demangling doesn't give the source function name as stored in
DW_AT_name. Class and template parameters must be stripped at
least.
So this patch takes a simpler approach. A symbol matches DWARF info
if the DWARF address matches the symbol address, and if the symbol
name contains the DWARF name as a sub-string. Very likely the name
matching is entirely superfluous.
PR 29573
* dwarf.c (lookup_symbol_in_function_table): Match a symbol
containing the DWARF source name as a substring.
(lookup_symbol_in_variable_table): Likewise.
(_bfd_dwarf2_find_nearest_line_with_alt): If stash_find_line_fast
returns false, fall back to comp_unit_find_line.
non_mangled incorrectly returned "true" for Ada. Correct that, and
add a few more non-mangled entries. Return a value suitable for
passing to cplus_demangle to control demangling.
* dwarf2.c: Include demangle.h.
(mangle_style): Rename from non_mangled. Return DMGL_* value
to suit lang. Adjust all callers.
The "sec" field in these structures is only set and used in lookup
functions. It always starts off as NULL. So the only possible effect
of the field is to modify the return of the lookup, which was its
purpose back in 2005 when HJ fixed PR990. Since then we solved the
problem of relocatable object files with the fix for PR2338, so this
field is now redundant.
* dwarf.c (struct funcinfo, struct varinfo): Remove "sec" field.
(lookup_symbol_in_function_table): Don't set or test "sec".
(lookup_symbol_in_variable_table): Likewise.
(info_hash_lookup_funcinfo, info_hash_lookup_varinfo): Likewise.
Because CPPFLAGS_FOR_BUILD is used in some subdirectories (through
bfd/warning.m4), not AC_SUBSTing the variable causes minor issues.
Fortunately, it didn't cause severe errors but error messages related to
@CPPFLAGS_FOR_BUILD@ (not AC_SUBSTed CPPFLAGS_FOR_BUILD variable passed
to subdirectories through Makefile) remain in config.log.
To avoid invalid invocation of preprocessor for build environment, we
need to set proper CPPFLAGS_FOR_BUILD (may be empty) and pass it to
subdirectories that need it. This is what this commit does.
ChangeLog:
* configure.ac: Pass CPPFLAGS_FOR_BUILD to subdirectories.
* configure: Regenerate.
This patch support ZTSO extension. It will turn on the tso flag for elf_flags
once we have enabled Ztso extension. This is intended to implement v0.1 of
the proposed specification which can be found in Chapter 25 of,
https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220723-10eea63/riscv-spec.pdf.
bfd\ChangeLog:
* elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Set TSO flag.
* elfxx-riscv.c: Add Ztso's arch.
binutils\ChangeLog:
* readelf.c (get_machine_flags): Set TSO flag.
gas\ChangeLog:
* config/tc-riscv.c (riscv_set_tso): Ditto.
(riscv_set_arch): Ditto.
* testsuite/gas/riscv/ztso.d: New test.
include\ChangeLog:
* elf/riscv.h (EF_RISCV_TSO): Ditto.
Since we have the same behaviors of CALL and CALL_PLT relocs in linker for now,
3b1450b38c
And the psabi already deprecate the CALL reloc,
a0dced8501
Therefore, we should always generate R_RISCV_CALL_PLT reloc for call, even if
it has @plt postfix. I believe LLVM (https://reviews.llvm.org/D132530) already
support this, so GNU as should do the same thing.
gas/
* config/tc-riscv.c (riscv_ip): Always generate CALL_PLT reloc for
call, even if it has @plt postfix.
* testsuite/gas/riscv/no-relax-reloc.d: Updated CALL to CALL_PLT.
* testsuite/gas/riscv/relax-reloc.d: Likewise.
ld/
* testsuite/ld-riscv-elf/variant_cc-r.d: Updated CALL to CALL_PLT.
The last patch wasn't all that shiny. There are rather a lot more
relocations that can hit the assertion in md_apply_fix if the symbol
is local or absolute. Fix them all.
* config/tc-ppc.c (ppc_force_relocation): Add all relocs that
expect a symbol in md_apply_fix. Remove tls pcrel relocs
already covered in general tls match range.
The direct cause for the looping was failing to test for error return
from _bfd_vms_get_object_record inside a while(1) loop. Fix that.
Also record status of first alpha_vms_slurp_relocs call and return
that for all subsequent calls. (The object format has one set of
relocation records for all sections.) If the first call fails, all
others should too.
* vms-alpha.c (struct vms_private_data_struct): Make reloc_done
a tri-state int.
(alpha_vms_slurp_relocs): Set reloc_done to 1 on success, -1 on
failure. Return that status on subsequent calls. Check
_bfd_vms_get_object_record return status.
(alpha_vms_get_reloc_upper_bound): Return status from
alpha_vms_slurp_relocs.
(alpha_vms_write_exec): Exclude sections with contents NULL due
to previous errors from layout, and don't try to write them.
