gas/
* gen-sframe.c (sframe_set_version): Use ATTRIBUTE_UNUSED
consistently.
(output_sframe): Likewise.
(sframe_set_fre_info): Remove the usage of ATTRIBUTE_UNUSED.
I happened across adjust_type_signedness, which may be used to modify
a type when printing an Ada value. Modifying a type like this is a
bad idea -- they should normally be considered immutable. Removing
this function still passes both the dejagnu and internal AdaCore
tests, though, so this patch drops it.
As this was reviewed internally, and only affect Ada, I am checking it
in.
Callers which want to make further parsing attempts at the buffer passed
to the function need to be aware that due to the potential of string
concatenation the input buffer may be altered in ways beyond what can be
undone by putting back at *input_line_pointer the character that the
function returns.
This reverts the code change done by 100f993c53 ("x86: Check
unbalanced braces in memory reference"), which wrongly identified
e87fb6a6d0 ("x86/gas: support quoted address scale factor in AT&T
syntax") as the root cause of PR gas/30248. (The testcase is left in
place, no matter that it's at best marginally useful in that shape.)
The problem instead is that parse_register() alters the string handed to
it, thus breaking valid assumptions in subsequent parsing code. Since
the function's behavior is a result of get_symbol_name()'s, make a copy
of the incoming string before invoking that function.
Like for parse_real_register() follow the model of strtol() et al: input
string is const-qualified to signal that the string isn't altered, but
the returned "end" pointer is not const-qualified, requiring const to be
cast away (which generally is a bad idea, but the alternative would
again be more convoluted code).
Follow the model of strtol() et al - input string is const-qualified to
signal that the string isn't altered, but the returned "end" pointer is
not const-qualified, requiring const to be cast away (which generally is
a bad idea, but the alternative would be more convoluted code).
PowerPC supports two 128-bit floating point formats, the IBM long double
and IEEE 128-bit float. The issue is the DWARF information does not
distinguish between the two. There have been proposals of how to extend
the DWARF information as discussed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
but has not been fully implemented.
GCC introduced the _Float128 internal type as a work around for the issue.
The workaround is not transparent to GDB. The internal _Float128 type
name is printed rather then the user specified long double type. This
patch adds a new gdbarch method to allow PowerPC to detect the GCC
workaround. The workaround checks for "_Float128" name when reading the
base typedef from the die_info. If the workaround is detected, the type
and format fields from the _Float128 typedef are copied to the long
double typedef. The same is done for the complex long double typedef.
This patch fixes 74 regression test failures in
gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
default on GCC. It fixes one regression test failure in
gdb.base/complex-parts.exp.
The patch has been tested on Power 10 where GCC defaults to IEEE Float
128-bit and on Power 10 where GCC defaults to the IBM 128-bit float. The
patch as also been tested on X86-64 with no new regression failures.
This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188
Current flow:
1) Scan any mapping symbol less than this instruciton.
2) If not found, did a backward search.
The flow seems not big issue, let run an example here:
$x:
0x0 a <--- Found at step 1
0x4 b <--- Not found in step 1, but found at step 2
0x8 c <--- Not found in step 1, but found at step 2
$d
0x12 .word 1234 <-- Found at step 1
The instruciton didn't have the same address with mapping symbol will
still did backward search again and again.
So the new flow is:
1) Use the last mapping symbol status if the address is still within the range
of the current mapping symbol.
2) Scan any mapping symbol less than this instruciton.
3) If not found, did a backward search.
4) If a proper mapping symbol is found in either step 2 or 3, find its boundary,
and cache that.
Use the same example to run the new flow again:
$x:
0x0 a <--- Found at step 2, the boundary is 0x12
0x4 b <--- Cache hit at step 1, within the boundary.
0x8 c <--- Cache hit at step 1, within the boundary.
$d
0x12 .word 1234 <-- Found at step 2, the boundary is the end of section.
The disassemble time of the test cases has been reduced from ~20 minutes to ~4
seconds.
opcode/ChangeLog
PR 30282
* riscv-dis.c (last_map_symbol_boundary): New.
(last_map_state): New.
(last_map_section): New.
(riscv_search_mapping_symbol): Cache the result of latest
mapping symbol.
We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
Some of these functions have versions. For example,
% nm -D /lib64/gprofng/libgp-collector.so | grep thread_create@ | sort
000000000004b420 T pthread_create@GLIBC_2.34
000000000004b490 T pthread_create@GLIBC_2.17
000000000004b500 T pthread_create@GLIBC_2.2.5
000000000004b570 T pthread_create@GLIBC_2.1
000000000004b5e0 T pthread_create@GLIBC_2.0
Our library does not set the default version for symbols.
This is correct because we don't know which libC will be used.
gcc and g++ links differently the version symbols when the default version is
not set. c-linker is using our pthread_create@GLIBC_2.34 and c++-linker is using
our pthread_create@GLIBC_2.0 by default.
The current implementation of the interposed functions is:
If we are in our pthread_create@GLIBC_<NN>,
we use dlvsym (dlflag, "pthread_create", "GLIBC_<NN>") to find and call
the same function from libC.
In the test from PR 30360, pthread_create@GLIBC_2.0 is not in the current libC.
We need to call the default version symbol from libC.
gprofng/ChangeLog
2023-04-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30360
* libcollector/iotrace.c: Find and call a default libC version symbol.
* libcollector/dispatcher.c: Likewise.
* libcollector/iotrace.c: Likewise.
* libcollector/linetrace.c: Likewise.
* libcollector/mmaptrace.c: Likewise.
* libcollector/synctrace.c: Likewise.
* libcollector/collector.h (REAL_DCL): Remove an unused argument.
This patch addresses bugzilla 29521:
Bug 29521 - [docs] man pages are not in the release tarball
The dependence on help2man to create the man pages has been eliminated.
All man pages are now written in Texinfo. Texi2pod and pod2man are used
to generate the man pages from the source.
The user guide has been significantly expanded. It also includes all
the man pages. These are formatted appropriately in the INFO, PDF, and
HTML formats.
The index in the user guide has been enhanced to include an overview
of all options and commands that have been documented so far.
The work on the documentation has not been completed, but this is
a significant step forward.
gprofng/ChangeLog
2023-04-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/29521
* doc/Makefile.am: Build documentation.
* doc/gprofng.texi: Update documentation.
* doc/version.texi: Likewise.
* src/Makefile.am: Move the man pages generation to doc/Makefile.am.
* gp-display-html/Makefile.am: Likewise.
* doc/gp-archive.texi: New file.
* doc/gp-collect-app.texi: New file.
* doc/gp-display-html.texi: New file.
* doc/gp-display-src.texi: New file.
* doc/gp-display-text.texi: New file.
* doc/gp-macros.texi: New file.
* doc/gprofng_ug.texi: New file.
* doc/Makefile.in: Rebuild.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in" Rebuild.
I noticed some unnecessary casts to LONGEST in ada-lang.c. This patch
removes the ones I think are very clearly not needed. I'm checking
this in as obvious.
Prior to this patch, it's not possible for GDB to debug GPU code in fork
children or after an exec. The amd-dbgapi target attaches to processes
when an inferior appears due to a "run" or "attach" command, but not
after a fork or exec. This patch adds support for that, such that it's
possible to for an inferior to fork and for GDB to debug the GPU code in
the child.
To achieve that, use the inferior_forked and inferior_execd observers.
In the case of fork, we have nothing to do if `child_inf` is nullptr,
meaning that GDB won't debug the child. We also don't attach if the
inferior has vforked. We are already attached to the parent's address
space, which is shared with the child, so trying to attach would cause
problems. And anyway, the inferior can't do anything other than exec or
exit, it certainly won't start GPU kernels before exec'ing.
In the case of exec, we detach from the exec'ing inferior and attach to
the following inferior. This works regardless of whether they are the
same or not. If they are the same, meaning the execution continues in
the existing inferior, we need to do a detach/attach anyway, as
amd-dbgapi needs to be aware of the new address space created by the
exec.
Note that we use observers and not target_ops::follow_{fork,exec} here.
When the amd-dbgapi target is compiled in, it will attach (in the
amd_dbgapi_process_attach sense, not the ptrace sense) to native
inferiors when they appear, but won't push itself on the inferior's
target stack just yet. It only pushes itself if the inferior
initializes the ROCm runtime. So, if a non-GPU-using inferior calls
fork, an amd_dbgapi_target::follow_fork method would not get called.
Same for exec. A previous version of the code had the amd-dbgapi target
pushed all the time, in which case we could use the target methods. But
we prefer having the target pushed only when necessary, it's less
intrusive when doing native debugging that doesn't involve the GPU.
Change-Id: I5819c151c371120da8bab2fa9cbfa8769ba1d6f9
Reviewed-By: Pedro Alves <pedro@palves.net>
The problem explained and fixed in the previous patch could have also
been fixed by this patch. But I think it's good change anyhow, that
could prevent future bugs, so here it is.
fetch_inferior_event switches to an arbitrary (in practice, the first) inferior
of the process target of the inferior used to fetch the event. The idea is
that the event handling code will need to do some target calls, so we want to
switch to an inferior that has target target.
However, you can have two inferiors that share a process target, but with one
inferior having an additional target on top:
inf 1 inf 2
----- -----
another target
process target process target
exec exec
Let's say inferior 2 is selected by do_target_wait and returns an event that is
really synthetized by "another target". This "another target" could be a
thread or record stratum target (in the case explained by the previous patch,
it was the arch stratum target, but it's because the amd-dbgapi abuses the arch
layer). fetch_inferior_event will then switch to the first inferior with
"process target", so inferior 1. handle_signal_stop then tries to fetch the
thread's registers:
ecs->event_thread->set_stop_pc
(regcache_read_pc (get_thread_regcache (ecs->event_thread)));
This will try to get the thread's register by calling into the current target
stack, the stack of inferior 1. This is problematic because "another target"
might have a special fetch_registers implementation.
I think it would be a good idea to switch to the inferior for which the
even was reported, not just some inferior of the same process target.
This will ensure that any target call done before we eventually call
context_switch will be done on the full target stack that reported the
event.
Not all events are associated to an inferior though. For instance,
TARGET_WAITKIND_NO_RESUMED. In those cases, some targets return
null_ptid, some return minus_one_ptid (ideally the expected return value
should be clearly defined / documented). So, if the ptid returned is
either of these, switch to an arbitrary inferior with that process
target, as before.
Change-Id: I1ffc8c1095125ab591d0dc79ea40025b1d7454af
Reviewed-By: Pedro Alves <pedro@palves.net>
With the following patch, which teaches the amd-dbgapi target to handle
inferiors that fork, we end up with target stacks in the following
state, when an inferior that does not use the GPU forks an inferior that
eventually uses the GPU.
inf 1 inf 2
----- -----
amd-dbgapi
linux-nat linux-nat
exec exec
When a GPU thread from inferior 2 hits a breakpoint, the following
sequence of events would happen, if it was not for the current patch.
- we start with inferior 1 as current
- do_target_wait_1 makes inferior 2 current, does a target_wait, which
returns a stop event for an amd-dbgapi wave (thread).
- do_target_wait's scoped_restore_current_thread restores inferior 1 as
current
- fetch_inferior_event calls switch_to_target_no_thread with linux-nat
as the process target, since linux-nat is officially the process
target of inferior 2. This makes inferior 1 the current inferior, as
it's the first inferior with that target.
- In handle_signal_stop, we have:
ecs->event_thread->suspend.stop_pc
= regcache_read_pc (get_thread_regcache (ecs->event_thread));
context_switch (ecs);
regcache_read_pc executes while inferior 1 is still the current one
(because it's before the `context_switch`). This is a problem,
because the regcache is for a ptid managed by the amd-dbgapi target
(e.g. (12345, 1, 1)), a ptid that does not make sense for the
linux-nat target. The fetch_registers target call goes directly
to the linux-nat target, which gets confused.
- We would then get an error like:
Couldn't get extended state status: No such process.
... since linux-nat tries to do a ptrace call on tid 1.
GDB should switch to the inferior the ptid belongs to before doing the
target call to fetch registers, to make sure the call hits the right
target stack (it should be handled by the amd-dbgapi target in this
case). In fact the following patch does this change, and it would be
enough to fix this specific problem.
However, I propose to change regcache to make it switch to the right
inferior, if needed, before doing target calls. That makes the
interface as a whole more independent of the global context.
My first attempt at doing this was to find an inferior using the process
stratum target and the ptid that regcache already knows about:
gdb::optional<scoped_restore_current_thread> restore_thread;
inferior *inf = find_inferior_ptid (this->target (), this->ptid ());
if (inf != current_inferior ())
{
restore_thread.emplace ();
switch_to_inferior_no_thread (inf);
}
However, this caused some failures in fork-related tests and gdbserver
boards. When we detach a fork child, we may create a regcache for the
child, but there is no corresponding inferior. For instance, to restore
the PC after a displaced step over the fork syscall. So
find_inferior_ptid would return nullptr, and
switch_to_inferior_no_thread would hit a failed assertion.
So, this patch adds to regcache the information "the inferior to switch
to to makes target calls". In typical cases, it will be the inferior
that matches the regcache's ptid. But in some cases, like the detached
fork child one, it will be another inferior (in this example, it will be
the fork parent inferior).
The problem that we witnessed was in regcache::raw_update specifically,
but I looked for other regcache methods doing target calls, and added
the same inferior switching code to raw_write too.
In the regcache constructor and in get_thread_arch_aspace_regcache,
"inf_for_target_calls" replaces the process_stratum_target parameter.
We suppose that the process stratum target that would be passed
otherwise is the same that is in inf_for_target_calls's target stack, so
we don't need to pass both in parallel. The process stratum target is
still used as a key in the `target_pid_ptid_regcache_map` map, but
that's it.
There is one spot that needs to be updated outside of the regcache code,
which is the path that handles the "restore PC after a displaced step in
a fork child we're about to detach" case mentioned above.
regcache_test_data needs to be changed to include full-fledged mock
contexts (because there now needs to be inferiors, not just targets).
Change-Id: Id088569ce106e1f194d9ae7240ff436f11c5e123
Reviewed-By: Pedro Alves <pedro@palves.net>
Add the maybe_switch_inferior function, which ensures that the given
inferior is the current one. Return an instantiated
scoped_restore_current_thread object only we actually needed to switch
inferior.
Returning a scoped_restore_current_thread requires it to be
move-constructible, so give it a move constructor.
Change-Id: I1231037102ed6166f2530399e8257ad937fb0569
Reviewed-By: Pedro Alves <pedro@palves.net>
The regcache class takes a process_stratum_target and then exposes it
through regcache::target. But it doesn't use it itself, suggesting it
doesn't really make sense to put it there. The only user of
regcache::target is record_btrace_target::fetch_registers, but it might
as well just get it from the current target stack. This simplifies a
little bit a patch later in this series.
Change-Id: I8878d875805681c77f469ac1a2bf3a508559a62d
Reviewed-By: Pedro Alves <pedro@palves.net>
In the upcoming patch to support fork in the amd-dbgapi target, the
amd-dbgapi target will need to be notified of fork events through an
observer, to attach itself (attach in the amd-dbgapi sense, not ptrace
sense) to the new inferior / process.
The reason that this can't be done through target_ops::follow_fork is
that the amd-dbgapi target isn't pushed on the inferior's target stack
right away. It attaches itself to the process and only pushes itself on
its target stack if and when the inferior initializes the ROCm runtime.
If an inferior that is not using the ROCm runtime forks, we want to be
notified of it, so we can attach to the child, and catch if the child
starts using the ROCm runtime.
So, add a new observable and notify it in follow_fork_inferior. It will
be used later in this series.
Change-Id: I67fced5a9cba6d5da72b9c7ea1c8397644ca1d54
Reviewed-By: Pedro Alves <pedro@palves.net>
The upcoming patch to support exec in the amd-dbgapi target needs to
detach amd-dbgapi from the inferior doing the exec and attach amd-dbgapi
to the inferior continuing the execution. They may or may not be the
same, depending on the `set follow-exec-mode` setting. But even if they
are the same, we need to do the detach / attach dance.
With the current observable signature, the observers only receive the
inferior in which execution continues (the "following" inferior).
Change the signature to pass both inferiors, and update all existing
observers.
Change-Id: I259d1ea09f70f43be739378d6023796f2fce2659
Reviewed-By: Pedro Alves <pedro@palves.net>
In preparation for adding more 128-bit support to gdb, a few additions
to gdb_mpz are needed.
First, this adds a new 'as_integer_truncate' method. This method
works like 'as_integer' but does not require the value to fit in the
target type -- it just truncates.
Second, gdb_mpz::export_bits is changed to handle the somewhat unusual
situation of zero-length types. This can happen for a Rust '()' type;
but I think other languages have zero-bit integer types as well.
Finally, this adds some operator== overloads.
PR 30142
* peXXigen.c (_bfd_XXi_swap_scnhdr_out): Do not force the .rsrc section to be writeable.
* rescoff.c (write_coff_file): Add the SEC_READONLY flag to the .rsrc section.
With DWARF 5, it's possible to produce an empty file name in the File Name
Table of the .debug_line section:
...
The File Name Table (offset 0x112, lines 1, columns 2):
Entry Dir Name
0 1 (indirect line string, offset: 0x2d):
...
Currently, when gdb reads an exec containing such debug info, it segfaults:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \
gdb/dwarf2/read.c:18716
18716 if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL)
...
because read_direct_string transforms "" into a nullptr, and we end up
dereferencing the nullptr.
Note that the behaviour of read_direct_string has been present since repo
creation.
Fix this in read_formatted_entries, by transforming nullptr filenames in to ""
filenames.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
PR symtab/30357
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357
This commit changes mi_make_breakpoint_pending to accept the 'script'
and 'times' arguments.
I've then added a new test that makes use of 'scripts' in
gdb.mi/mi-pending.exp and gdb.mi/mi-dprintf-pending.exp.
There is already a test in gdb.mi/mi-pending.exp that uses the 'times'
argument -- previously this argument was being ignored, but is now
used.
Reviewed-By: Tom Tromey <tom@tromey.com>
Commit:
commit c569a946f6
Date: Fri Mar 24 10:45:37 2023 +0100
[gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument
Introduced the use of {"} in mi-support.exp. There is absolutely
nothing wrong with this in any way. However, this is causing my
editor to get the syntax highlighting of this file wrong after this
point.
Maybe the real answer is to use a better editor, or fix my current
editor.... but I'm hoping I can instead take the lazy approach of just
changing {"} to "\"", which is handled fine, and means exactly the
same as far as I understand it.
There should be no change in what is tested after this commit.
Reviewed-By: Tom Tromey <tom@tromey.com>
Older gdb's (9, 10, 11 and 12) have a bug that causes them to crash whenever
a target reports the pauth feature string in the target description and also
provide additional register outside of gdb's known and expected feature
strings.
This was fixed in gdb 13 onwards, but that means we're stuck with gdb's out
there that will crash on connection to the above targets.
QEMU has postponed inclusion of the pauth feature string in version 8, and
instead we agreed to use a new feature name to prevent crashing those older
gdb's.
Initially there was a plan to backport a trivial fix all the way to gdb 9, but
given QEMU's choice, this is no longer needed.
This new feature string is org.gnu.gdb.aarch64.pauth_v2, and should be used
by all targets going forward, except native linux gdb and gdbserver, for
backwards compatibility with older gdb's/gdbserver's.
gdb/gdbserver will still emit the old feature string for Linux since it doesn't
report additional system registers and thus doesn't cause a crash of older
gdb's. We can revisit this in the future once the problematic gdb's are likely
no longer in use.
I've added some documentation to explain the situation.
The Arm Architecture Reference Manual defines debug version 0b1010 for
FEAT_Debugv8p8. This is used to identify valid hardware debug registers.
gdb currently only knows about versions up to FEAT_Debugv8p4. This patch
teaches gdb about this new version.
No visible changes should happen as consequence of this patch, but in the
future gdb will be able to identify debug registers in newer hardware.
Regression-tested on aarch64-linux Ubuntu 20.04/22.04.
(1) Description of problem
In the current code, when execute the following test on LoongArch:
$make check-gdb TESTS="gdb.base/dump.exp"
```
FAIL: gdb.base/dump.exp: dump array as value, intel hex
FAIL: gdb.base/dump.exp: dump struct as value, intel hex
FAIL: gdb.base/dump.exp: dump array as memory, ihex
FAIL: gdb.base/dump.exp: dump struct as memory, ihex
```
These tests passed on the X86_64,
(2) Root cause
On LoongArch, variable intarray address 0x120008068 out of range for IHEX,
so dump ihex test failed.
gdb.base/dump.exp has the following code to check 64-bit address
```
# Check the address of a variable. If it is bigger than 32-bit,
# assume our target has 64-bit addresses that are not supported by SREC,
# IHEX and TEKHEX. We skip those tests then.
set max_32bit_address "0xffffffff"
set data_address [get_hexadecimal_valueof "&intarray" 0x100000000]
if {${data_address} > ${max_32bit_address}} {
set is64bitonly "yes"
}
```
We check the "&intarray" on different target as follow:
```
$gdb gdb/testsuite/outputs/gdb.base/dump/dump
...
(gdb) start
...
On X86_64:
(gdb) print /x &intarray
$1 = 0x404060
On LoongArch:
(gdb) print /x &intarray
$1 = 0x120008068
```
The variable address difference here is due to the link script
of linker.
```
On X86_64:
$ld --verbose
...
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;
On LoongArch:
$ld --verbose
...
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x120000000));
. = SEGMENT_START("text-segment", 0x120000000) + SIZEOF_HEADERS;
```
(3) How to fix
Because 64-bit variable address out of range for IHEX, it's not an
functional problem for LoongArch. Refer to the handling of 64-bit
targets in this testsuite, use the "is64bitonly" flag to skip those
tests for the target has 64-bit addresses.
Signed-off-by: Hui Li <lihui@loongson.cn>
Approved-By: Tom Tromey <tom@tromey.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Add regression tests for PR30325, one for the asm window and one for the
source window.
Use maint set tui-left-margin verbose to make the extend of the left margin
clear.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR gdb/29257 points out a possible double free when debuginfod is in
use. Aside from some ugly warts in the symbol code (an ongoing
issue), the underlying issue in this particular case is that elfread.c
seems to assume that symfile_bfd_open will return NULL on error,
whereas in reality it throws an exception. As this code isn't
prepared for an exception, bad things result.
This patch fixes the problem by introducing a non-throwing variant of
symfile_bfd_open and using it in the affected places.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29257
All the tests are designed for a little-endian ARC system. Thus,
update the arc predicate in arc.exp, improve the matching pattern for
linker relaxation test, and add linker scripts to nps-1x tests.
Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>
