[ Copied from gcc commit 153689603fd ("[gdb/build] Fix gdbserver build with
-fsanitize=thread"). ]
When building gdbserver with -fsanitize=thread (added to CFLAGS/CXXFLAGS) we
run into:
...
ld: ../libiberty/libiberty.a(safe-ctype.o): warning: relocation against \
`__tsan_init' in read-only section `.text'
ld: ../libiberty/libiberty.a(safe-ctype.o): relocation R_X86_64_PC32 \
against symbol `__tsan_init' can not be used when making a shared object; \
recompile with -fPIC
ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[1]: *** [libinproctrace.so] Error 1
...
which looks similar to what is described in commit 78e4948694 ("[gdb/build]
Fix gdbserver build with -fsanitize=address").
The gdbserver component builds a shared library libinproctrace.so, which uses
libiberty and therefore requires the pic variant. The gdbserver Makefile is
setup to use this variant, if available, but it's not there.
Fix this by listing gdbserver in the toplevel configure alongside libcc1, as a
component that needs the libiberty pic variant, setting:
...
extra_host_libiberty_configure_flags=--enable-shared
...
Tested on x86_64-linux.
ChangeLog:
2022-06-27 Tom de Vries <tdevries@suse.de>
* configure.ac: Build libiberty pic variant for gdbserver.
* configure: Regenerate.
PR 29263
* configure.ac: Move HPPA specific code from here...
* configure.tgt: ... to here. Add similar code for MIPS.
Move code for CRIS, MIPS and HPPA to block at start of file.
* configure: Regenerate.
The final "match all" case can take care of a few explicit entries:
Purge those. Also move s12z* into proper position (the table is
otherwise sorted, after all).
Commit 04f096fb9e ("Move the xc16x target to the obsolete list") moved
the architecture from the "obsolete but still available" to the
"obsolete / support removed" list in config.bfd, making the architecture
impossible to enable (except maybe via "enable everything" options").
Note that I didn't touch */po/*.po{,t} on the assumption that these
would be updated by some (half)automatic means.
For clang compiled objects with dwarf-5, location list offset address dump
under DW_AT_location is corrected, where DW_FORM_loclistx is used. While
dumping the location list offset, the address dumped is wrong where it was
refering to .debug_addr instead of .debug_loclists
* dwarf.c (fetch_indexed_value): Add base_address as parameter and
use it to access the section offset.
(read_and_display_attr_value): Handle DW_FORM_loclistx form separately.
Pass loclists_base to fetch_indexed_value().
.branch_lt is really an extension of .plt, as is .iplt. We'd like all
of the PLT sections to be fixed relative to .TOC. after stub sizing,
because changes in offset to PLT entries might mean a change in stub
sizes. When -z relro, the relro layout does this by laying out
sections from the end of the relro segment. So for example, a change
in .eh_frame (which happens after stub sizing) will keep the same GOT
to PLT offset when -z relro. Not so when -z norelro, because then the
usual forward layout of section is done and .got is more aligned than
.branch_lt.
* emulparams/elf64ppc.sh: Set .branch_lt address fixed relative
to .got.
* testsuite/ld-powerpc/elfv2exe.d: Adjust to suit.
A number of targets use assignments like:
. = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 12 ? 12 : 0, .);
(from i386) in linker scripts to put the end of the relro segment past
the header in .got.plt. Examination of testcases like those edited by
this patch instead sees the end of the relro segment being placed at
the start of .got.plt. For the i386 pie1 test:
[ 9] .got.plt PROGBITS 00002000 001000 00000c 04 WA 0 0 4
GNU_RELRO 0x000f90 0x00001f90 0x00001f90 0x00070 0x00070 R 0x1
A map file shows:
.dynamic 0x0000000000001f90 0x70
*(.dynamic)
.dynamic 0x0000000000001f90 0x70 tmpdir/pie1.o
0x0000000000001f90 _DYNAMIC
.got 0x0000000000002000 0x0
*(.got)
.got 0x0000000000002000 0x0 tmpdir/pie1.o
*(.igot)
0x0000000000002ff4 . = DATA_SEGMENT_RELRO_END (., (SIZEOF (.got.plt) >= 0xc)?0xc:0x0)
.got.plt 0x0000000000002000 0xc
*(.got.plt)
.got.plt 0x0000000000002000 0xc tmpdir/pie1.o
0x0000000000002000 _GLOBAL_OFFSET_TABLE_
The DATA_SEGMENT_RELRO_END value in the map file is weird too. All of
this is triggered by SIZEOF (.got.plt) being evaluated wrongly as
zero. Fix it by taking into account the action of
lang_reset_memory_regions during relaxation.
* ldexp.c (fold_name <SIZEOF>): Use rawsize if size has been reset.
* ldlang.c (lang_size_sections_1): Don't reset processed_vma here.
* testsuite/ld-i386/pie1.d: Adjust to suit.
* testsuite/ld-x86-64/pr20830a.d: Likewise.
* testsuite/ld-x86-64/pr20830b.d: Likewise.
* testsuite/ld-x86-64/pr21038a.d: Likewise.
* testsuite/ld-x86-64/pr21038b.d: Likewise.
* testsuite/ld-x86-64/pr21038c.d: Likewise.
Similar to commit 4fb55bf6a9 for aarch64.
Commit b68a20d667 changed ld to produce
R_ARM_GLOB_DAT but that defeated the purpose of protected visibility
as an optimization. Restore the previous behavior (which matches
ld.lld) by defining elf_backend_extern_protected_data to 0.
The dw2-double-set-die-type.exp test case caused an AddressSanitizer
failure in the new DWARF scanner.
The immediate cause was bad DWARF in the test -- in particular, the
the sibling attribute here:
<2><181>: Abbrev Number: 33 (DW_TAG_subprogram)
<182> DW_AT_external : 1
<183> DW_AT_name : address
<18b> DW_AT_type : <0x171>
<18f> DW_AT_declaration : 1
<190> DW_AT_sibling : <0x1a1>
...
<1><1a1>: Abbrev Number: 23 (DW_TAG_pointer_type)
<1a2> DW_AT_byte_size : 4
<1a3> DW_AT_type : <0x1a7>
...points to a "sibling" DIE that is at a different child depth.
Because this test case doesn't really require sibling attributes, this
patch fixes the problem by removing them from the test.
Note that gdb is not generally robust against malformed DWARF.
Detecting and compensating for this problem would probably be
expensive and, IMO, is better left to some (still hypothetical) DWARF
linter.
cooked_indexer::index_dies incorrect computes the end of the current
CU in the .debug_info. This isn't readily testable without writing
intentionally corrupt DWARF, but it's apparent through observation: it
is currently based on 'info_ptr', which does not always point to the
start of the CU. This patch fixes the expression. Tested on x86-64
Fedora 34.
This commit defines register numbers of various important registers,
we can use them directly in the related code, and also clean up some
code to make them more clear and readable.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
For historical reasons, the CLI and the TUI observers are basically
exact duplicates, except for the downcast:
cli:
struct cli_interp *cli = as_cli_interp (interp);
tui:
struct interp *tui = as_tui_interp (interp);
and how they get at the interpreter's ui_out:
cli:
cli->cli_uiout
tui:
tui->interp_ui_out ()
Since interp_ui_out() is a virtual method that also works for the CLI
interpreter, and, both the CLI and the TUI interpreters inherit from
the same base class (cli_interp_base), we can convert the CLI
observers to cast to cli_interp_base instead and use interp_ui_out()
too. With that, the CLI observers will work for the TUI interpreter
as well. This lets us completely eliminate the TUI observers. That's
what this commit does.
Change-Id: Iaf6cf12dfa200ed3ab203a895a72b69dfedbd6e0
Turns out we'll be gaining a new use of this function very soon, the
incoming AMDGPU port needs it. Let's add it back, as it isn't really
hurting anything.
This reverts commit 39b8a8090e.
For Arm Cortex-M33 with security extensions, there are 4 different
stacks pointers (msp_s, msp_ns, psp_s, psp_ns).
When plain "sp" is updated during unwinding of the stack, the active
stack pointer of the 4 stack pointers needs to be kept in sync.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
It is not necessary to call get_compiler_info before calling
test_compiler_info, and, after recent commits that removed setting up
the gcc_compiled, true, and false globals from get_compiler_info,
there is now no longer any need for any test script to call
get_compiler_info directly.
As a result every call to get_compiler_info outside of lib/gdb.exp is
redundant, and this commit removes them all.
There should be no change in what is tested after this commit.
After this commit the gcc_compiled global is no longer exported from
lib/gdb.exp. In theory we could switch over all uses of gcc_compiled
to instead call test_compiler_info directly, however, I have instead
added a new proc to gdb.exp: 'is_c_compiler_gcc'. I've then updated
the testsuite to call this proc instead of using the global.
Having a new proc specifically for this task means that we have a
single consistent pattern for detecting gcc. By wrapping this logic
within a proc that calls test_compiler_info, rather than using the
global, means that test scripts don't need to call get_compiler_info
before they read the global, simply calling the new proc does
everything in one go.
As a result I've been able to remove the get_compiler_info calls from
all the test scripts that I've touched in this commit.
In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was
being checked at the top of the script to decide if the whole script
should be skipped or not. In these cases I've called the new proc
directly and removed all uses of gcc_compiled.
In other cases, e.g. most of the gdb.base scripts, there were many
uses of gcc_compiled. In these cases I set a new global gcc_compiled
near the top of the script, and leave the rest of the script
unchanged.
There should be no changes in what is tested after this commit.
If GDB, GDBserver, a testcase program, Valgrind, etc. unexpectedly
crash while running the GDB testsuite, and you've setup your machine
such that core files are dumped in the current directory instead of
being shoved somewhere by abrt, apport, or similar (as you should for
proper GDB testing), you'll end up with an unexpected core file in the
$build/gdb/testsuite/ directory.
It can happen that GDB, GDBserver, etc. even crashes _after_ gdb_exit,
during teardown, and thus such a crash won't be noticed by looking at
the gdb.sum file at all. This commit aims at improving that, by
including a new "unexpected core files" line in the testrun summary.
For example, here's what I get on x86-64 Ubuntu 20.04, with this
patch:
=== gdb Summary ===
# of unexpected core files 12 << new info
# of expected passes 107557
# of unexpected failures 35
# of expected failures 77
# of unknown successes 2
# of known failures 114
# of untested testcases 31
# of unsupported tests 139
I have my core pattern setup like this:
$ cat /proc/sys/kernel/core_pattern
core.%e.%p.%h.%t
That's:
%e: executable filename
%p: pid
%h: hostname
%t: UNIX time of dump
and so I get these core files:
$ ls -1 testsuite/core.*
testsuite/core.connect-with-no.216191.nelson.1656002431
testsuite/core.connect-with-no.217729.nelson.1656002431
testsuite/core.gdb.194247.nelson.1656002423
testsuite/core.gdb.226014.nelson.1656002435
testsuite/core.gdb.232078.nelson.1656002438
testsuite/core.gdb.352268.nelson.1656002441
testsuite/core.gdb.4152093.nelson.1656002337
testsuite/core.gdb.4154515.nelson.1656002338
testsuite/core.gdb.4156668.nelson.1656002339
testsuite/core.gdb.4158871.nelson.1656002341
testsuite/core.gdb.468495.nelson.1656002444
testsuite/core.vgdb.4192247.nelson.1656002366
where we can see that GDB crashed a number of times, but also
Valgrind's vgdb, and a couple testcase programs. Neither of which is
good.
If your core_pattern is just "core" (but why??), then I guess that you
may end up with just a single core file in testsuite/. Still, that is
one core file too many.
Above, we see a couple cores for "connect-with-no", which are the
result of gdb.server/connect-with-no-symbol-file.exp. This is a case
mentioned above -- while the program crashed, that happens during
testcase teardown, and it goes unnoticed (without this commit) by
gdb.sum results. Vis:
$ make check TESTS="gdb.server/connect-with-no-symbol-file.exp"
...
=== gdb Summary ===
# of unexpected core files 2
# of expected passes 8
...
$
The tests fully passed, but still the testcase program crashed
somehow:
$ ls -1 testsuite/core.*
testsuite/core.connect-with-no.941561.nelson.1656003317
testsuite/core.connect-with-no.941682.nelson.1656003317
Against --target_board=native-extended-gdbserver it's even worse. I
get:
# of unexpected core files 26
and note that when GDBserver hits an assertion failure, it exits with
error, instead of crashing with SIGABRT. I think that should be
changed, at least on development builds, but that would be for another
patch. After such patch, I suspect the number of unexpected cores
will be higher, as there are likely teardown GDBserver assertions that
we're not noticing.
I decided to put this new info in the "gdb Summary" section, as that's
a place people already are used to looking at, either when looking at
the tail of gdb.sum, or when diffing gdb.sum files, and we've already
extended this section before, to include the count of DUPLICATE and
PATH problems, so there's precedent.
Implementation-wise, the new line is appended after DejaGnu is
finished, with a shell script that is invoked by the Makefile. It is
done this way so that serial and parallel testing work the same way.
My initial cut at an implementation was in TCL, straight in
testsuite/lib/check-test-names.exp, where DUPLICATES and PATH are
handled, like so:
@@ -148,6 +159,10 @@ namespace eval ::CheckTestNames {
$counts(paths,$which)
maybe_show_count "# of duplicate test names\t" \
$counts(duplicates,$which)
+
+ set cores [glob -nocomplain -directory $::objdir core*]
+ maybe_show_count "# of unexpected core files\t" \
+ [llength $cores]
}
But that would only work for serial testing, as in parallel testing,
the final gdb.sum is generated by aggregating the results of all the
individual gdb.sum files, and dg-extract-results.sh doesn't know about
our new summary line. And I don't think that dg-extract-results.sh
should be taught about it, since the count of core files is not
something that we want to count many times, once per testcase, and
then add up the subcounts at the end. Every time we count the core
files, we're already counting the final count.
I considered using the Tcl implementation in serial mode, and the
script approach for parallel testing, but that has the obvious
downside of implementing and maintaining the same thing twice. In the
end, I settled on the script approach for serial mode too, which
requires making the "check-single" rule print the tail end of the
gdb.sum file, with a side effect being that if you look at the
terminal after a run (instead of at the gdb.sum file), you'll see the
"gdb Summary" section twice, once without the unexpected core lines
printed, and then another with. IMO, this isn't an issue; when
testing in parallel mode, if you look at the terminal after "make -jN
check", you'll also see multiple "gdb Summary" sections printed.
Change-Id: I190b8d41856d49ad143854b6e3e6ccd7caa04491
After a testrun, I noticed that I have some kernel-produced cores for
testcase programs, under build/gdb/testsuite/, which shouldn't be
there:
$ ls -1 testsuite/core.*
testsuite/core.annota1.1274351.nelson.1656004407
testsuite/core.annota3.1288474.nelson.1656004414
testsuite/core.exitsignal.1240674.nelson.1656004391
I have my core pattern setup like this:
$ cat /proc/sys/kernel/core_pattern
core.%e.%p.%h.%t
That's:
%e: executable filename
%p: pid
%h: hostname
%t: UNIX time of dump
so it's easy to tell which program produced the core from the core
file name.
From above, we can tell that the corresponding testcases are
gdb.base/annota1.exp, gdb.base/annota3.exp and
gdb.base/exitsignal.exp.
At least gdb.base/annota1.exp and gdb.base/annota3.exp have code in
them to delete the core file. However, that isn't working for me,
because said code only looks for cores named exactly either "core" or
"core.PID", and my core_pattern doesn't match that.
Another issue I noticed, is that I have not been running
gdb.base/bigcore.exp, for a similar reason. I get:
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
UNTESTED: gdb.base/bigcore.exp: can't generate a core file
But I actually have a core file under the testcase's output dir:
$ find . -name "core.*"
./testsuite/outputs/gdb.base/bigcore/core.bigcore.2306705.nelson.1656005213
$
This commit fixes these things, by adding a find_core_file routine
that searches core files in a way that works with my core pattern as
well. This then also adds a convenience remove_core routine as a
wrapper around find_core_file that removes the found core file.
In addition, it changes some testcases that expect to have their
program dump core, to switch the inferior's cwd to the testcase's
output dir, so that the core is dumped there instead of in
build/gdb/testsuite/. Some testcases were already doing that, but not
all. The idea is that any core file dumped in build/gdb/testsuite/ is
an unexpected core file. The next patch will add a count of such
unexpected core files to gdb.sum.
Another change is that the directory changing is now done with "set
cwd" instead of with "cd". "set cwd" only affects the inferior cwd,
while "cd" affects GDB's cwd too. By using "set cwd" instead of "cd",
if GDB dumps core in these testcases, the GDB core dump will still end
up in build/gdb/testsuite/, and can thus be detected as an unexpected
core.
Change-Id: I45068f21ffd4814350aaa8a3cc65cad5e3107607
In passing I noticed that there are three local variables in
run_inferior_call that are used to save, and then restore some state,
I think these could all be replaced with a RAII style scoped_restore
instead.
Of the three locals that I've changed, the only one that I believe is
now restored in a different location is ui::async, before this commit
the async field was restored after a call to either delete_file_handle
or ui_register_input_event_handler, and after this commit, the field
is restored before these calls. However, I don't believe that either
of these functions depend on the value of the async field, so I
believe the commit is fine.
Tested on x86-64/Linux passes with no regressions.
cli_set_logging is declared but not defined. It's probably a leftover
from whenever interpreters were changed to use inheritance. This
patch removes the declaration. Tested by grep and rebuilding.
I noticed a few spots that were explicitly creating new references to
Py_True or Py_False. It's simpler here to use PyBool_FromLong, so
this patch changes all the places I found.
save_res stubs aren't written in ppc_build_one_stub, their offsets
(which are zero) should not be checked.
* elf64-ppc.c (ppc_build_one_stub): Don't check save_res offsets.
Let's show the current stub as well as the previous one. Of interest
is the current offset and a new field, id. Check that the build
hash table traversal is in the same order as sizing traversal too.
* elf64-ppc.c (struct ppc_stub_hash_entry): Add id.
(struct ppc_link_hash_table): Add stub_id.
(stub_hash_newfunc): Init id and symtype.
(dump_stub): New function, extracted from..
(dump_previous_stub): ..here. Deleted.
(ppc_build_one_stub): Sanity check stub id as well as offset.
Show current stub as well as previous.
(ppc_size_one_stub): Set stub id.
(ppc64_elf_size_stubs): Init stub_id before traversal.
(ppc64_elf_build_stubs): Likewise.
__attribute__((visibility("protected"))) void *foo() {
return (void *)foo;
}
gcc -fpic -shared -fuse-ld=bfd fails with the confusing diagnostic:
relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `foo' which may bind externally can not be used when making a shared object; recompile with -fPIC
Call _bfd_elf_symbol_refs_local_p with local_protected==true to suppress
the error. The new behavior matches gold and ld.lld.
Note: if some code tries to use direct access relocations to take the
address of foo (likely due to -fno-pic), the pointer equality will
break, but the error should be reported on the executable link, not on
the innocent shared object link. glibc 2.36 will give a warning at
relocation resolving time.
Follow-up to commit 90b7a5df15
("aarch64: Disallow copy relocations on protected data").
Commit 32f573bcb3 changed ld to produce
R_AARCH64_GLOB_DAT but that defeated the purpose of protected visibility
as an optimization. Restore the previous behavior (which matches
ld.lld) by defining elf_backend_extern_protected_data to 0.
I noticed that touching interps.h caused a lot of recompilation. I
tracked this down to mi-common.h including this file. This patch
moves the MI interpreter to mi-interp.h, which cuts down on
recompilation when modifying interps.h.
This changes interp::m_name to be a unique_xmalloc_ptr, removing some
manual memory management. It also cleans up the initialization of the
'inited' member, and moves the 'private:' and 'public:' keywords to
their proper spots.
If an executable has copy relocations for extern protected data, that
can only work if the shared object containing the definition is built
with assumptions (a) the compiler emits GOT-generating relocations (b)
the linker produces R_*_GLOB_DAT instead of R_*_RELATIVE. Otherwise the
shared object uses its own definition directly and the executable
accesses a stale copy. Note: the GOT relocations defeat the purpose of
protected visibility as an optimization, and it turns out this never
worked perfectly.
glibc 2.36 will warn on copy relocations on protected data. Let's
produce a warning at link time, matching ld.lld which has been used on
many aarch64 OSes.
Note: x86 requires GNU_PROPERTY_NO_COPY_ON_PROTECTED to have the error.
This is to largely due to GCC 5's "x86-64: Optimize access to globals in
PIE with copy reloc" which started to use direct access relocations for
external data symbols in -fpie mode.
GCC's aarch64 port does not have the change. Nowadays with most builds
switching to -fpie/-fpic, aarch64 mostly doesn't need to worry about
copy relocations. So for aarch64 we simply don't check
GNU_PROPERTY_NO_COPY_ON_PROTECTED.
* dwarf.c (fetch_indexed_string): Added new parameter
str_offsets_base to calculate the string offset.
(read_and_display_attr_value): Read DW_AT_str_offsets_base
attribute.
(process_debug_info): While allocating memory and initializing
debug_information, do it for do_debug_info also, if its true.
(load_separate_debug_files): Load .debug_str_offsets if exists.
* dwarf.h (struct debug_info): Add str_offsets_base field.
This patch has been pending for almost a year... However, I noticed that
llvm can already re-order the extensions, even if they are out of orders.
Not really sure if they can also re-order the single letter extensions,
but at least we can do this for the multi-letter extensions in binutils.
bfd/
* elfxx-riscv.c (riscv_parse_prefixed_ext): Removed the code which are
used to check the prefixed extension orders.
gas/
* testsuite/gas/riscv/march-fail-order-x-z.d: Removed since we will help
tp reorder the prefixed extensions for now.
* testsuite/gas/riscv/march-fail-order-x-z.l: Likewise.
* testsuite/gas/riscv/march-fail-order-x.d: Likewise.
* testsuite/gas/riscv/march-fail-order-x.l: Likewise.
* testsuite/gas/riscv/march-fail-order-z.d: Likewise.
* testsuite/gas/riscv/march-fail-order-z.l: Likewise.
According to the picture 28.1 in the current ISA spec, h is no larger the
multi-letter extension, it is a single extension after v. Therefore, this
patch fix the implementation, and use the single h to control hypervisor
CSRs and instructions, which we promised to do before.
bfd/
* elfxx-riscv.c (riscv_supported_std_ext): Added h with version 1.0 after v.
(riscv_supported_std_h_ext): Removed.
(riscv_all_supported_ext): Updated since riscv_supported_std_h_ext is removed.
(riscv_prefix_ext_class): Removed RV_ISA_CLASS_H.
(parse_config): Updated since riscv_prefix_ext_class is removed.
(riscv_recognized_prefixed_ext): Likewise.
(riscv_get_default_ext_version): Likewise.
(riscv_multi_subset_supports): Handle INSN_CLASS_H for hypervisor instructions.
(riscv_multi_subset_supports_ext): Likewise.
gas/
* config/tc-riscv.c (riscv_csr_class): Added CSR_CLASS_H and CSR_CLASS_H_32 for
hypervisor CSRs.
(riscv_csr_address): Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Updated since hypervisor CSRs are
controlled by single h extension for now.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/h-ext-32.d: Added h to architecture string.
* testsuite/gas/riscv/h-ext-64.d: Likewise.
* testsuite/gas/riscv/march-fail-single-prefix-h: Removed since h is no
longer multi-letter extension.
* testsuite/gas/riscv/march-fail-unknown-h.d: Likewise.
include/
* opcode/riscv-opc.h: Control hypervisor CSRs by h extension, rather than
the privileged spec verisons.
* opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_H.
opcodes/
* riscv-opc.c (riscv_opcodes): Control hypervisor instructions by h extension.
This commit adds 'H' to canonical extension ordering based on current
consensus (not officially ratified as a new ISA specification manual
but discussion for software compatibility is made).
bfd/ChangeLog
* elfxx-riscv.c (riscv_ext_canonical_order): Add 'H' for
canonical extension ordering based on current consensus.
Some strings returned by the riscv_multi_subset_supports_ext function
contain not just extension names but words like "and" and "or".
This commit wraps such strings with the gettext macro (_) for
internationalization in the future.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports_ext): Wrap some
strings with the gettext macro to prepare future i18n.
This commit fixes inconsistent error message format involving compressed
funct<n> fields. In specific, funct6 had an error message with range
0..2^<n> ("0..64") unlike other funct<n> fields with 0..2^<n>-1
(e.g. funct4 with "0..15").
gas/ChangeLog:
* config/tc-riscv.c (riscv_ip): Fix inconsistent error message.
Using xmalloc makes the null check redundant since failing allocation
will exit the program. Instead use malloc and let the error be
conveyed up the call chain.
powerpc64le-linux-ld is failing the assertion in ppc_build_one_stub,
again apparently, which means a stub will overwrite the tail of a
previous stub. The difficulty with debugging these issues is that
it's not a problem with the stub that triggers the assertion, but the
previous stub in that section. This patch keeps track of the last
stub and adds a debug dump. Hopefully that will help.
* elf64-ppc.c (enum _ppc64_sec_type): Add sec_stub.
(struct _ppc64_elf_section_data): Add u.last_ent.
(dump_previous_stub): New function.
(ppc_build_one_stub): Keep track of previous stub, and dump it
when finding an overlapping stub.
We were failing to call prune_warnings appropriately, leading to
false-positive test failures on some platforms (observed on
sparclinux).
libctf/ChangeLog:
* testsuite/lib/ctf-lib.exp: Prune warnings from compiler and
linker output.
* testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise,
and ar output too.
A missing paren led to an intended cast to avoid dependence on the size
of size_t in one argument of ctf_err_warn applying to the wrong type by
mistake.
libctf/ChangeLog:
* ctf-serialize.c (ctf_write_mem): Fix cast.
Right now, if you compile the same .c input repeatedly with CTF enabled
and different compilation flags, then arrange to link all of these
together, then things misbehave in various ways. libctf may conflate
either inputs (if the .o files have the same name, say if they are
stored in different .a archives), or per-CU outputs when conflicting
types are found: the latter can lead to entirely spurious errors when
it tries to produce multiple per-CU outputs with the same name
(discarding all but the last, but then looking for types in the earlier
ones which have just been thrown away).
Fixing this is multi-pronged. Both inputs and outputs need to be
differentiated in the hashtables libctf keeps them in: inputs with the
same cuname and filename need to be considered distinct as long as they
have different associated CTF dicts, and per-CU outputs need to be
considered distinct as long as they have different associated input
dicts. Right now there is nothing tying the two together other than the
CU name: fix this by introducing a new field in the ctf_dict_t named
ctf_link_in_out, which (for input dicts) points to the associated per-CU
output dict (if any), and for output dicts points to the associated
input dict. At creation time the name used is completely arbitrary:
it's only important that it be distinct if CTF dicts are distinct. So,
when a clash is found, adjust the CU name by sticking the number of
elements in the input on the end. At output time, the CU name will
appear in the linked object, so it matters a little more that it look
slightly less ugly: in conflicting cases, append an incrementing
integer, starting at 0.
This naming scheme is not very helpful, but it's hard to see what else
we can do. The input .o name may be the same. The input .a name is not
even visible to ctf_link, and even *that* might be the same, because
.a's can contain many members with the same name, all of which
participate in the link. All we really know is that the two have
distinct dictionaries with distinct types in them, and at least this way
they are all represented, any any symbols, variables etc referring to
those types are accurately stored.
(As a side-effect this also fixes a use-after-free and double-free when
errors are found during variable or symbol emission.)
Use the opportunity to prevent a couple of sources of problems, to wit
changing the active CU mappings when a link has already been done
(no effect on ld, which doesn't use CU mappings at all), and causing
multiple consecutive ctf_link's to have the same net effect as just
doing the last one (no effect on ld, which only ever does one
ctf_link) rather than having the links be a sort of half-incremental
not-really-intended mess.
libctf/ChangeLog:
PR libctf/29242
* ctf-impl.h (struct ctf_dict) [ctf_link_in_out]: New.
* ctf-dedup.c (ctf_dedup_emit_type): Set it.
* ctf-link.c (ctf_link_add_ctf_internal): Set the input
CU name uniquely when clashes are found.
(ctf_link_add): Document what repeated additions do.
(ctf_new_per_cu_name): New, come up with a consistent
name for a new per-CU dict.
(ctf_link_deduplicating): Use it.
(ctf_create_per_cu): Use it, and ctf_link_in_out, and set
ctf_link_in_out properly. Don't overwrite per-CU dicts with
per-CU dicts relating to different inputs.
(ctf_link_add_cu_mapping): Prevent per-CU mappings being set up
if we already have per-CU outputs.
(ctf_link_one_variable): Adjust ctf_link_per_cu call.
(ctf_link_deduplicating_one_symtypetab): Likewise.
(ctf_link_empty_outputs): New, delete all the ctf_link_outputs
and blank out ctf_link_in_out on the corresponding inputs.
(ctf_link): Clarify the effect of multiple ctf_link calls.
Empty ctf_link_outputs if it already exists rather than
having the old output leak into the new link. Fix a variable
name.
* testsuite/config/default.exp (AR): Add.
(OBJDUMP): Likewise.
* testsuite/libctf-regression/libctf-repeat-cu.exp: New test.
* testsuite/libctf-regression/libctf-repeat-cu*: Main program,
library, and expected results for the test.
