libcollector may not link against libC.
We use dlsym() to get a function from libc.
In some files, pointers to these functions do not have prototypes.
I also moved the shared definitions to libcollector/collect.h.
gprofng/ChangeLog
2023-03-15 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
libcollector/collector.c: Add prototypes.
libcollector/dispatcher.c: Likewise.
libcollector/heaptrace.c: Likewise.
libcollector/iotrace.c: Likewise.
libcollector/linetrace.c: Likewise.
libcollector/mmaptrace.c: Likewise.
libcollector/synctrace.c: Likewise.
libcollector/collector.h: Add CALL_REAL(), NULL_PTR(), and DBG_LT.
XCOFF archive elements are in a linked list. Add a little more sanity
checking. This of course doesn't stop the fuzzers finding a way to
make a loop, but this check is cheap.
* coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Sanity
check that next element isn't pointing back to the header.
Layout in rewrite_elf_program_header is really done by lma, even if
program headers are going to have their p_paddr forced to zero. Thus
when not matching against an existing segment, don't try to use a
"vma" from elf_segment_map.
* elf.c (is_contained_by): Replace "bed" param with "use_vaddr".
(IS_SECTION_IN_INPUT_SEGMENT): Adjust is_contained_by call.
(rewrite_elf_program_header): Always match against lma in
calls to is_contained_by using new maps.
This adds some types to struct builtin_type, ensuring it contains all
the types currently used by objfile_type.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This renames objfile_type to be an overload of builtin_type, in
preparation for their unification.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
There are a few spots that check whether a type is objfile-owned, and
then choose either the objfile- or arch-specific builtin type. I
don't think there is a need to do this any more (if there ever was),
because it is ok for an objfile-allocated type to refer to an
arch-allocated type.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This changes the set type creation function to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the set, which is what this patch implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This changes the array type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
placement of the index type of the array, which is what this patch
implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This changes the range type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the range, which is what this patch implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This changes a few spots to reuse the existing builting "void" type,
rather than construct a new one.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This introduces a new type_allocator class. This class will be used
to abstract out the placement of new types, so that type-creation code
can be simplified and shared.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
Simon pointed out a line table regression, and after a couple of false
starts, I was able to reproduce it by hand using his instructions.
The bug is that most of the code in do_mixed_source_and_assembly uses
unrelocated addresses, but one spot does:
pc = low;
... after the text offset has been removed.
This patch fixes the problem by introducing a new type to represent
unrelocated addresses in the line table. This prevents this sort of
bug to some degree (it's still possible to manipulate a CORE_ADDR in a
bad way, this is unavoidable).
However, this did let the compiler flag a few spots in that function,
and now it's not possible to compare an unrelocated address from a
line table with an ordinary CORE_ADDR.
Regression tested on x86-64 Fedora 36, though note this setup never
reproduced the bug in the first place. I also tested it by hand on
the disasm-optim test program.
Since commit cb1e4e32c2 ("catch catch/throw/rethrow", breakpoint ->
catchpoint), this simple tracing scenario does not work:
$ gdb/gdb -nx -q --data-directory=gdb/data-directory ./test
Reading symbols from ./test...
(gdb) tar rem :1234
Remote debugging using :1234
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007ffff7fe5730 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) trace do_something
Tracepoint 1 at 0x555555555144: file test.c, line 5.
(gdb) tstart
(gdb) continue
Continuing.
Target returns error code '01'.
The root cause is that the bp_location::nserted flag does not transfer
anymore from an old bp_location to the new matching one. When a shared
library gets loaded, GDB computes new breakpoint locations for each
breakpoint in update_breakpoint_locations. The new locations are in the
breakpoint::loc chain, while the old locations are still in the
bp_locations global vector. Later, update_global_location_list is
called. It tries to map old locations to new locations, and if
necessary transfer some properties, like the inserted flag.
Since commit cb1e4e32c2, the inserted flag isn't transferred for
locations of tracepoints. This is because bl_address_is_meaningful used
to be implemented like this:
static int
breakpoint_address_is_meaningful (struct breakpoint *bpt)
{
enum bptype type = bpt->type;
return (type != bp_watchpoint && type != bp_catchpoint);
}
and was changed to this:
static bool
bl_address_is_meaningful (bp_location *loc)
{
return loc->loc_type != bp_loc_other;
}
Because locations for tracepoints have the bp_loc_other type,
bl_address_is_meaningful started to return false for them, where it
returned true before. This made update_global_location_list skip the
part where it calls swap_insertion.
I think this can be solved by introduced a new bp_loc_tracepoint
bp_loc_type.
I don't know if it's accurate, but my understanding is that bp_loc_type
describes roughly "how do we ask the target to insert that location".
bp_loc_software_breakpoint are inserted using
target_ops::insert_breakpoint_location. bp_loc_hardware_breakpoint are
inserted using target_ops::insert_hw_breakpoint.
bp_loc_software_watchpoint and bp_loc_hardware_watchpoint are inserted
using target_ops::insert_watchpoint. For all these, the address is
meaningful, as we ask the target to insert the point at a specific
address. bp_loc_other is a catch-all for "the rest", in practice for
catchpoints that don't have a specific address (hence why
bl_address_is_meaningful returns false for them). For instance,
inserting a signal catchpoint is done by asking the target to report
that specific signal. GDB doesn't associate an address to that.
But tracepoints do have a meaningful address to thems, so they can't be
bp_loc_other, with that logic. They also can't be
bp_loc_software_breakpoint, because we don't want GDB to insert
breakpoints for them (even though they might be implemented using
software breakpoints by the remote side). So, the new bp_loc_tracepoint
type describes that the way to insert these locations is with
target_ops::download_tracepoint. It makes bl_address_is_meaningful
return true for them. And they'll be ignored by insert_bp_location and
GDB won't try to insert a memory breakpoint for them.
With this, I see a few instances of 'Target returns error code: 01'
disappearing from gdb.log, and the results of gdb.trace/*.exp improve a
little bit:
-# of expected passes 3765
+# of expected passes 3781
-# of unexpected failures 518
+# of unexpected failures 498
Things remain quite broken in that area though.
Change-Id: Ic40935c450410f4bfaba397c9ebc7faf97320dd3
PPC64 multiple entry points, a normal entry point and an alternate entry
point. The alternate entry point is to setup the Table of Contents (TOC)
register before continuing at the normal entry point. When the TOC is
already valid, the normal entry point is used, this is typically the case.
The alternate entry point is typically referred to as the global entry
point (GEP) in IBM. The normal entry point is typically referred to as
the local entry point (LEP).
When GDB is executing the finish command in reverse, the function
finish_backward currently sets the break point at the alternate entry point.
This issue is if the function, when executing in the forward direction,
entered the function via the normal entry point, execution in the reverse
direction will never sees the break point at the alternate entry point. In
this case, the reverse execution continues until the next break point is
encountered thus stopping at the wrong place.
This patch adds a new address to struct execution_control_state to hold the
address of the alternate entry point (GEP). The finish_backwards function
is updated, if the stopping point is between the normal entry point (LEP)
and the end of the function, a breakpoint is set at the normal entry point.
If the stopping point is between the entry points, a breakpoint is set at
the alternate entry point. This ensures that GDB will always stop at the
normal entry point. If the function did enter via the alternate entry
point, GDB will detect that and continue to execute backwards in the
function until the alternate entry point is reached.
The patch fixes the behavior of the reverse-finish command on PowerPC to
match the behavior of the command on other platforms, specifically X86.
The patch does not change the behavior of the command on X86.
A new test is added to verify the reverse-finish command on PowerPC
correctly stops at the instruction where the function call is made.
The patch fixes 11 regression errors in test gdb.reverse/finish-precsave.exp
and 11 regression errors in test gdb.reverse/finish-reverse.exp.
The patch has been tested on Power 10 and X86 processor with no new
regression failures.
Procedure step_until from test gdb.reverse/step-indirect-call-thunk.exp
is moved to lib/gdb.exp and renamed repeat_cmd_until. The existing procedure
gdb_step_until in lib/gdb.exp is simpler variant of the new repeat_cmd_until
procedure. The existing procedure gdb_step_until is changed to just call
the new repeat_cmd_until procedure with the command set to "step" and an
optional CURRENT string. The default CURRENT string is set to "\}" to work
with the existing uses of procedure gdb_step_until.
With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) info sharedlibrary^M
From To Syms Read Shared Object Library^M
$hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
$hex $hex Yes /home/remote-host/libinproctrace.so^M
$hex $hex Yes /lib64/libm.so.6^M
$hex $hex Yes /lib64/libc.so.6^M
$hex $hex Yes /lib64/libdl.so.2^M
$hex $hex Yes (*) /usr/lib64/libstdc++.so.6^M
$hex $hex Yes (*) /lib64/libgcc_s.so.1^M
$hex $hex Yes /lib64/libpthread.so.0^M
(*): Shared library is missing debugging information.^M
(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
...
due to trying to match libinproctrace.so using the target path, while the
command lists it using the host path.
Fix this by making the regexp less strict.
Tested on x86_64-linux.
With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) tstart^M
Target returns error code '.In-process agent library not loaded in process. \
Fast and static trace points unavailable.'.^M
(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: start trace experiment
...
Fix this by:
- handling remote host in gdb_load_shlib, and
- moving the gdb_load_shlib to after the clean_restart, such that the
set solib-search-path can take effect.
Tested on x86_64-linux.
Handle REMOTE_HOST_USERNAME in local-remote-host, similar to how that's done for
REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.
This helps to keep the home dir clean.
Since the setup makes $build/gdb/testsuite on build unreadable for the remote
host, we run into permission problems for GDB and the data-directory, so fix
this (as was done for gdbserver in gdbserver-base.exp) using file normalize.
Tested on x86_64-linux.
When doing a gdb_simple_compile, and downloading the resulting exec $obj
to target the result $target_obj may be a relative file path, which may give
problems when trying to do:
...
remote_exec target $target_obj
...
Fix/workaround this on some target boards by setting remotedir by default, and
add a corresponding test in gdb.testsuite/board-sanity.exp.
This doesn't work for host/target board local-remote-host-native, so xfail this.
Tested on x86_64-linux.
In proc have_avx we compile some source into an exec, resulting in a file $obj
on build, and then attempt to execute it on target:
...
set result [remote_exec target $obj]
...
Fix this by using gdb_remote_download target.
Likewise in a few other procs that use "remote_exec target".
Tested on x86_64-linux.
With test-case gdb.arch/i386-sse.exp (and likewise gdb.arch/i386-avx.exp) and
host board local-remote-host-notty and target board native-gdbserver I run
into:
...
gdb compile failed, i386-sse.c:68:10: fatal error: \
../lib/precise-aligned-alloc.c: No such file or directory
#include "../lib/precise-aligned-alloc.c"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
Fix this using '#include "precise-aligned-alloc.c"' and making that work with
non-remote and remote host.
Tested on x86_64-linux.
In gdb_compile we have:
...
lappend new_options "ldflags=-Wl,-rpath,\\\$ORIGIN"
...
and we could improve readability by using {} rather than "":
...
lappend new_options {ldflags=-Wl,-rpath,\$ORIGIN}
...
But rather than manually adding escapes in a string, add a new proc
escape_for_host that care of this for us, allowing us to write:
...
lappend new_options [escape_for_host {ldflags=-Wl,-rpath,$ORIGIN}]
...
Tested on x86_64-linux.
