Make them return boolean and convert FETCH_DATA() uses to fetch_code().
With this no further users of FETCH_DATA() remain, so the macro and its
backing function are dropped as well.
Leave value types as they were for the helper functions, even if I don't
think that beyond get64() use of bfd_{,signed_}vma is really necessary.
With type change of "disp" in OP_E_memory(), change the 2nd parameter of
print_displacement() to a signed type as well, though (eliminating the
need for a local variable of signed type). This also eliminates the need
for custom printing of '-' in Intel syntax displacement expressions.
While there drop forward declarations which aren't really needed.
Use a tristate (enum) return value type to be able to express all three
cases which are of interest to the (sole) caller. This also allows doing
away with the abuse of "rex_used".
... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch
error handling is problematic, as per
https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start
using more conventional error handling instead.
Also introduce a fetch_modrm() helper, for subsequent re-use.
... such that it can be used from other than the setjmp() error handling
path.
Since I'd like the function's parameter to be pointer-to-const, two
other functions need respective constification then, too (along with
needing to be forward-declared).
This should be the first related issue, which posted in riscv-gnu-toolchain,
https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497
If the output sections are not between gp and the symbol, then their alignments
shouldn't affect the gp relaxation. However, this patch improves this idea
even more, it limits the range to the gp+-2k, which means only the output
section which are in the [gp-2K, gp+2K) range need to be considered.
Even if the output section candidates may be different for each relax passes,
the symbol that can be relaxed ar this round will not be truncated at next
round. That is because this round you can do relaxation which means that the
section where the symbol is located is within the [gp-2K, gp+2K) range, so all
the output section alignments between them should be considered. In other
words, if the alignments between them may cause truncated, then we should
already preserve the size and won't do the gp relaxation this time.
This patch can resolve the github issue which mentioned above, and also passed
all gcc/binutils regressions of riscv-gnu-toolchain, so should be worth and
safe enough to commit.
Originally, this patch also do the same optimization for the call relaxations,
https://sourceware.org/pipermail/binutils/2022-October/123918.html
But just in case there is something that has not been considered, we only
deal with the gp relaxation at this time.
bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Added new bfd_vma,
max_alignment_for_gp. It is used to record the maximum alignment of
the output sections, which are in the [gp-2K, gp+2k) range.
(riscv_elf_link_hash_table_create): Init max_alignment_for_gp to -1.
(_bfd_riscv_get_max_alignment): Added new parameter, gp. If gp is
zero, then all the output section alignments are possible candidates;
Otherwise, only the output sections which are in the [gp-2K, gp+2K)
range need to be considered.
(_bfd_riscv_relax_lui): Called _bfd_riscv_get_max_alignment with the
non-zero gp if the max_alignment_for_gp is -1.
(_bfd_riscv_relax_pc): Likewise.
(_bfd_riscv_relax_section): Record the first input section, so that
we can reset the max_alignment_for_gp for each repeated relax passes.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/relax-max-align-gp.*: New testcase. It fails
without this patch.
rs6000-coff archives use a linked list of file offsets, where each
element points to the next element. The idea is to allow updating of
large archives quickly without rewriting the whole archive. (binutils
ar does not do this.) Unfortunately this is an easy target for
fuzzers to create an archive that will cause ar or any other tool
processing archives to hang. I'd implemented guards against pointing
back to the previous element, but of course that didn't last long.
So this patch implements a scheme to keep track of file offset ranges
used by elements as _bfd_read_ar_hdr is called for each element. See
the add_range function comment. I needed a place to stash the list,
so chose the obvious artdata.tdata backend extension to archive's
tdata, already used by xcoff. That involved a little cleanup, because
while it would be possible to continue using different artdata.tdata
for the big and small archives, it's nicer to use a union.
If anyone is concerned this list of element ranges might grow large
and thus significantly slow down the tools, adjacent ranges are
merged. In fact something like "ar t" will only ever have one range
on xcoff archives generated by binutils/ar. I agree there might still
be a problem with ld random element access via the armap.
include/
* coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof.
(SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise.
(struct ar_ranges, struct xcoff_artdata): New.
(x_artdata): Define.
(xcoff_big_format_p): Rewrite.
(xcoff_ardata, xcoff_ardata_big): Delete.
bfd/
* coff-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(_bfd_xcoff_archive_p): Adjust artdata.tdata allocation.
(add_range): New function.
(_bfd_xcoff_read_ar_hdr): Use it here. Fix memory leak.
(_bfd_xcoff_openr_next_archived_file): Remove old sanity
checks. Set up range for header.
(xcoff_write_archive_contents_old): Make the temporary
artdata.tdata used here to pass info down to
_bfd_compute_and_write_armap a struct xcoff_artdata.
(xcoff_write_archive_contents_big): Likewise.
* coff64-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(xcoff64_archive_p): Adjust artdata.tdata allocation.
This element is unused. Ideally we'd be moving archive_head and
other archive specific fields from struct bfd to here, but that's a
much larger change than this little bit of cleanup.
* libbfd-in.h (struct artdata): Delete archive_head.
* libbfd.h: Regenerate.
* archive.c,
* coff-rs6000.c,
* coff64-rs6000.c: Delete comments mentioning artdata archive_head.
In commit 6967633c8b ("x86: convert testcases to use .insn") an ILP32
clone of a testcase was missed in the set of tests needing --divide
added.
Reported-by: Clément Chigot <chigot@adacore.com>
Segmentation fault
FAIL: pr22269-1 (static pie undefined weak)
and others running "visibility (hidden undef)" tests
No code has any right to access bfd_link_hash_entry u.def without
first checking the type, and SYMBOL_REFERENCES_LOCAL isn't sufficient.
* elf32-sh.c (sh_elf_finish_dynamic_symbol): Don't use relative
relocs in GOT unless symbol is defined.
Make ldemul_before_plugin_all_symbols_read more useful.
* ldlang.c (lang_process): Move call to
ldemul_before_plugin_all_symbols_read outside BFD_SUPPORTS_PLUGINS.
Allow backends to add to gc_sym_list before handling entry sym.
* ldelf.c (ldelf_before_plugin_all_symbols_read): Test
lto_plugin_active.
This one was caused by me unnecessarily promoting an "int adv" to
"int64_t adv". The expression overflowing was 4259 + 9223372036854775807
with the left number being unsigned int.
* dwarf.h (DWARF2_Internal_LineInfo): Replace unsigned short
with uint16_t and unsigned char with uint8_t. Make li_line_base
an int8_t.
* dwarf.c (display_debug_lines_raw): Revert "adv" back to an int.
Do I care about out of memory conditions triggered by fuzzers? Not
much. Your operating system ought to be able to handle it by killing
the memory hog. Oh well, this one was an element of a coff-alpha
archive that said it was a little less that 2**64 in size. The
coff-alpha compression scheme expands at most 8 times, so we can do
better in bfd_get_file_size.
* bfdio.c (bfd_get_file_size): Assume elements in compressed
archive can only expand a maximum of eight times.
* coffgen.c (_bfd_coff_get_external_symbols): Sanity check
size of symbol table agains file size.
libsframe/
* sframe.c (sframe_decoder_get_header): Use consistent function
arg names.
(sframe_decoder_free): Likewise.
(sframe_encode): Use more appropriate var name.
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>
