Today, GDB only allows a single displaced stepping operation to happen
per inferior at a time. There is a single displaced stepping buffer per
inferior, whose address is fixed (obtained with
gdbarch_displaced_step_location), managed by infrun.c.
In the case of the AMD ROCm target [1] (in the context of which this
work has been done), it is typical to have thousands of threads (or
waves, in SMT terminology) executing the same code, hitting the same
breakpoint (possibly conditional) and needing to to displaced step it at
the same time. The limitation of only one displaced step executing at a
any given time becomes a real bottleneck.
To fix this bottleneck, we want to make it possible for threads of a
same inferior to execute multiple displaced steps in parallel. This
patch builds the foundation for that.
In essence, this patch moves the task of preparing a displaced step and
cleaning up after to gdbarch functions. This allows using different
schemes for allocating and managing displaced stepping buffers for
different platforms. The gdbarch decides how to assign a buffer to a
thread that needs to execute a displaced step.
On the ROCm target, we are able to allocate one displaced stepping
buffer per thread, so a thread will never have to wait to execute a
displaced step.
On Linux, the entry point of the executable if used as the displaced
stepping buffer, since we assume that this code won't get used after
startup. From what I saw (I checked with a binary generated against
glibc and musl), on AMD64 we have enough space there to fit two
displaced stepping buffers. A subsequent patch makes AMD64/Linux use
two buffers.
In addition to having multiple displaced stepping buffers, there is also
the idea of sharing displaced stepping buffers between threads. Two
threads doing displaced steps for the same PC could use the same buffer
at the same time. Two threads stepping over the same instruction (same
opcode) at two different PCs may also be able to share a displaced
stepping buffer. This is an idea for future patches, but the
architecture built by this patch is made to allow this.
Now, the implementation details. The main part of this patch is moving
the responsibility of preparing and finishing a displaced step to the
gdbarch. Before this patch, preparing a displaced step is driven by the
displaced_step_prepare_throw function. It does some calls to the
gdbarch to do some low-level operations, but the high-level logic is
there. The steps are roughly:
- Ask the gdbarch for the displaced step buffer location
- Save the existing bytes in the displaced step buffer
- Ask the gdbarch to copy the instruction into the displaced step buffer
- Set the pc of the thread to the beginning of the displaced step buffer
Similarly, the "fixup" phase, executed after the instruction was
successfully single-stepped, is driven by the infrun code (function
displaced_step_finish). The steps are roughly:
- Restore the original bytes in the displaced stepping buffer
- Ask the gdbarch to fixup the instruction result (adjust the target's
registers or memory to do as if the instruction had been executed in
its original location)
The displaced_step_inferior_state::step_thread field indicates which
thread (if any) is currently using the displaced stepping buffer, so it
is used by displaced_step_prepare_throw to check if the displaced
stepping buffer is free to use or not.
This patch defers the whole task of preparing and cleaning up after a
displaced step to the gdbarch. Two new main gdbarch methods are added,
with the following semantics:
- gdbarch_displaced_step_prepare: Prepare for the given thread to
execute a displaced step of the instruction located at its current PC.
Upon return, everything should be ready for GDB to resume the thread
(with either a single step or continue, as indicated by
gdbarch_displaced_step_hw_singlestep) to make it displaced step the
instruction.
- gdbarch_displaced_step_finish: Called when the thread stopped after
having started a displaced step. Verify if the instruction was
executed, if so apply any fixup required to compensate for the fact
that the instruction was executed at a different place than its
original pc. Release any resources that were allocated for this
displaced step. Upon return, everything should be ready for GDB to
resume the thread in its "normal" code path.
The displaced_step_prepare_throw function now pretty much just offloads
to gdbarch_displaced_step_prepare and the displaced_step_finish function
offloads to gdbarch_displaced_step_finish.
The gdbarch_displaced_step_location method is now unnecessary, so is
removed. Indeed, the core of GDB doesn't know how many displaced step
buffers there are nor where they are.
To keep the existing behavior for existing architectures, the logic that
was previously implemented in infrun.c for preparing and finishing a
displaced step is moved to displaced-stepping.c, to the
displaced_step_buffer class. Architectures are modified to implement
the new gdbarch methods using this class. The behavior is not expected
to change.
The other important change (which arises from the above) is that the
core of GDB no longer prevents concurrent displaced steps. Before this
patch, start_step_over walks the global step over chain and tries to
initiate a step over (whether it is in-line or displaced). It follows
these rules:
- if an in-line step is in progress (in any inferior), don't start any
other step over
- if a displaced step is in progress for an inferior, don't start
another displaced step for that inferior
After starting a displaced step for a given inferior, it won't start
another displaced step for that inferior.
In the new code, start_step_over simply tries to initiate step overs for
all the threads in the list. But because threads may be added back to
the global list as it iterates the global list, trying to initiate step
overs, start_step_over now starts by stealing the global queue into a
local queue and iterates on the local queue. In the typical case, each
thread will either:
- have initiated a displaced step and be resumed
- have been added back by the global step over queue by
displaced_step_prepare_throw, because the gdbarch will have returned
that there aren't enough resources (i.e. buffers) to initiate a
displaced step for that thread
Lastly, if start_step_over initiates an in-line step, it stops
iterating, and moves back whatever remaining threads it had in its local
step over queue to the global step over queue.
Two other gdbarch methods are added, to handle some slightly annoying
corner cases. They feel awkwardly specific to these cases, but I don't
see any way around them:
- gdbarch_displaced_step_copy_insn_closure_by_addr: in
arm_pc_is_thumb, arm-tdep.c wants to get the closure for a given
buffer address.
- gdbarch_displaced_step_restore_all_in_ptid: when a process forks
(at least on Linux), the address space is copied. If some displaced
step buffers were in use at the time of the fork, we need to restore
the original bytes in the child's address space.
These two adjustments are also made in infrun.c:
- prepare_for_detach: there may be multiple threads doing displaced
steps when we detach, so wait until all of them are done
- handle_inferior_event: when we handle a fork event for a given
thread, it's possible that other threads are doing a displaced step at
the same time. Make sure to restore the displaced step buffer
contents in the child for them.
Simon Marchi [Fri, 4 Dec 2020 21:43:55 +0000 (16:43 -0500)]
gdb: move displaced stepping types to displaced-stepping.{h,c}
Move displaced-stepping related stuff unchanged to displaced-stepping.h
and displaced-stepping.c. This helps make the following patch a bit
smaller and easier to read.
Simon Marchi [Fri, 4 Dec 2020 21:43:54 +0000 (16:43 -0500)]
gdb: pass inferior to get_linux_inferior_data
Pass to get_linux_inferior_data the inferior for which we want to obtain
the linux-specific data, rather than assuming the current inferior.
This helps slightly reduce the diff in the upcoming main patch.
Update the sole caller to pass the current inferior.
gdb/ChangeLog:
* linux-tdep.c (get_linux_inferior_data): Add inferior
parameter.
(linux_vsyscall_range): Pass current inferior.
Simon Marchi [Fri, 4 Dec 2020 21:43:54 +0000 (16:43 -0500)]
gdb: introduce status enum for displaced step prepare/finish
This is a preparatory patch to reduce the size of the diff of the
upcoming main patch. It introduces enum types for the return values of
displaced step "prepare" and "finish" operations. I find that this
expresses better the intention of the code, rather than returning
arbitrary integer values (-1, 0 and 1) which are difficult to remember.
That makes the code easier to read.
I put the new enum types in a new displaced-stepping.h file, because I
introduce that file in a later patch anyway. Putting it there avoids
having to move it later.
There is one change in behavior for displaced_step_finish: it currently
returns 0 if the thread wasn't doing a displaced step and 1 if the
thread was doing a displaced step which was executed successfully. It
turns out that this distinction is not needed by any caller, so I've
merged these two cases into "_OK", rather than adding an extra
enumerator.
gdb/ChangeLog:
* infrun.c (displaced_step_prepare_throw): Change return type to
displaced_step_prepare_status.
(displaced_step_prepare): Likewise.
(displaced_step_finish): Change return type to
displaced_step_finish_status.
(resume_1): Adjust.
(stop_all_threads): Adjust.
* displaced-stepping.h: New file.
Simon Marchi [Fri, 4 Dec 2020 21:43:54 +0000 (16:43 -0500)]
gdb: rename displaced_step_fixup to displaced_step_finish
This is a preparatory patch to reduce a little bit the diff size of the
main patch later in this series. It renames the displaced_step_fixup
function in infrun.c to displaced_step_finish.
The rationale is to better differentiate the low and high level
operations.
We first have the low level operation of writing an instruction to a
displaced buffer, called "copy_insn". The mirror low level operation to
fix up the state after having executed the instruction is "fixup". The
high level operation of preparing a thread for a displaced step (which
includes doing the "copy_insn" and some more bookkeeping) is called
"prepare" (as in displaced_step_prepare). The mirror high level
operation to cleaning up after a displaced step (which includes doing
the "fixup" and some more bookkeeping) is currently also called "fixup"
(as in displaced_step_fixup), just like the low level operation.
I think that choosing a different name for the low and high level
cleanup operation makes it clearer, hence "finish".
Simon Marchi [Fri, 4 Dec 2020 21:43:53 +0000 (16:43 -0500)]
gdb: rename displaced_step_closure to displaced_step_copy_insn_closure
Since we're going to introduce other "displaced step" functions and
another kind of displaced step closure, make it clear that this is the
return type of the gdbarch_displaced_step_copy_insn function.
Simon Marchi [Fri, 4 Dec 2020 21:43:53 +0000 (16:43 -0500)]
gdb: rename things related to step over chains
Rename step_over_queue_head to global_thread_step_over_chain_head, to
make it more obvious when reading code that we are touching the global
queue. Rename all functions that operate on it to have "global" in
their name, to make it clear on which chain they operate on. Also, in a
subsequent patch, we'll need both global and non-global versions of
these functions, so it will be easier to do the distinction if they are
named properly.
Normalize the naming to use "chain" everywhere instead of sometimes
"queue", sometimes "chain".
I also reworded a few comments in gdbthread.h. They implied that the
step over chain is per-inferior, when in reality there is only one
global chain, not one per inferior, as far as I understand.
gdb/ChangeLog:
* gdbthread.h (thread_step_over_chain_enqueue): Rename to...
(global_thread_step_over_chain_enqueue): ... this. Update all
users.
(thread_step_over_chain_remove): Rename to...
(global_thread_step_over_chain_remove): ... this. Update all
users.
(thread_step_over_chain_next): Rename to...
(global_thread_step_over_chain_next): ... this. Update all
users.
* infrun.h (step_over_queue_head): Rename to...
(global_thread_step_over_chain_head): ... this. Update all
users.
* infrun.c (step_over_queue_head): Rename to...
(global_thread_step_over_chain_head): ... this. Update all
users.
* thread.c (step_over_chain_remove): Rename to...
(thread_step_over_chain_remove): ... this. Update all users.
(thread_step_over_chain_next): Rename to...
(global_thread_step_over_chain_next): ... this. Update all
users.
(thread_step_over_chain_enqueue): Rename to...
(global_thread_step_over_chain_enqueue): ... this. Update all
users.
(thread_step_over_chain_remove): Rename to...
(global_thread_step_over_chain_remove): ... this. Update all
users.
Simon Marchi [Fri, 4 Dec 2020 21:43:53 +0000 (16:43 -0500)]
gdb: get rid of get_displaced_stepping_state
Remove function get_displaced_stepping_state. When it was introduced,
inferiors' displaced stepping state was kept in a linked list in
infrun.c, so it was handy. Nowadays, the state is kept inside struct
inferior directly, so we can just access it directly instead.
gdb/ChangeLog:
* infrun.c (get_displaced_stepping_state): Remove, change
callers to access the field directly.
Simon Marchi [Fri, 4 Dec 2020 21:43:52 +0000 (16:43 -0500)]
gdb: restore displaced step buffer bytes when another thread forks
In handle_inferior_event, where we handle forks, we make sure to restore
the bytes of the displaced stepping buffer in the child's address
space. However, we only do it when the forking thread was the one
doing a displaced step. It could happen that a thread forks while
another one is doing a displaced step. In this case, we also need to
restore the bytes in the child.
Move the byte-restoring code outside of the condition that checks
whether the event thread was displaced stepping.
gdb/ChangeLog:
* infrun.c (handle_inferior_event): Restore displaced step
buffer bytes in child process when handling fork, even if fork
happened in another thread than the displaced-stepping one.
Simon Marchi [Fri, 4 Dec 2020 21:43:52 +0000 (16:43 -0500)]
gdb: clear inferior displaced stepping state and in-line step-over info on exec
When a process does an exec, all its program space is replaced with the
newly loaded executable. All non-main threads disappear and the main
thread starts executing at the entry point of the new executable.
Things can go wrong if a displaced step operation is in progress while
we process the exec event.
If the main thread is the one executing the displaced step: when that
thread (now executing in the new executable) stops somewhere (say, at a
breakpoint), displaced_step_fixup will run and clear up the state. We
will execute the "fixup" phase for the instruction we single-stepped in
the old program space. We are now in a completely different context,
so doing the fixup may corrupt the state.
If it is a non-main thread that is doing the displaced step: while
handling the exec event, GDB deletes the thread_info representing that
thread (since the thread doesn't exist in the inferior after the exec).
But inferior::displaced_step_state::step_thread will still point to it.
When handling events later, this condition, in displaced_step_fixup,
will likely never be true:
/* Was this event for the thread we displaced? */
if (displaced->step_thread != event_thread)
return 0;
... since displaced->step_thread points to a deleted thread (unless that
storage gets re-used for a new thread_info, but that wouldn't be good
either). This effectively makes the displaced stepping buffer occupied
for ever. When a thread in the new program space will want to do a
displaced step, it will wait for ever.
I think we simply need to reset the displaced stepping state of the
inferior on exec. Everything execution-related that existed before the
exec is now gone.
Similarly, if a thread does an in-line step over an exec syscall
instruction, nothing clears the in-line step over info when the event is
handled. So it the in-line step over info stays there indefinitely, and
things hang because we can never start another step over. To fix this,
I added a call to clear_step_over_info in infrun_inferior_execd.
Add a test with a program with two threads that does an exec. The test
includes the following axes:
- whether it's the leader thread or the other thread that does the exec.
- whether the exec'r and exec'd program have different text segment
addresses. This is to hopefully catch cases where the displaced
stepping info doesn't get reset, and GDB later tries to restore bytes
of the old address space in the new address space. If the mapped
addresses are different, we should get some memory error. This
happens without the patch applied:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true -ex "b main" -ex r -ex "b my_execve_syscall if 0" -ex "set displaced-stepping on"
...
Breakpoint 1, main (argc=1, argv=0x7fffffffde38) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.threads/step-over-exec.c:69
69 argv0 = argv[0];
Breakpoint 2 at 0x60133a: file /home/simark/src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 34.
(gdb) c
Continuing.
[New Thread 0x7ffff7c62640 (LWP 1455423)]
Leader going in exec.
Exec-ing /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd
[Thread 0x7ffff7c62640 (LWP 1455423) exited]
process 1455418 is executing new program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd
Error in re-setting breakpoint 2: Function "my_execve_syscall" not defined.
No unwaited-for children left.
(gdb) n
Single stepping until exit from function _start,
which has no line number information.
Cannot access memory at address 0x6010d2
(gdb)
- Whether displaced stepping is allowed or not, so that we end up
testing both displaced stepping and in-line stepping on arches that do
support displaced stepping (otherwise, it just tests in-line stepping
twice I suppose)
To be able to precisely put a breakpoint on the syscall instruction, I
added a small assembly file (lib/my-syscalls.S) that contains minimal
Linux syscall wrappers. I prefer that to the strategy used in
gdb.base/step-over-syscall.exp, which is to stepi into the glibc wrapper
until we find something that looks like a syscall instruction, I find
that more predictable.
gdb/ChangeLog:
* infrun.c (infrun_inferior_execd): New function.
(_initialize_infrun): Attach inferior_execd observer.
Simon Marchi [Fri, 4 Dec 2020 21:43:51 +0000 (16:43 -0500)]
gdb: add inferior_execd observable
I want to add another action (clearing displaced stepping state) that
happens when an inferior execs. I think it would be cleaner to have an
observer for this event, rather than have infrun know about each other
sub-component.
Replace the calls to solib_create_inferior_hook and
jit_inferior_created_hook in follow_exec by observers.
Tom de Vries [Fri, 4 Dec 2020 21:35:07 +0000 (22:35 +0100)]
[gdb] Fix heap-buffer-overflow in completion_tracker::build_completion_result
When building gdb with address sanitizer and running test-case
gdb.base/completion.exp, we run into:
...
==5743==ERROR: AddressSanitizer: heap-buffer-overflow on address \
0x60200025c02f at pc 0x000000cd9d64 bp 0x7fff3297da30 sp 0x7fff3297da28
READ of size 1 at 0x60200025c02f thread T0
#0 0xcd9d63 in completion_tracker::build_completion_result(char const*, \
int, int) gdb/completer.c:2258
...
0x60200025c02f is located 1 bytes to the left of 1-byte region \
[0x60200025c030,0x60200025c031)
...
This can be reproduced using just:
...
$ gdb
(gdb) p/d[TAB]
...
The problem is in this code in completion_tracker::build_completion_result:
...
bool completion_suppress_append
= (suppress_append_ws ()
|| match_list[0][strlen (match_list[0]) - 1] == ' ');
...
If strlen (match_list[0]) == 0, then we access match_list[0][-1].
Fix this by testing if the memory access is in bounds before doing the memory
access.
... to remove other typedefs that are no longer necessary now that gdb
uses C++.
I didn't remove absolutely every one -- I didn't touch the tdep files.
However, I removed many of them. In some cases, I removed an existing
different struct tag.
Simon Marchi [Fri, 4 Dec 2020 20:08:54 +0000 (15:08 -0500)]
gdb/testsuite: make declare_labels use better default label names
When using the single-element form of argument to declare_labels, the
generated label (in the assembly file) is of the format ".LlabelN",
where N is a number.
I propose making it use the name of the label by default. Calling:
declare_labels foo
will generate the ".LfooN" in the assembly file (again, where N is a
number). When debugging the output of the DWARF assembler, it makes it
easier to map labels to the source. Also, when defining the same label
twice by mistake in the Tcl code (like I d id), it's easier to track the
error from the message to the root cause:
-/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/implptrpiece/implptrpiece-dw.S:62: Error: symbol `.Llabel5' is already defined
+/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/implptrpiece/implptrpiece-dw.S:62: Error: symbol `.Lvar_label5' is already defined
This doesn't change anything for the test cases, it just makes the
assembly output a bit nicer.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (declare_labels): Use name as text if text is
not provided.
Tom de Vries [Fri, 4 Dec 2020 12:36:48 +0000 (13:36 +0100)]
[gdb/tdep] Handle static field in i386_16_byte_align_p
When running test-case on gdb.cp/many-args.exp with target board unix/-m32, I
run into:
...
(gdb) p check_val (ref_val, ref_val, ... , ref_val, ref_val)^M
$1 = false^M
(gdb) FAIL: gdb.cp/many-args.exp: check passing many structures
...
The test source contains struct ss:
...
typedef int v4si __attribute__ ((vector_size (16)));
struct ss
{
static v4si static_field;
unsigned char aa;
};
...
and i386_16_byte_align_p returns true for this type.
Fix this by skipping static fields in i386_16_byte_align_p.
Tom de Vries [Fri, 4 Dec 2020 12:36:48 +0000 (13:36 +0100)]
[gdb/testsuite] Fix control-flow in gdb.reverse/insn-reverse.exp
In gdb.reverse/insn-reverse.exp, we have loop containing a call to
gdb_test_multiple, which itself contains a break:
...
for {} {$count < 500} {incr count} {
...
gdb_test_multiple "x/i \$pc" "" {
...
break
}
...
On SLE-11 with:
...
$ runtest --version
Expect version is 5.44.1.11
Tcl version is 8.5
Framework version is 1.4.4
...
the break doesn't seem to have the effect of breaking out of the loop.
The break does have the effect of terminating evaluation of the expect clause,
which means we don't set insn_array, after which we run into:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.reverse/insn-reverse.exp.
ERROR: can't read "insn_array(5)": no such element in array
...
Tom de Vries [Fri, 4 Dec 2020 12:36:47 +0000 (13:36 +0100)]
[gdb/testsuite] Fix count usage in gdb.reverse/insn-reverse.exp
Consider the test-case gdb.reverse/insn-reverse.exp.
After the loop setting count, the valid entries in various arrays range from 0
to $count - 1 inclusive.
Then $count is decremented:
...
incr count -1
...
after which the valid entries range from 0 to $count inclusive.
The first subsequent loop handles that properly:
...
for {set i $count} {$i >= 0} {incr i -1} {
...
but the following loop does not, because it treats $count as exclusive bound:
...
for {set i 0} {$i < $count} {incr i} {
...
Fix this by removing the incr, and using $count - 1 as starting value in the
first loop.
gdb/testsuite/ChangeLog:
2020-12-04 Tom de Vries <tdevries@suse.de>
* gdb.reverse/insn-reverse.exp: Fix count handling.
Tom de Vries [Fri, 4 Dec 2020 12:36:47 +0000 (13:36 +0100)]
[gdb/testsuite] Handle SIGILL in gdb.reverse/insn-reverse.exp
Consider test-case gdb.reverse/insn-reverse.exp.
It runs a number of subtests, dependent on the architecture, f.i. for
x86_64 it runs subtests rdrand and rdseed.
For each subtest, it checks whether the subtest is supported and otherwise
bails out of that subtest.
However, there may be a problem with the support test or the information it
relies on, and if it states that a subtest is supported while it is actually
not, we may run into a SIGILL, as f.i. described in PR21166, which results in
tcl errors like this:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.reverse/insn-reverse.exp.
ERROR: can't read "insn_array(5)": no such element in array
...
We can emulate this by inserting a sigfpe in function rdrand in
insn-reverse-x86.c, like this:
...
volatile int a = 0; volatile int b = 1; volatile int c = b / a;
...
The problem is that the loop in the test-case attempts to stepi over of all
insn in rdrand, but because of the signal it will never get to the last insn.
Handle this by detecting that the stepi made no progress, and bailing out of
the loop.
Furthermore, make running of the subtests independent, such that a SIGILL in
subtest rdrand does not affect running of subtest rdseed.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-04 Tom de Vries <tdevries@suse.de>
* gdb.reverse/insn-reverse.c (test_nr): New var.
(usage, parse_args): New function.
(main): Call parse_args. Only run test for test_nr.
* gdb.reverse/insn-reverse.exp: Detect lack of progress in stepi loop
and bail out. Run subtests individually, using an inferior arg
specifying the subtest.
Andreas Krebbel [Fri, 4 Dec 2020 08:00:43 +0000 (09:00 +0100)]
IBM Z: Add risbgz and risbgnz extended mnemonics
These two extended mnemonics are documented in the Principles of
Operations manual but currently not supported by Binutils. They
provide aliases for already supported instructions with the zero flag
being set. The flag otherwise is mingled into one of the immediate
operands what makes asm code much harder to read.
opcodes/
* s390-opc.txt: Add risbgz and risbgnz.
* s390-opc.c (U6_26): New operand type.
(INSTR_RIE_RRUUU2, MASK_RIE_RRUUU2): New instruction format and
mask.
gas/
* testsuite/gas/s390/zarch-z10.s: Add tests for risbgz.
* testsuite/gas/s390/zarch-z10.d: Add regexp for risbgz.
* testsuite/gas/s390/zarch-zEC12.s: Add tests for risbgnz.
* testsuite/gas/s390/zarch-zEC12.d: Add regexp for risbgnz.
Alan Modra [Thu, 3 Dec 2020 05:40:37 +0000 (16:10 +1030)]
asan: readelf: memory leaks
This tidies some code used by readelf, hopefully fixing some
intermittent oss-fuzz bug reports that likely could only be reproduced
by feeding readelf two or more object files on the command line. The
second and subsequent file may see non-zero state in .bss variables,
and non-initial values in .data variables. This patch fixes some of
those, and moves some .data variables to .rodata.
* dwarf.c (frame_display_row): Do without static variable "sloc".
(cu_tu_indexes_read): Move to file scope.
(free_debug_memory): Reset it here, along with level_type_signed.
Free and clear a number of other static variables.
* readelf.c (arm_attr_public_tag <table>): Constify, updating..
(arm_attr_tag_*): ..all these uses.
(process_mips_specific): Free "rels" on error path.
Alan Modra [Wed, 2 Dec 2020 02:33:23 +0000 (13:03 +1030)]
PR26978, Inconsistency for strong foo@v1 and weak foo@@v1
Prior to this patch
ld -shared --version-script=pr26979.ver pr26978a.o pr26978b.o
results in
ld: pr26978b.o: in function `foo_v1':
(.text+0x0): multiple definition of `foo@v1'
ld: pr26978b.o:(*IND*+0x0): multiple definition of `foo'
while
ld -shared --version-script=pr26979.ver pr26978b.o pr26978a.o
results in no error, but some odd dynamic symbols.
... 0 NOTYPE GLOBAL DEFAULT 7 foo@v1
... 0 NOTYPE WEAK DEFAULT 7 foo@@v1
When linking an undecorated reference to foo against such a shared
library, ld complains about multiple definitions of foo@v1 while gold
creates a dynamic reference to foo@v1. That results in foo@v1 being
used at runtime.
While we could error in both cases, it is reasonable to say foo@v1 and
foo@@v1 are in fact the same symbol. (Same name, same version. The
only real difference is that foo@@v1 satisfies a reference to plain
foo, while foo@v1 does not.) Just as merging a weak undecorated sym
with a strong sym results in the strong sym prevailing, so should the
strong foo@v1 prevail. And since there is a definition that satisfies
plain foo, the foo@@v1 variety of dynamic symbol should be emitted at
the foo@v1 value. That makes the testcase that currently links
continue to produce a shared library, and that shared library can now
be used by both ld and gold with the same runtime behaviour as when
using gold with the odd dynamic symbol library.
bfd/
PR 26978
* elflink.c (_bfd_elf_add_default_symbol): Handle the case where
a new weak sym@@ver should be overridden by an existing sym@ver.
(elf_link_add_object_symbols): Don't _bfd_elf_add_default_symbol
for a new weak sym@ver when sym@@ver already exists.
* linker.c (link_action): Choose MIND for previous indirect,
current def, rather than MDEF.
(_bfd_generic_link_add_one_symbol <MIND>): Handle redefinition of
weak indirect symbol.
ld/
* testsuite/ld-elf/pr26978a.d,
* testsuite/ld-elf/pr26978a.s,
* testsuite/ld-elf/pr26978b.d,
* testsuite/ld-elf/pr26978b.s: New tests.
Simon Marchi [Thu, 3 Dec 2020 20:47:56 +0000 (15:47 -0500)]
gdb: fix logic of find_comp_unit and set_comp_unit
The logic in find_comp_unit and set_comp_unit is reversed. When the BFD
requires relocation, we want to put the comp_unit structure in the
map where the comp_unit objects are not shared, that is the one indexed
by objfile. If the BFD does not require relocation, then, we can share
a single comp_unit structure for all users of that BFD, so we want to
put it in the BFD-indexed map. The comments on top of
dwarf2_frame_bfd_data and dwarf2_frame_objfile_data make that clear.
Fix it by swapping the two in find_comp_unit and set_comp_unit.
I don't have a test for this, because I don't see how to write one in a
reasonable amount of time.
gdb/ChangeLog:
PR gdb/26876
* dwarf2/frame.c (find_comp_unit, set_comp_unit): Reverse use of
dwarf2_frame_bfd_data and dwarf2_frame_objfile_data.
Andreas Krebbel [Thu, 3 Dec 2020 15:31:15 +0000 (16:31 +0100)]
IBM Z: Add support for HLASM extended mnemonics
Add extended mnemonics used in the HLASM assembler. All of them are
just aliases for instructions we already support and help when
assembling code which was written for the HLASM assembler.
The HLASM mnemonics are documented here:
https://www.ibm.com/support/knowledgecenter/SSENW6_1.6.0/com.ibm.hlasm.v1r6.asm/asmr1023.pdf
See the 'Branching with extended mnemonic codes' chapter.
objdump will still print the existing mnemonics with the exception of
relative nop branches (i.e. conditional branches with an empty
condition code mask). Now we have jnop and jgnop which will be used
by objdump when possible.
The same change have been applied to the LLVM assembler:
https://reviews.llvm.org/D92185
Andrew Burgess [Mon, 23 Nov 2020 18:03:32 +0000 (18:03 +0000)]
gdb/riscv: rewrite target description validation, add rv32e support
This commit started as adding rv32e support to gdb. The rv32e
architecture is a cut-down rv32i, it only has 16 x-registers compared
to the usual 32, and an rv32e target should not have any floating
point registers.
In order to add this I needed to adjust the target description
validation checks that are performed from riscv_gdbarch_init, and I
finally got fed up with the current scheme of doing these checks and
rewrote this code.
Unfortunately the rv32e changes are currently mixed in with the
rewrite of the validation scheme. I could split these apart if anyone
is really interested in seeing these two ideas as separate patches.
The main idea behind this change is that where previously I tried to
have a purely data driven approach, a set of tables one for each
expected feature, and then a single generic function that would
validate a feature given a table, I have created a new class for each
feature. Each class has its own check member function which allows
the logic for how to check each feature to be different. I think the
new scheme is much easier to follow.
There are some other changes that I made to the validation code as
part of this commit.
I've relaxed some of the checks related to the floating point CSRs.
Previously the 3 CSRs fflags, frm, and fcsr all had to be present in
either the fpu feature or the csr feature. This requirement is now
relaxed, if the CSRs are not present then gdb will not reject the
target description. My thinking here is that there's no gdb
functionality that specifically requires these registers, and so, if a
target offers a description without these registers nothing else in
gdb should stop working.
And as part of the rv32e support targets now only have to provide the
first 16 x-registers and $pc. The second half of the x-registers (x16
-> x31) are now optional.
gdb/ChangeLog:
* arch/riscv.c: Include 'rv32e-xregs.c'.
(riscv_create_target_description): Update to handle rv32e.
* arch/riscv.h (struct riscv_gdbarch_features) <embedded>: New
member variable.
<operator==>: Update to account for new field.
<hash>: Likewise.
* features/Makefile (FEATURE_XMLFILES): Add riscv/rv32e-xregs.xml.
* features/riscv/rv32e-xregs.c: Generated.
* features/riscv/rv32e-xregs.xml: New file.
* riscv-tdep.c (riscv_debug_breakpoints): Move from later in the
file.
(riscv_debug_infcall): Likewise.
(riscv_debug_unwinder): Likewise.
(riscv_debug_gdbarch): Likewise.
(enum riscv_register_required_status): Delete.
(struct riscv_register_feature): Add constructor, delete default
constructor, copy, and assign constructors.
(struct riscv_register_feature::register_info) <required>: Delete.
<check>: Update comment and arguments.
(struct riscv_register_feature) <name>: Change to member function.
<prefer_first_name>: Delete.
<tdesc_feature>: New member function.
<registers>: Rename to...
<m_registers>: ...this.
<m_feature_name>: New member variable.
(riscv_register_feature::register_info::check): Update arguments.
(riscv_xreg_feature): Rewrite as class, create a single static
instance of the class.
(riscv_freg_feature): Likewise.
(riscv_virtual_feature): Likewise.
(riscv_csr_feature): Likewise.
(riscv_create_csr_aliases): Has become a member function inside
riscv_csr_feature class.
(riscv_abi_embedded): New function definition.
(riscv_register_name): Adjust to use new feature objects.
(struct riscv_call_info) <riscv_call_info>: Check for rv32e abi,
and adjust available argument registers.
(riscv_features_from_gdbarch_info): Check for EF_RISCV_RVE flag.
(riscv_check_tdesc_feature): Delete.
(riscv_tdesc_unknown_reg): Adjust to use new feature objects.
(riscv_gdbarch_init): Delete target description checking code, and
instead call to the new feature objects to perform the checks.
Reorder handling of no abi information case, allows small code
simplification.
(_initialize_riscv_tdep): Remove call, this is now done in the
riscv_csr_feature constructor.
* riscv-tdep.h (riscv_abi_embedded): Declare.
RISC-V GDB was changed to make use of the DECLARE_CSR_ALIAS macro to
define register aliases for some CSRs. Actually, only one alias was
created 'dscratch' as an alias for 'dscratch0'. All of the other
DECLARE_CSR_ALIAS lines (from include/opcode/riscv-opc.h) were
filtered out.
RISC-V: Support debug and float CSR as the unprivileged ones.
Changes were made to include/opcode/riscv-opc.h so that GDB no longer
created even the dscratch alias.
This caused a test failure in gdb.arch/riscv-tdesc-regs.exp.
In looking at how to address this failure I think that the best
strategy is, for now at least, to just remove the code that tries to
create aliases with DECLARE_CSR_ALIAS.
My thoughts are that:
1. At least some of the aliases are for CSRs where the register now
has a completely different use. Being able to reference the CSR
using a completely inappropriate name just seems confusing. This
was solved by the filtering added in the first commit referenced
above. But we certainly don't want to blindly add all aliases.
2. Names presented in a target description are always honoured, so
if a user has a legacy target then they should just start sending a
target description with their legacy register names in, this problem
is then solved.
3. It's easy enough to figure out which CSRs a target has with the
info registers command, so missing an alias shouldn't be a big
issue.
4. Allowing users to use names for registers that differ from the
names the target announces doesn't feel like a critical feature. If
in the future targets want multiple names for a register then maybe
we could/should extend target descriptions to allow the target to
send aliases as well as the primary name.... but that can wait for
another day.
So in this commit I remove the use of DECLARE_CSR_ALIAS, and remove
the test that was failing.
gdb/ChangeLog:
* riscv-tdep.c (riscv_create_csr_aliases): Remove use of
DECLARE_CSR_ALIAS.
Andrew Burgess [Tue, 24 Nov 2020 18:08:25 +0000 (18:08 +0000)]
gdb/riscv: place unknown csrs into the correct register groups
Unknown riscv CSRs should not be in the 'general' group, but should be
in the system and csr register groups.
To see this in action connect to QEMU, this target advertises two
registers dscratch and mucounteren which are unknown to GDB (these are
legacy CSRs). Before this commit these registers would show up in the
output of:
(gdb) info registers
....
dscratch Could not fetch register "dscratch"; remote failure reply 'E14'
mucounteren Could not fetch register "mucounteren"; remote failure reply 'E14'
Ignore the errors, this is just a QEMU annoyance, it advertises these
CSRs, but doesn't actually let GDB read them. These registers don't
show up in the output of either:
(gdb) info registers csr
(gdb) info registers system
After this commit this situation is reveresed, which makes more sense
to me.
gdb/ChangeLog:
* riscv-tdep.c (riscv_is_unknown_csr): New function,
implementation moved from riscv_register_reggroup_p.
(riscv_register_reggroup_p): Update group handling for unknown
CSRs.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-tdesc-regs.exp (get_expected_result): New proc,
update test to use this.
Search for DWZ files in debug-file-directories as well
When Debian (and Ubuntu) builds its binaries, it (still) doesn't use
dwz's "--relative" option. This causes their debuginfo files to
carry a .gnu_debugaltlink section containing a full pathname to the
DWZ alt debug file, like this:
$ readelf -wk /usr/bin/cat
Contents of the .gnu_debugaltlink section:
Separate debug info file: /usr/lib/debug/.dwz/x86_64-linux-gnu/coreutils.debug
Build-ID (0x14 bytes):
ee 76 5d 71 97 37 ce 46 99 44 32 bb e8 a9 1a ef 99 96 88 db
This usually works OK, because most of the debuginfo files installed
via apt will be present in /usr/lib/debug anyway. However, imagine
the following scenario:
- You are using /usr/bin/cat, it crashes on you and generates a
corefile.
- You don't want/need to "apt install" the debuginfo file for
coreutils from the repositories. Instead, you already have the
debuginfo files in a separate directory (e.g., $HOME/dbgsym).
- You start GDB and "set debug-file-directory $HOME/dbgsym/usr/lib/debug".
You then get the following message:
$ gdb -ex 'set debug-file-directory ./dbgsym/usr/lib/debug' -ex 'file /bin/cat' -ex 'core-file ./cat.core'
GNU gdb (Ubuntu 10.1-0ubuntu1) 10.1
...
Reading symbols from /bin/cat...
Reading symbols from /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id/bc/06d3bee37b8c7e67b31cb2689cb351102ae73b.debug...
could not find '.gnu_debugaltlink' file for /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id/bc/06d3bee37b8c7e67b31cb2689cb351102ae73b.debug
This error happens because GDB is trying to locate the build-id
link (inside /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id) for the
DWZ alt debug file, which doesn't exist. Arguably, this is a problem
with how dh_dwz works in Debian, and it's something I'm also planning
to tackle. But, back at the problem at hand.
Besides not being able to find the build-id link in the directory
mentioned above, GDB also tried to open the DWZ alt file using its
filename. The problem here is that, since we don't have the distro's
debuginfo installed, it can't find anything under /usr/lib/debug that
satisfies it.
It occurred to me that a good way to workaround this problem is to
actually try to locate the DWZ alt debug file inside the
debug-file-directories (that were likely provided by the user). So
this is what the proposed patch does.
The idea here is simple: get the filename extracted from the
.gnu_debugaltlink section, and manipulate it in order to replace the
initial part of the path (everything before "/.dwz/") by whatever
debug-file-directories the user might have provided.
I talked with Mark Wielaard and he agrees this is a sensible approach.
In fact, apparently this is something that eu-readelf also does.
I regtested this code, and no regressions were found.
* dwarf2/read.c (dwz_search_other_debugdirs): New function.
(dwarf2_get_dwz_file): Convert 'filename' to a
std::string. Use dwz_search_other_debugdirs to search for DWZ
files in the debug-file-directories provided by the user as well.
Tom Tromey [Wed, 2 Dec 2020 00:22:05 +0000 (17:22 -0700)]
Use new+delete for struct expression
In another series I'm working on, it is necessary to manage
"struct expression" with new and delete. Because the patch is
straightforward and could be extracted, I've done so here.
gdb/ChangeLog
2020-12-01 Tom Tromey <tom@tromey.com>
* parse.c (expr_builder::expr_builder): Initialize expout.
(expr_builder::release): Use expression::resize.
(expression::expression, expression::~expression)
(expression::resize): New methods.
(write_exp_elt): Use expression::resize.
(prefixify_expression): Update.
(increase_expout_size): Use expression::resize.
* expression.h (struct expression): Add constructor, destructor.
<resize>: New method.
(expression_up): Change type.
Simon Marchi [Tue, 1 Dec 2020 20:07:08 +0000 (15:07 -0500)]
gdb/testsuite: use foreach_with_prefix in gdb.threads/non-ldr-exc-*.exp
Replace the manual with_test_prefix in the do_test proc with using
foreach_with_prefix at the top-level. This helps reduce the indentation
level of the code a bit, and makes the test names in sync with the
variable names used in the code.
gdb/testsuite/ChangeLog:
* gdb.threads/non-ldr-exc-1.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-2.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-3.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-4.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
Simon Marchi [Tue, 1 Dec 2020 15:31:19 +0000 (10:31 -0500)]
gdb/testsuite: fix comment in gdb.threads/non-ldr-exit.exp
Maybe there's something I don't understand in that test, but the comment
seems wrong. It checks what happens when the non-leader thread does an
exit, not the leader.
Chungyi Chi [Tue, 1 Dec 2020 11:06:08 +0000 (11:06 +0000)]
gdbsupport/tdesc: print enum size attribute
According to gdb online docs[1], XML target description enum types
have both name and size attributes. Currently GDB does not print the
size attribute. This commit fixes this. This change will be visible
in the output of the command `maint print xml-tdesc`.
There are other bugs with the print of enum types in XML target
descriptions, the next commit will fix these and include a test that
covers this patch.
Nelson Chu [Fri, 20 Nov 2020 15:42:28 +0000 (23:42 +0800)]
RISC-V: Fix the order checking for Z* extension.
We have to check the first char of the Z* extensions, to make sure that
they follow the order of the standard extensions. But we can not have
the testcases for this patch, since we only support the zicsr and zifencei
so far, both of them are the sub extensions of i.
bfd/
* elfxx-riscv.c (riscv_parse_prefixed_ext): Use riscv_compare_subsets
to check the Z* extensions' order.
Nelson Chu [Fri, 20 Nov 2020 14:33:11 +0000 (22:33 +0800)]
RISC-V: Support to add implicit extensions for G.
G is a special case, consider the ISA spec github issue as follows,
https://github.com/riscv/riscv-isa-manual/issues/575
My understand is that - i, m, a, f and d extensions are not g's implicit
extensions, they are g's expansions. The zifencei is the implicit extension
of g, and so is zicsr, since it is implicited by f (or i2p1). However,
we add the g with the RISCV_UNKNOWN_VERSION to the subset list, and it
will not output to the arch string, it is only used to check what implicit
extensions are need to be added.
bfd/
* elfxx-riscv.c (riscv_parse_add_subset): Allow to add g with
RISCV_UNKNOWN_VERSION versions.
(riscv_parse_std_ext): Add g to the subset list, we only use it
to add the implicit extensions, but won't output it to arch string.
(riscv_parse_add_implicit_subsets): Add implicit zicsr and zifencei
for g extension.
(riscv_arch_str1): Do not output g to the arch string.
* elfxx-riscv.h (RISCV_UNKNOWN_VERSION): Moved to include/opcode/riscv.h.
gas/
* testsuite/gas/riscv/attribute-10.d: Updated.
* testsuite/gas/riscv/march-imply-g.d: New testcase for g.
* testsuite/gas/riscv/march-imply-unsupported.d: The zicsr and zifencei
are not supported in the ISA spec v2.2, so don't add and output them.
Nelson Chu [Fri, 20 Nov 2020 10:05:05 +0000 (18:05 +0800)]
RISC-V: Support to add implicit extensions.
We have to parse and add all arch string extensions at first, and then
start to add their implicit extensions. That means we can always add
arch string extensions at the end of the subset list, but we need to
search the right place to add their implicit extensions. For now we
follow the following rules to add the implicit extensions,
* Add zicsr and zifencei only when the i's version less than 2.1.
* Add d, f and zicsr when q is found.
* Add f and zicsr when d is found.
* Add zicsr when f is found.
Besides, we do not add the implicit extensions if they are already added
in the subset list, or we cannot find their default versions according to
the chosen ISA spec.
bfd/
* elfnn-riscv.c (riscv_merge_std_ext): Updated since
riscv_lookup_subset is changed.
* elfxx-riscv.c (riscv_ext_order): New Array used to compare the
extensions' order quickly.
(riscv_init_ext_order): New function. Init the riscv_ext_order
according to the riscv_supported_std_ext and parse_config[i].class
automatically.
(riscv_compare_subsets): New function. Similar to the strcmp, but
compare the subsets with the specific order.
(riscv_lookup_subset): Return TRUE and set `current` to the subset
if it is found. Otherwise, return FALSE and set `current` to the
place where we should insert the subset.
(riscv_add_implicit_subset): New function. Search the list first,
and then find the right place to add the implicit_subset.
(riscv_parse_add_subset): Since We have to add all arch string
extensions first, and then start to add their implicit extensions.
We can add arch string extensions in order by the original
riscv_add_subset, and then add the implicit subsets by the
riscv_add_implicit_subset. Besides, do not add the implicit
extensions if we failed to find their default versions.
(riscv_parse_std_ext): Updated.
(riscv_parse_add_implicit_subsets): New function. Add all implicit
extensions according to the arch string extensions.
(riscv_parse_subset): Call riscv_init_ext_order and
riscv_parse_add_implicit_subsets, before and after parsing the
arch string. Remove parts of the ISA conflict checking since
the implicit extensions are added.
* elfxx-riscv.h (riscv_lookup_subset): Updated.
gas/
* config/tc-riscv.c (riscv_subset_supports): Updated.
* testsuite/gas/riscv/march-imply-i2p0.d: New testcase. Need to
add the implicit zicsr and zifencei when i's version less than 2.1.
* testsuite/gas/riscv/march-imply-i2p1.d: New testcase.
* testsuite/gas/riscv/march-imply-d.d: Likewise.
* testsuite/gas/riscv/march-imply-f.d: Likewise.
* testsuite/gas/riscv/march-imply-q.d: Likewise.
* testsuite/gas/riscv/march-fail-rv32iq.l: Updated.
* testsuite/gas/riscv/march-fail-rv32id.d: Removed.
* testsuite/gas/riscv/march-fail-rv32id.l: Likewise.
* testsuite/gas/riscv/march-fail-rv64iq.d: Likewise.
* testsuite/gas/riscv/march-fail-rv64iq.l: Likewise.
Nelson Chu [Fri, 20 Nov 2020 09:26:04 +0000 (17:26 +0800)]
RISC-V: Improve the version parsing for arch string.
Keep the riscv_add_subset to do the same thing, and use a new
function, riscv_parse_add_subset, to cover most of the things
when parsing, including find the default versions for extensions,
and check whether the versions are valid. The version 0p0 should
be an invalid version, that is the mistake I made before. This
patch clarify the version rules as follows,
* We accept any version of extensions set by users, except 0p0.
* The non-standard x extensions must be set with versions in arch string.
* If user don't set the versions, or set 0p0 for the extensions, then try
to find the supported versions according to the chosen ISA spec.
Otherwise, report errors rather than output 0p0 for them.
Besides, we use as_bad rather than as_fatal to report more errors
for assembler.
bfd/
* elfxx-riscv.c (riscv_lookup_subset): Moved to front.
(riscv_add_subset): Likewise.
(riscv_release_subset_list): Likewise.
(riscv_parse_add_subset): New function. Find and check the
versions before adding them by riscv_add_subset.
(riscv_parsing_subset_version): Remove use_default_version
and change the version type from unsigned to int. Set the
versions to RISCV_UNKNOWN_VERSION if we can not find them
in the arch string.
(riscv_parse_std_ext): Updated.
(riscv_parse_prefixed_ext): Updated. Since we use as_bad
rather than as_fatal to report more errors, return NULL
string if the parsed end_of_version is NULL, too.
(riscv_parse_subset): Use a new boolean, no_conflict, to
report more errors when we have more than one ISA conflicts.
* elfxx-riscv.h (RISCV_DONT_CARE_VERSION): Changed to
RISCV_UNKNOWN_VERSION.
(riscv_lookup_subset_version): Removed.
(riscv_parse_subset_t): Updated.
gas/
* config/tc-riscv.c (riscv_get_default_ext_version):
Change the version type from unsigned to int.
(riscv_set_arch): Use as_bad rather than as_fatal to
report more errors.
* testsuite/gas/riscv/attribute-02.d: Updated since x must be
set with versions.
* testsuite/gas/riscv/attribute-03.d: Likewise.
* testsuite/gas/riscv/march-ok-two-nse.d: Likewise.
* testsuite/gas/riscv/attribute-09.d: zicsr wasn't supported
in the spec 2.2, so choose the newer spec.
* testsuite/gas/riscv/march-fail-base-01.l: Updated since as_bad.
* testsuite/gas/riscv/march-fail-base-02.l: Likewise.
* testsuite/gas/riscv/march-fail-order-std.l: Likewise.
* testsuite/gas/riscv/march-fail-order-x.l: Likewise.
* testsuite/gas/riscv/march-fail-order-z.l: Likewise.
* testsuite/gas/riscv/march-fail-porder.l: Likewise.
* testsuite/gas/riscv/march-fail-rv32ef.l: Likewise.
* testsuite/gas/riscv/march-fail-rv32id.l: Likewise.
* testsuite/gas/riscv/march-fail-rv32iq.l: Likewise.
* testsuite/gas/riscv/march-fail-rv64iq.l: Likewise.
* testsuite/gas/riscv/march-fail-single-char.l: Likewise.
* testsuite/gas/riscv/march-fail-unknown-std.l: Likewise.
* testsuite/gas/riscv/march-fail-unknown.l: Likewise.
* testsuite/gas/riscv/march-fail-uppercase.l: Likewise.
* testsuite/gas/riscv/march-fail-version.l: Likewise.
* testsuite/gas/riscv/march-fail-isa-spec.d: Likewise.
* testsuite/gas/riscv/march-fail-isa-spec.l: Likewise.
include/
* opcode/riscv.h (riscv_ext_version):
Change the version type from unsigned to int.
Nelson Chu [Fri, 20 Nov 2020 08:52:35 +0000 (16:52 +0800)]
RISC-V: Remove the unimplemented extensions.
Although spec had defined and ratified p, v and n extensions,
but we don't have any related implementaitons so far, so keep
them in the supported extension table looks weird. Remove them
until we have the related implementations.
opcodes/
* riscv-opc.c (riscv_ext_version_table): Remove the p, v, n
and their versions.
Nelson Chu [Sat, 21 Nov 2020 03:19:58 +0000 (11:19 +0800)]
RISC-V: Don't allow any uppercase letter in the arch string.
Although I cannot find any RISC-V specs said that uppercases are not
allowed in the arhc string, but seems like it is an established fact
both for GNU and LLVM. Therefore, we shouldn't allow the uppercases
for the non-standard x extensions, too.
bfd/
* elfxx-riscv.c (riscv_parse_subset): ISA string cannot contain
any uppercase letter.
Nelson Chu [Fri, 20 Nov 2020 06:45:32 +0000 (14:45 +0800)]
RISC-V: Minor cleanup and testcases improvement for arch string parser.
Re-indent the related codes, unify and improve the related error messages
and comments. Besies, also re-write the testcases to cover more cases.
bfd/
* elfxx-riscv.c: Re-indent codes, unify and improve the error
messages and comments.
(riscv_parse_prefixed_ext): Stop parsing the prefixed class
extensions if the class is RV_ISA_CLASS_UNKNOWN, I get internal
errors before adding this check for march-fail-porder* testcases.
(riscv_parse_subset): Move the rv32 with q checking in front.
* elfxx-riscv.h: Likewise.
gas/
(These are new testcases that cover more cases)
* testsuite/gas/riscv/march-fail-base-01.d: The first extension must
be e, i or g.
* testsuite/gas/riscv/march-fail-base-01.l: Likewise.
* testsuite/gas/riscv/march-fail-base-02.d: rv64e is an invalid base ISA.
* testsuite/gas/riscv/march-fail-base-02.l: Likewise.
* testsuite/gas/riscv/march-fail-order-std.d: Check orders of standard
extensions.
* testsuite/gas/riscv/march-fail-order-std.l: Likewise.
* testsuite/gas/riscv/march-fail-order-x.d: Check orders of prefixed
x extensions.
* testsuite/gas/riscv/march-fail-order-x.l: Likewise.
* testsuite/gas/riscv/march-fail-porder-x-std.d: Check orders when
standard and prefixed extensions are set at the same time.
* testsuite/gas/riscv/march-fail-porder-x-z.d: Likewise.
* testsuite/gas/riscv/march-fail-porder-z-std.d: Likewise.
* testsuite/gas/riscv/march-fail-porder.l: Likewise.
* testsuite/gas/riscv/march-fail-single-char-s.d: Only standard
extensions can use single char.
* testsuite/gas/riscv/march-fail-single-char-x.d: Likewise.
* testsuite/gas/riscv/march-fail-single-char-z.d: Likewise.
* testsuite/gas/riscv/march-fail-single-char.l: Likewise.
* testsuite/gas/riscv/march-fail-unknown-s.d: All extensions
should be known, except the non-standard x extensions.
* testsuite/gas/riscv/march-fail-unknown-std.d: Likewise.
* testsuite/gas/riscv/march-fail-unknown-std.l: Likewise.
* testsuite/gas/riscv/march-fail-unknown-z.d: Likewise.
* testsuite/gas/riscv/march-fail-unknown.l: Likewise.
* testsuite/gas/riscv/march-fail-uppercase-base.d: Do not
allow any uppercase in the arch string.
* testsuite/gas/riscv/march-fail-uppercase-std.d: Likewise.
* testsuite/gas/riscv/march-fail-uppercase-z.d: Likewise.
* testsuite/gas/riscv/march-fail-uppercase.l: Likewise.
* testsuite/gas/riscv/march-fail-version-x.d: Failed to set versions.
* testsuite/gas/riscv/march-fail-version-z.d: Likewise.
* testsuite/gas/riscv/march-fail-version.l: Likewise.
* testsuite/gas/riscv/march-fail-rv32ef.l: Updated.
* testsuite/gas/riscv/march-fail-rv32id.d: Need f-ext.
* testsuite/gas/riscv/march-fail-rv32iq.d: Should be rv64.
* testsuite/gas/riscv/march-fail-rv32iq.l: Likewise.
* testsuite/gas/riscv/march-fail-rv64iq.d: Need d-ext and f-ext.
* testsuite/gas/riscv/march-fail-rv64iq.l: Likewise.
H.J. Lu [Mon, 30 Nov 2020 13:21:51 +0000 (05:21 -0800)]
ld: Xfail PR ld/26936 test if not supported
Linkonce sections and comdat groups can be mixed only if comdat groups
have only a single member with matching symbol table entries. Xfail
ld/26936 test:
1. If comdat groups always have more than one member.
2. If symbol table entries in linkonce and comdat group don't match.
3. If the assembly source file is renamed.
PR ld/26936
* testsuite/ld-elf/pr26936.d: Xfail targets which don't support
mixing linkonce and comdat sections.
Tom de Vries [Mon, 30 Nov 2020 12:50:26 +0000 (13:50 +0100)]
[gdb/symtab] Fix gdb.base/vla-optimized-out.exp with clang
Consider test-case gdb.base/vla-optimized-out.exp, compiled using clang-10.
GDB fails to get the size of the vla a:
...
(gdb) p sizeof (a)^M
Cannot access memory at address 0x6^M
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of \
optimized out vla
...
The relevant DWARF looks like this: the variable a:
...
<2><12b>: Abbrev Number: 5 (DW_TAG_variable)
<12c> DW_AT_name : a
<132> DW_AT_type : <0x189>
...
has type:
...
<1><189>: Abbrev Number: 10 (DW_TAG_array_type)
<18a> DW_AT_type : <0x198>
<2><18e>: Abbrev Number: 11 (DW_TAG_subrange_type)
<18f> DW_AT_type : <0x19f>
<193> DW_AT_count : <0x117>
...
with the count attribute equated to the value of this artificial variable:
...
<2><117>: Abbrev Number: 4 (DW_TAG_variable)
<118> DW_AT_location : 10 byte block: 75 1 10 ff ff ff ff f 1a 9f \
(DW_OP_breg5 (rdi): 1;
DW_OP_constu: 4294967295;
DW_OP_and;
DW_OP_stack_value)
<123> DW_AT_name : __vla_expr0
<127> DW_AT_type : <0x182>
<12b> DW_AT_artificial : 1
...
The location description of the variable is terminated with DW_OP_stack_value,
which according to the DWARF spec means that "the DWARF expression represents
the actual value of the object, rather than its location".
However, in attr_to_dynamic_prop, we set is_reference to true:
...
baton->locexpr.is_reference = true;
...
and use it in dwarf2_evaluate_property to dereference the value of the DWARF
expression, which causes the access to memory at address 0x6.
Fix this by ignoring the baton->locexpr.is_reference == true setting if
the expression evaluation has ctx.location == DWARF_VALUE_STACK, such that we
get:
...
(gdb) p sizeof (a)^M
$2 = 6^M
(gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed size of \
optimized out vla
...
Tested on x86_64-linux, with gcc.
Tested the following test-cases (the ones mentioned in PR26905) on
x86_64-linux with clang-10:
- gdb.base/vla-optimized-out.exp
- gdb.base/vla-ptr.exp
- gdb.mi/mi-vla-c99
Tom de Vries [Mon, 16 Nov 2020 12:02:04 +0000 (13:02 +0100)]
[gdb/testsuite] Fix minimal encodings KPASSes
With current master I see a couple of KPASSes:
...
KPASS: gdb.ada/enum_idx_packed.exp: scenario=minimal: ptype small \
(PRMS minimal encodings)
...
KPASS: gdb.ada/mod_from_name.exp: scenario=minimal: print xp \
(PRMS minimal encodings)
KPASS: gdb.ada/pckd_arr_ren.exp: scenario=minimal: print var \
(PRMS minimal encodings)
...
The corresponding setup_kfail is called for everything before gnat 11.
However, the test-cases also PASS for me with gnat-4.8, gnat-7.5.0 and
gnat-8.4.0.
Fix the KPASSes by limiting the setup_kfail to gnat 9 and 10.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-11-16 Tom de Vries <tdevries@suse.de>
* gdb.ada/enum_idx_packed.exp: Limit setup_kfail to gnat 9 and 10.
* gdb.ada/mod_from_name.exp: Same.
* gdb.ada/pckd_arr_ren.exp: Same.
Tom de Vries [Mon, 16 Nov 2020 09:29:36 +0000 (10:29 +0100)]
[gdb] Don't return non-existing path in debuginfod_source_query
When setting env var DEBUGINFOD_URLS to " " and running the testsuite, we run
into these regressions:
...
FAIL: gdb.base/list-missing-source.exp: info source
FAIL: gdb.base/source-dir.exp: info source before setting directory search list
...
Setting var DEBUGINFOD_URLS to " " allows the debuginfod query function
debuginfod_source_query to get past its early exit.
The function debuginfod_source_query is documented as: "If the file is
successfully retrieved, its path on the local machine is stored in DESTNAME".
However, in case we get back -ENOENT from libdebuginfod, we still set
DESTNAME:
....
if (fd.get () < 0 && fd.get () != -ENOENT)
printf_filtered (_("Download failed: %s. Continuing without source file %ps.\n"),
safe_strerror (-fd.get ()),
styled_string (file_name_style.style (), srcpath));
else
*destname = make_unique_xstrdup (srcpath);
return fd;
...
Fix this by making debuginfod_source_query fit it's documentation and only
setting DESTNAME when successfully retrieving a file. Likewise in
debuginfod_debuginfo_query.
gdb/ChangeLog:
2020-11-16 Tom de Vries <tdevries@suse.de>
* debuginfod-support.c (debuginfod_source_query)
(debuginfod_debuginfo_query): Only set DESTNAME if successful.
Tom Tromey [Mon, 30 Nov 2020 08:37:10 +0000 (01:37 -0700)]
Remove per-language op_name functions
enum exp_opcode is created from all the .def files, but then each
language is required to implement its own op_name function to turn an
enum value to a string. This seemed over-complicated to me, and this
patch removes the per-language functions in favor of simply using the
.def names for all languages. Note that op_name is only used for
dumping expressions, which is a maintainer/debug feature.
Furthermore, I don't think there was any case where the .def name and
the string name differed.
gdb/ChangeLog
2020-11-30 Tom Tromey <tom@tromey.com>
Tom Tromey [Mon, 30 Nov 2020 08:24:57 +0000 (01:24 -0700)]
Remove some dead code from evaluate_subexp_standard
I noticed that in the OP_ARRAY case in evaluate_subexp_standard,
"index_pc" is read but never set. This dead code then guards the only
call to init_array_element, so this can be removed as well.
gdb/ChangeLog
2020-11-30 Tom Tromey <tom@tromey.com>
H.J. Lu [Sun, 29 Nov 2020 13:55:23 +0000 (05:55 -0800)]
gold: Get linkonce/comdate sections for debugging sections
When relocating debug sections, get the section index for the linkonce
section. Since symbols referenced in debugging sections can be defined
a single comdat section with a different section name, also check the
single comdat section.
PR gold/26937
* object.cc (Sized_relobj_file::map_to_kept_section): Get the
section index for linkonce section. Also check the single
comdat section.
* testsuite/Makefile.am (check_SCRIPTS): Add pr26936.sh.
(check_DATA): Add pr26936a.stdout and pr26936b.stdout.
(MOSTLYCLEANFILES): Add pr26936a and pr26936b.
(pr26936a.stdout): New target.
(pr26936a): Likewise.
(pr26936b.stdout): Likewise.
(pr26936b): Likewise.
(pr26936a.o): Likewise.
(pr26936b.o): Likewise.
(pr26936c.o): Likewise.
(pr26936d.o): Likewise.
* testsuite/Makefile.in: Regenerated.
* testsuite/pr26936.sh: New file.
* testsuite/pr26936a.s: Likewise.
* testsuite/pr26936b.s: Likewise.
* testsuite/pr26936c.s: Likewise.
* testsuite/pr26936d.s: Likewise.
Alex Richardson [Sat, 28 Nov 2020 16:45:06 +0000 (11:45 -0500)]
GDB: Fix detection of ELF support when configuring with -Werror=implicit-function-declaration
I am getting
I'm sorry, Dave, I can't do that. Symbol format `elf64-littleriscv' unknown.
errors after updating from GDB 8.3 to 10. Bisecting showed that since
commit 1ff6de031241 ("bfd, ld: add CTF section linking"), bfd.h depends
on strncmp() being present, so configuring with
-Werror=implicit-function-declaration results in the check for ELF
support in BFD failing:
.../gdb/gdb/../bfd/elf-bfd.h: In function 'bfd_section_is_ctf':
.../gdb/gdb/../bfd/elf-bfd.h:3086:10: error: implicit declaration of function 'strncmp' [-Werror=implicit-function-declaration]
return strncmp (name, ".ctf", 4) == 0 && (name[4] == 0 || name[4] == '.');
gdb/ChangeLog:
* acincludde.m4 (GDB_AC_CHECK_BFD): Include string.h in the test
program.
Section ordering is important for _bfd_elf_map_sections_to_segments
and assign_file_positions_for_load_sections, which are only prepared
to handle sections in increasing LMA order. When zero size sections
are involved it is possible to have multiple sections at the same LMA.
In that case the zero size sections must sort before any non-zero size
sections regardless of their types.
bfd/
PR 26907
* elf.c (elf_sort_sections): Don't sort zero size !load sections
after load sections.
ld/
* testsuite/ld-elf/pr26907.ld,
* testsuite/ld-elf/pr26907.s,
* testsuite/ld-elf/pr26907.d: New test.
gdb: improve command completion for 'print', 'x', and 'display'
A potential use of an uninitialised variable was introduced. This is
fixed in this commit.
Previously when analysing /FMT strings for tab completion we
considered two possibilities, either the user has typed '/', or the
user has typed '/' followed by an alpha-numeric character, as these
are the only valid FMT string characters.
This meant that if the user type, for example '/@' and then tried to
tab complete gdb would use an uninitialised variable.
Currently only the first character after the '/' is checked to see if
it is alpha-numeric, so if a user typed '/x@@' then gdb would be happy
to treat this as a FMT string.
Given the goal of this change was primarily to allow tab completion of
symbols later in the command when a /FMT was used then I decided to
just make the /FMT skipping less smart. Now any characters after the
'/' up to the first white space, will be treated as a FMT string.
gdb/ChangeLog:
* printcmd.c (skip_over_slash_fmt): Reorder code to ensure in_fmt
is always initialized.
The ".persistent" section is for data that should be initialized during
load, but not during application reset.
The ".noinit" section is for data that should not be initialized during
load or application reset.
Targets utilizing the elf.sc linker script template can define
HAVE_{NOINIT,PERSISTENT}=yes to include the .noinit or .persistent
output sections in the generated linker script.
Targets with existing support for .noinit did not handle unique
.noinit.* and .gnu.linkonce.n.* sections the .noinit output section,
this patch also fixes that.
* testsuite/gas/elf/elf.exp: Run new tests.
* testsuite/gas/elf/section25.d: New test.
* testsuite/gas/elf/section25.s: New test.
* testsuite/gas/elf/section26.d: New test.
* testsuite/gas/elf/section26.s: New test.
ld/ChangeLog:
* emulparams/armelf.sh (OTHER_SECTIONS): Remove .noinit section
definition.
Define HAVE_{NOINIT,PERSISTENT}=yes.
* scripttempl/avr.sc (.noinit): Add .noinit.* and .gnu.linkonce.n.*
input section wildcard patterns.
* scripttempl/elf.sc: Define .noinit and .persistent sections when
HAVE_NOINIT or HAVE_PERSISTENT are defined to "yes".
* scripttempl/elf32msp430.sc (.noinit): Add .noinit.* and
.gnu.linkonce.n.*. input section wildcard patterns.
(.persistent): Add .persistent.* and
.gnu.linkonce.p.*. input section wildcard patterns.
* scripttempl/elfarcv2.sc (.noinit): Add .noinit.* and
.gnu.linkonce.n.*. input section wildcard patterns.
* scripttempl/pru.sc: Likewise.
* testsuite/ld-elf/noinit-sections-1.d: New test.
* testsuite/ld-elf/noinit-sections-2.d: New test.
* testsuite/ld-elf/noinit-sections-2.l: New test.
* testsuite/ld-elf/noinit-sections.s: New test.
* testsuite/ld-elf/persistent-sections-1.d: New test.
* testsuite/ld-elf/persistent-sections-2.d: New test.
* testsuite/ld-elf/persistent-sections-2.l: New test.
* testsuite/ld-elf/persistent-sections.s: New test.
gdb/aarch64: Add named flags for FPCR and FPSR registers
This patch updates FPCR (Floating-point Control Register) and FPSR
(Floating-point Status Register) named fields in AArch64. For detailed
description of named register FPCR and FPSR bit fields see [1] and [2].
Please not that bit fields FIZ, AH and NEP (bits 0, 1 and 2 respectively) in
FPCR are defined starting from Armv8.7 architecture.
Alan Modra [Thu, 26 Nov 2020 07:15:26 +0000 (17:45 +1030)]
PR26936 testsuite fixes
Many targets fail this test due to -z noseparate-code not being
supported, or _start not being the proper entry symbol, or "as -g"
something other than "generate debug".
PR 26936
* testsuite/ld-elf/pr26936.d: Pass --gen-debug to gas rather than -g.
Only run when -shared -z options are supported.
* testsuite/ld-elf/pr26936b.s: Define more entry symbols.
Nick Alcock [Mon, 23 Nov 2020 21:30:24 +0000 (21:30 +0000)]
binutils: readelf: support CTF dicts with non-native-endian symtabs
Now we have a way to tell libctf what the endianness of the symtab is,
get readelf to use it. (objdump doesn't need to do so, nor does ld,
because they both use BFD-aware mechanisms to open CTF dicts, so libctf
can automatically figure the symtab endianness out.)
binutils/ChangeLog
2020-11-23 Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Mon, 23 Nov 2020 21:17:44 +0000 (21:17 +0000)]
libctf, include: support foreign-endianness symtabs with CTF
The CTF symbol lookup machinery added recently has one deficit: it
assumes the symtab is in the machine's native endianness. This is
always true when the linker is writing out symtabs (because cross
linkers byteswap symbols only after libctf has been called on them), but
may be untrue in the cross case when the linker or another tool
(objdump, etc) is reading them.
Unfortunately the easy way to model this to the caller, as an endianness
field in the ctf_sect_t, is precluded because doing so would change the
size of the ctf_sect_t, which would be an ABI break. So, instead, allow
the endianness of the symtab to be set after open time, by calling one
of the two new API functions ctf_symsect_endianness (for ctf_dict_t's)
or ctf_arc_symsect_endianness (for entire ctf_archive_t's). libctf
calls these functions automatically for objects opened via any of the
BFD-aware mechanisms (ctf_bfdopen, ctf_bfdopen_ctfsect, ctf_fdopen,
ctf_open, or ctf_arc_open), but the various mechanisms that just take
raw ctf_sect_t's will assume the symtab is in native endianness and need
a later call to ctf_*symsect_endianness to adjust it if needed. (This
call is basically free if the endianness is actually native: it only
costs anything if the symtab endianness was previously guessed wrong,
and there is a symtab, and we are using it directly rather than using
symtab indexing.)
Obviously, calling ctf_lookup_by_symbol or ctf_symbol_next before the
symtab endianness is correctly set will probably give wrong answers --
but you can set it at any time as long as it is before then.
include/ChangeLog
2020-11-23 Nick Alcock <nick.alcock@oracle.com>
* ctf-api.h: Style nit: remove () on function names in comments.
(ctf_sect_t): Mention endianness concerns.
(ctf_symsect_endianness): New declaration.
(ctf_arc_symsect_endianness): Likewise.
libctf/ChangeLog
2020-11-23 Nick Alcock <nick.alcock@oracle.com>
* ctf-impl.h (ctf_dict_t) <ctf_symtab_little_endian>: New.
(struct ctf_archive_internal) <ctfi_symsect_little_endian>: Likewise.
* ctf-create.c (ctf_serialize): Adjust for new field.
* ctf-open.c (init_symtab): Note the semantics of repeated calls.
(ctf_symsect_endianness): New.
(ctf_bufopen_internal): Set ctf_symtab_little_endian suitably for
the native endianness.
(_Static_assert): Moved...
(swap_thing): ... with this...
* swap.h: ... to here.
* ctf-util.c (ctf_elf32_to_link_sym): Use it, byteswapping the
Elf32_Sym if the ctf_symtab_little_endian demands it.
(ctf_elf64_to_link_sym): Likewise swap the Elf64_Sym if needed.
* ctf-archive.c (ctf_arc_symsect_endianness): New, set the
endianness of the symtab used by the dicts in an archive.
(ctf_archive_iter_internal): Initialize to unknown (assumed native,
do not call ctf_symsect_endianness).
(ctf_dict_open_by_offset): Call ctf_symsect_endianness if need be.
(ctf_dict_open_internal): Propagate the endianness down.
(ctf_dict_open_sections): Likewise.
* ctf-open-bfd.c (ctf_bfdopen_ctfsect): Get the endianness from the
struct bfd and pass it down to the archive.
* libctf.ver: Add ctf_symsect_endianness and
ctf_arc_symsect_endianness.
Tom Tromey [Tue, 24 Nov 2020 18:50:54 +0000 (11:50 -0700)]
Do not include parser-defs.h from c-lang.h
While working on another series, I noticed that c-lang.h does not need
to include parser-defs.h. This patch makes this change, and fixes up
the two .c files that needed this include. Tested by rebuilding.
gdb/ChangeLog
2020-11-25 Tom Tromey <tom@tromey.com>
* d-lang.c: Include parser-defs.h.
* rust-lang.c: Include parser-defs.h.
* c-lang.h: Do not include parser-defs.h.
Alan Modra [Tue, 24 Nov 2020 13:11:31 +0000 (23:41 +1030)]
Duplicate output sections in scripts
Previously, ld merged duplicate output sections if such existed in
scripts, except for those with a constraint of SPECIAL. This makes
scripts with duplicate output section statements create duplicate
output sections in the linker output file.
* ldlang.c (lang_output_section_statement_lookup): Change "create"
parameter to a tristate, if 2 then always create a new output
section statement. Update all callers, with
lang_enter_output_section_statement using "2".
(map_input_to_output_sections): Don't ignore SPECIAL constraint
here.
* ldlang.h (lang_output_section_statement_type): Update prototype.
(lang_output_section_find): Update.
Alan Modra [Mon, 23 Nov 2020 22:15:33 +0000 (08:45 +1030)]
gas output_file_close error message
Seen on arm-elf, where ELFOSABI_ARM is set too late to get a warning
when processing ifunc related directives on their source line.
../gas/as-new ifunc.s -o tmpdir/ifunc.o
../gas/as-new: symbol type STT_GNU_IFUNC is supported only by GNU and FreeBSD targets
ifunc.s: Assembler messages:
ifunc.s: Fatal error: can't close tmpdir/ifunc.o: sorry, cannot handle this file
This patch doesn't fix the real underlying problem, just the late
error message where "can't close" is a misdirection in this case.
projects / thirdparty / binutils-gdb.git / log
