| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Various tests use test code written in i386 / x86_64 assembly that cannot
be used to create PIE executables. Therefore compilation of test programs
failed on systems where the compiler default is to create PIE executable.
The solution is to use -no-pie linker flag, however, such flag may not
(is not) supported by all compilers GDB needs to support (e.g. gcc 4.8).
To handle this, introduce a new flag to gdb_compile - nopie - which
inserts -no-pie linker flag where supported and is no-op where it is
not. By default, -no-pie flag is inserted since most modern compiler do
support it.
|
|
The ptrace command PT_LWPINFO to request detailed information about a
stopped thread can return stale signal information from an earlier
stop. Events which are reporting an intercepted signal will always
report the correct information, but signal stops for some other events
such as system call enter/exit events might include stale siginfo from
an earlier signal. In particular, if a thread reports a system call
entry or exit event after previously reporting a single-step or
breakpoint event via SIGTRAP, fbsd_handle_debug_trap believed the
system call event was the previous event and claimed it resulting in a
spurious SIGTRAP event.
True breakpoint and single-step events will never report another event
in the pl_flags member of struct ptrace_lwpinfo. Use this to detect
stale siginfo by requiring pl_flags to have only the PL_FLAG_SI flag
and no other flags before treating a SIGTRAP as a single-step or
breakpoint trap.
gdb/ChangeLog:
* fbsd-nat.c (fbsd_handle_debug_trap): Require pl.pl_flags to
equal PL_FLAG_SI.
(fbsd_nat_target::stopped_by_sw_breakpoint): Likewise.
|
|
Running `info os someUnknownOsType` is crashing when gdb is built with
-D_GLIBCXX_DEBUG:
/usr/include/c++/5/debug/vector:439:error: attempt to
access an element in an empty container.
In target_read_stralloc from target.c, the call to
target_read_alloc_1 can return an empty vector, we then call vector::back on
this vector, which is invalid.
This commit adds a check for emptiness before trying to call
vector::back on it. It also adds test to check for `info os <unknown>`
to return the proper error message.
This is a regression in gdb 8.2 and this patch restores the behavior of
previous versions.
gdb/ChangeLog:
PR gdb/23974
* target.c (target_read_stralloc): Check for empty vector.
gdb/testsuite/ChangeLog:
PR gdb/23974
* gdb.base/info-os.exp: Check return for unknown "info os" type.
|
|
When using the --configuration command line switch, or using
the "show configuration" command with a version of GDB which
was configured without Python supoprt, this patch changes
the resulting output to include...
--without-python
... instead of not printing anything about Python support.
gdb/ChangeLog:
* top.c (print_gdb_configuration): Print "--without-python"
if GDB was configured without Python.
Tested on x86_64-linux by rebuilding GDB with and without Python,
and checking the output of "gdb --configuration" in both cases.
|
|
Avoid compiler errors caused by trying to print CORE_ADDR using '%ld'
format, instead convert to a string and print that instead.
gdb/ChangeLog:
* riscv-tdep.c (riscv_scan_prologue): Use plongest to format
a signed offset as a string.
|
|
When compiling with clang 3.8 (default clang version on Debian
Stretch, the current stable), we get errors like this:
CXX dtrace-probe.o
../../binutils-gdb/gdb/dtrace-probe.c:103:31: error: default initialization of an object of const type 'const dtrace_static_probe_ops' without a user-provided default constructor
const dtrace_static_probe_ops dtrace_static_probe_ops;
^
Silence them by value-initializing those objects. It's not necessary
with other compilers (later clang versions, gcc), but it shouldn't
hurt either.
|
|
standard_ada_testfile, standard_test_file and the explicit
csrcfile assignment in info_auto_lang.exp all gives similar pathnames
prefix for a source, such as
/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>.
Note that the above pathnames contain ../ which appears when a relative
pathname is used to call configure.
In any case, the gnat compiler normalizes Ada sources path when compiling.
So, the 'Ada' .o object are referencing a pathname such as
/home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb,
while the 'C' .o object still references the not normalized pathname.
As the results of 'info functions | ...' are sorted by pathname first,
the order of the results depends on the comparison between different directories,
leading to results that can change depending on these directories.
=> Ensure the result order is always the same, by normalising the C source file,
which makes the results independent of the way configure is launched.
Tested by running the testcase in 2 different builds, that without normalize
were giving different results.
Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C.
After discussion, it was deemed sufficient to just normalize the pathname
for this test.
gdb/testsuite/ChangeLog
2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.ada/info_auto_lang.exp: Normalize some_c source file.
Update order of results accordingly.
|
|
Supply default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp. This patch doesn't actually
convert any targets to use these methods, and so, there will be no
user visible changes after this commit.
The implementations for default_dummy_id and default_unwind_sp are
fairly straight forward, these just take on the pattern used by most
targets. Once these default methods are in place then most targets
will be able to switch over.
The implementation for default_unwind_pc is also fairly straight
forward, but maybe needs some explanation.
This patch has gone through a number of iterations:
https://sourceware.org/ml/gdb-patches/2018-03/msg00165.html
https://sourceware.org/ml/gdb-patches/2018-03/msg00306.html
https://sourceware.org/ml/gdb-patches/2018-06/msg00090.html
https://sourceware.org/ml/gdb-patches/2018-09/msg00127.html
and the implementation of default_unwind_pc has changed over this
time. Originally, I took an implementation like this:
CORE_ADDR
default_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
{
int pc_regnum = gdbarch_pc_regnum (gdbarch);
return frame_unwind_register_unsigned (next_frame, pc_regnum);
}
This is basically a clone of default_unwind_sp, but using $pc. It was
pointed out that we could potentially do better, and in version 2 the
implementation became:
CORE_ADDR
default_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
{
struct type *type;
int pc_regnum;
CORE_ADDR addr;
struct value *value;
pc_regnum = gdbarch_pc_regnum (gdbarch);
value = frame_unwind_register_value (next_frame, pc_regnum);
type = builtin_type (gdbarch)->builtin_func_ptr;
addr = extract_typed_address (value_contents_all (value), type);
addr = gdbarch_addr_bits_remove (gdbarch, addr);
release_value (value);
value_free (value);
return addr;
}
The idea was to try split out some of the steps of unwinding the $pc,
steps that are on some (or many) targets no-ops, and so allow targets
that do override these methods, to make use of default_unwind_pc.
This implementation remained in place for version 2, 3, and 4.
However, I realised that I'd made a mistake, most targets simply use
frame_unwind_register_unsigned to unwind the $pc, and this throws an
error if the register value is optimized out or unavailable. My new
proposed implementation doesn't do this, I was going to end up
breaking many targets.
I considered duplicating the code from frame_unwind_register_unsigned
that throws the errors into my new default_unwind_pc, however, this
felt really overly complex. So, what I instead went with was to
simply revert back to using frame_unwind_register_unsigned. Almost
all existing targets already use this. Some of the ones that don't can
be converted to, which means almost all targets could end up using the
default.
One addition I have made over the version 1 implementation is to add a
call to gdbarch_addr_bits_remove. For most targets this is a no-op,
but for a handful, having this call in place will mean that they can
use the default method. After all this, the new default_unwind_pc now
looks like this:
CORE_ADDR
default_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
{
int pc_regnum = gdbarch_pc_regnum (gdbarch);
CORE_ADDR pc = frame_unwind_register_unsigned (next_frame, pc_regnum);
pc = gdbarch_addr_bits_remove (gdbarch, pc);
return pc;
}
gdb/ChangeLog:
* gdb/dummy-frame.c (default_dummy_id): Defined new function.
* gdb/dummy-frame.h (default_dummy_id): Declare new function.
* gdb/frame-unwind.c (default_unwind_pc): Define new function.
(default_unwind_sp): Define new function.
* gdb/frame-unwind.h (default_unwind_pc): Declare new function.
(default_unwind_sp): Declare new function.
* gdb/frame.c (frame_unwind_pc): Assume gdbarch_unwind_pc is
available.
(get_frame_sp): Assume that gdbarch_unwind_sp is available.
* gdb/gdbarch.c: Regenerate.
* gdb/gdbarch.h: Regenerate.
* gdb/gdbarch.sh: Update definition of dummy_id, unwind_pc, and
unwind_sp. Add additional header files to be included in
generated file.
|
|
A recent patch [1] to fix a GCC PR [2] actually broke the GDB build.
To fix, remove the stack pointer clobber. GCC will ignore the clobber
marker, and will not save or restore the stack pointer.
I ran "make check-gdb" on x86_64 to ensure there are no regressions.
gdb/ChangeLog:
2018-12-17 Dimitar Dimitrov <dimitar@dinux.eu>
* nat/linux-ptrace.c (linux_ptrace_test_ret_to_nx): Remove sp clobbers.
[1] https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00532.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
|
|
In the dwarf reader we have a set of predicates, these include the
different producer predicates and also some control predicates. The
older ones are declared as integers, while newer ones (added since the
C++ conversion) are bool.
This commit makes them all bool for consistency. There should be no
user visible change after this commit.
gdb/ChangeLog:
* dwarf2read.c (struct dwarf2_cu): Convert the fields 'mark',
'has_loclist', 'checked_producer', 'producer_is_gxx_lt_4_6',
'producer_is_gcc_lt_4_3', 'producer_is_icc_lt_14',
'processing_has_namespace_info' from unsigned int to bool. Update
comments.
(producer_is_icc_lt_14): Update return type.
(producer_is_gcc_lt_4_3): Likewise.
(producer_is_gxx_lt_4_6): Likewise.
(process_die): Write true instead of 1 into predicate fields.
(dwarf2_start_symtab): Likewise.
(var_decode_location): Likewise.
(dwarf2_mark_helper): Likewise.
(dwarf2_mark): Likewise.
(dwarf2_clear_marks): Write false instead of 0 into predicate
field.
(dwarf2_cu::dwarf2_cu): Initialise predicate fields to false, not
0.
|
|
Including asm/sigcontext.h together with libc headers is not valid. In
general linux headers may not work with libc headers, so mixing them
should be avoided, especially when the linux header defines types that
are also exposed in libc headers.
In case of asm/sigcontext.h glibc happens to work because glibc signal.h
directly includes it, but e.g. in musl libc signal.h replicates the
sigcontext.h definitions in an abi compatible way which are in conflict
with the linux definitions when both headers are included.
Since old linux headers or old libc headers may not have the necessary
definitions, gdb has to replicate the definitions it relies on anyway.
Which is fine since all definitions must be ABI stable. For linux apis
that are not available via libc headers, replicating the definitions in
gdb is the most reliable way to use them.
Note: asm/ptrace.h includes asm/sigcontext.h in some versions of linux
headers, which is just as problematic and should be fixed in linux.
gdb/ChangeLog:
* nat/aarch64-sve-linux-ptrace.h: Include signal.h instead of
asm/sigcontext.h.
|
|
2018-12-17 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* nat/linux-ptrace.c (kill_child): Fix ARI warning by removing
warning trailing new line.
|
|
Running the gdb testsuite under Valgrind started to fail after 100+ tests,
due to out of memory caused by lingering processes.
The lingering processes are caused by the combination
of a limitation in Valgrind signal handling when using PTRACE_TRACEME
and a (minor) bug in GDB.
The Valgrind limitation is : when a process is ptraced and raises
a signal, Valgrind will replace the raised signal by SIGSTOP as other
signals are masked by Valgrind when executing a system call.
Removing this limitation seems far to be trivial, valgrind signal
handling is very complex.
Due to this valgrind limitation, GDB linux_ptrace_test_ret_to_nx gets
a SIGSTOP signal instead of the expected SIGTRAP or SIGSEGV.
In such a case, linux_ptrace_test_ret_to_nx does an early return, but
does not kill the child (running under valgrind), child stays in a STOP-ped
state.
These lingering processes then eat the available system memory,
till launching a new process starts to fail.
This patch fixes the GDB minor bug by killing the child in case
linux_ptrace_test_ret_to_nx does an early return.
nat/linux-ptrace.c has 3 different logics to kill a child process.
So, this patch factorizes killing a child in the function kill_child.
The 3 different logics are:
* linux_ptrace_test_ret_to_nx is calling both kill (child, SIGKILL)
and ptrace (PTRACE_KILL, child, ...), and then is calling once
waitpid.
* linux_check_ptrace_features is calling ptrace (PTRACE_KILL, child, ...)
+ my_waitpid in a loop, as long as the waitpid status was WIFSTOPPED.
* linux_test_for_tracefork is calling once ptrace (PTRACE_KILL, child, ...)
+ my_waitpid.
The linux ptrace documentation indicates that PTRACE_KILL is deprecated,
and tells to not use it, as it might return success but not kill the tracee.
The documentation indicates to send SIGKILL directly.
I suspect that linux_ptrace_test_ret_to_nx calls both kill and ptrace just
to be sure ...
I suspect that linux_check_ptrace_features calls ptrace in a loop
to bypass the PTRACE_KILL limitation.
And it looks like linux_test_for_tracefork does not handle the PTRACE_KILL
limitation.
Also, 2 of the 3 logics are calling my_waitpid, which seems better,
as this is protecting the waitpid syscall against EINTR.
So, the logic in kill_child is just using kill (child, SIGKILL)
+ my_waitpid, and then does a few verifications to see everything worked
accordingly to the plan.
Tested on Debian/x86_64.
2018-12-16 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* nat/linux-ptrace.c (kill_child): New function.
(linux_ptrace_test_ret_to_nx): Use kill_child instead of local code.
Add a call to kill_child in case of early return after fork.
(linux_check_ptrace_features): Use kill_child instead of local code.
(linux_test_for_tracefork): Likewise.
|
|
This removes an IMO not very useful comment in gdb/Makefile.in about
"alloca". It also removes INFOFILES, which I think probably has not
been useful since whenever the manual was moved into a subdirectory.
gdb/ChangeLog
2018-12-14 Tom Tromey <tom@tromey.com>
* Makefile.in: Remove "alloca" comment.
(INFOFILES): Remove.
(local-maintainer-clean): Don't use INFOFILES.
|
|
Add a script to generate the FreeBSD XML system call table from the
sys/sys/syscall.h file in the kernel source tree. For ABI
compatiblity system calls used by older binaries (such as
freebsd11_kevent()), the original system call name is used as an
alias.
Run this script against the current syscall.h file in FreeBSD's head
branch which is expected to be the file used in 12.0 (head is
currently in code freeze as part of the 12.0 release process).
gdb/ChangeLog:
* syscalls/update-freebsd.sh: New file.
* syscalls/freebsd.xml: Regenerate.
|
|
When setting a syscall catchpoint by name, catch syscalls whose name
or alias matches the requested string.
When the ABI of a system call is changed in the FreeBSD kernel, this
is implemented by leaving a compatibility system call using the old
ABI at the existing "slot" and allocating a new system call for the
version using the new ABI. For example, new fields were added to the
'struct kevent' used by the kevent() system call in FreeBSD 12. The
previous kevent() system call in FreeBSD 12 kernels is now called
freebsd11_kevent() and is still used by older binaries compiled
against the older ABI. The freebsd11_kevent() system call can be
tagged with an "alias" attribute of "kevent" permitting 'catch syscall
kevent' to catch both system calls and providing the expected user
behavior for both old and new binaries. It also provides the expected
behavior if GDB is compiled on an older host (such as a FreeBSD 11
host).
gdb/ChangeLog:
* NEWS: Add entry documenting system call aliases.
* break-catch-syscall.c (catch_syscall_split_args): Pass 'result'
to get_syscalls_by_name.
* gdbarch.sh (UNKNOWN_SYSCALL): Remove.
* gdbarch.h: Regenerate.
* syscalls/gdb-syscalls.dtd (syscall): Add alias attribute.
* xml-syscall.c [!HAVE_LIBEXPAT] (get_syscalls_by_name): Rename
from get_syscall_by_name. Now accepts a pointer to a vector of
integers and returns a bool.
[HAVE_LIBEXPAT] (struct syscall_desc): Add alias member.
(syscall_create_syscall_desc): Add alias parameter and pass it to
syscall_desc constructor.
(syscall_start_syscall): Handle alias attribute.
(syscall_attr): Add alias attribute.
(xml_get_syscalls_by_name): Rename from xml_get_syscall_number.
Now accepts a pointer to a vector of integers and returns a
bool. Add syscalls whose alias or name matches the requested
name.
(get_syscalls_by_name): Rename from get_syscall_by_name. Now
accepts a pointer to a vector of integers and returns a bool.
* xml-syscall.h (get_syscalls_by_name): Likewise.
gdb/doc/ChangeLog:
* gdb.texinfo (Set Catchpoints): Add an anchor for 'catch syscall'.
(Native): Add a FreeBSD subsection.
(FreeBSD): Document use of system call aliases for compatibility
system calls.
|
|
This removes the need for the caller to explicitly manage the memory
for the returned system call list. The sole caller only needed the
system call numbers rather than the full syscall structures.
get_syscalls_by_group now uses a boolean return value to indicate if
the requested group exists.
gdb/ChangeLog:
* break-catch-syscall.c (catch_syscall_split_args): Pass 'result'
to get_syscalls_by_group.
* xml-syscall.c [!HAVE_LIBEXPAT] (get_syscalls_by_group): Return
false.
[HAVE_LIBEXPAT] (xml_list_syscalls_by_group): Append syscall
numbers to an existing vector of integers and return a bool.
(get_syscalls_by_group): Accept pointer to vector of integers
and change return type to bool.
* xml-syscall.h (get_syscalls_by_group): Likewise.
|
|
* riscv-tdep.c (riscv_print_one_register_info): For MSTATUS, add
comment for SD field, and correct xlen calculation. For MISA, add
comment for MXL field, add call to register_size, and correct base
calculation.
|
|
gdb/ChangeLog:
* NEWS(New targets): Add or1k*-*-linux*.
|
|
ARI warning.
2018-12-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* nat/linux-osdata.c (linux_xfer_osdata_info_os_types): Forward
declare on one line to fix ARI warning.
|
|
When running the test gdb.base/annota1.exp with:
make check-gdb RUNTESTFLAGS="--target_board=native-extended-gdbserver gdb.base/annota1.exp"
I would see a failure due to some unexpected lines in GDB's output.
The extra lines (when compared with a native run) were about file
transfer from the remote back to GDB.
This commit extends the regexp for this test to allow for these extra
lines, and also splits the rather long regexp up into a list of parts.
With this change in place I see no failures for gdb.base/annota1.exp
when using the native-extended-gdbserver target board, nor with a
native run on X86-64/Linux.
gdb/testsuite/ChangeLog:
* gdb.base/annota1.exp: Update a test regexp.
|
|
I ran into a situation where attempting to make an inferior function
call would trigger an assertion, like this:
(gdb) call some_inferior_function ()
../../src/gdb/regcache.c:310: internal-error: void regcache::restore(readonly_detached_regcache*): Assertion `src != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The problem that triggers the assertion is that in the function
save_infcall_suspend_state, we basically did this:
1. Create empty infcall_suspend_state object.
2. Fill fields of infcall_suspend_state object.
The problem is causes is that if filling any of the fields triggered
an exception then the infcall_suspend_state object would be deleted
while in a partially filled in state.
In the specific case I encountered, I had a remote RISC-V target that
claimed in its target description to support floating point registers.
However, this was not true, and when GDB tried to read a floating
point register the remote sent back an error. This error would cause
an exception to be thrown while creating the
readonly_detached_regcache, which in turn caused GDB to try and delete
an infcall_suspend_state which didn't have any register state, and
this triggered the assertion.
To prevent this problem we have two possibilities, either, rewrite the
restore code the handle partially initialised infcall_suspend_state
objects, or, prevent partially initialised infcall_suspend_state
objects from existing. The second of these seems like a better
solution.
So, in this patch, I move the filling in of the different
infcall_suspend_state fields within a new constructor for
infcall_suspend_state. Now, if generating one of those fields fails
the destructor for infcall_suspend_state will not be executed and GDB
will not try to restore the partially saved state.
With this patch in place GDB now behaves like this:
(gdb) call some_inferior_function ()
Could not fetch register "ft0"; remote failure reply 'E99'
(gdb)
The inferior function call is aborted due to the error.
This has been tested against x86-64/Linux native, native-gdbserver,
and native-extended-gdbserver with no regressions. I've manually
tested this against my baddly behaving target and confirmed the
inferior function call is aborted as described above.
gdb/ChangeLog:
* infrun.c (infcall_suspend_state::infcall_suspend_state): New.
(infcall_suspend_state::registers): New.
(infcall_suspend_state::restore): New.
(infcall_suspend_state::thread_suspend): Rename to...
(infcall_suspend_state::m_thread_suspend): ...this.
(infcall_suspend_state::registers): Rename to...
(infcall_suspend_state::m_registers): ...this.
(infcall_suspend_state::siginfo_gdbarch): Rename to...
(infcall_suspend_state::m_siginfo_gdbarch): ...this.
(infcall_suspend_state::siginfo_data): Rename to...
(infcall_suspend_state::m_siginfo_data): ...this.
(save_infcall_suspend_state): Rewrite to use infcall_suspend_state
constructor.
(restore_infcall_suspend_state): Rewrite to use
infcall_suspend_state::restore method.
(get_infcall_suspend_state_regcache): Use
infcall_suspend_state::registers method.
|
|
This commit fixes some test failures in gdb.base/varargs.exp when
running on targets with floating point hardware. Floating point
unnamed (variadic) arguments should be passed in integer registers
according to the abi.
After this commit I see no failures in gdb.base/varargs.exp on 32 or
64 bit targets with floating point hardware.
gdb/ChangeLog:
* riscv-tdep.c (riscv_call_arg_scalar_float): Unnamed (variadic)
arguments are passed in integer registers.
(riscv_call_arg_complex_float): Likewise.
|
|
Valgrind reports leaks in all linux osdata annex transfers of linux-osdata.c.
A typical leak (this one is of gdb.base/info-os) is:
==10592== VALGRIND_GDB_ERROR_BEGIN
==10592== 65,536 bytes in 1 blocks are definitely lost in loss record 3,175 of 3,208
==10592== at 0x4C2E273: realloc (vg_replace_malloc.c:826)
==10592== by 0x409B0C: xrealloc (common-utils.c:62)
==10592== by 0x408BC3: buffer_grow(buffer*, char const*, unsigned long) [clone .part.1] (buffer.c:40)
==10592== by 0x5263DF: linux_xfer_osdata_processes(unsigned char*, unsigned long, unsigned long) (linux-osdata.c:370)
==10592== by 0x520875: linux_nat_xfer_osdata (linux-nat.c:4214)
...
The leaks are created because the linux_xfer_osdata_* functions
transfer the ownership of their 'static struct buffer' memory
to their 'static char *buf' local var, but then call buffer_free
instead of xfree-ing buf.
I see no reason why the ownership of the memory has to be transferred
from a local var to another local var, so the fix consists in dropping
the 'static char *buf' and accessing the struct buffer memory where needed.
Also, because this bug was replicated in all functions, and there was
a non neglectible amount of duplicated code, the setup and usage
of the 'static struct buffer' is factorized in a new function
common_getter. The buffer for a specific annex is now a member
of the struct osdata_type instead of being a static var of each
linux_xfer_osdata_* function.
Thanks to this, all the linux_xfer_osdata_* do not have
anymore any logic related to the partial transfer of data: they now
only build the xml data in a struct buffer.
This all removes about 300 SLOC.
Note: git diff/git format-patch shows a lot of differences only due
to space changes/indentation changes.
So, git diff -w helps to look only at the relevant differences.
gdb/ChangeLog
2018-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* nat/linux-osdata.c (common_getter): New function.
(struct osdata_type): Change getter to take_snapshot.
Add LONGEST len_avail and struct buffer buffer.
Change all elements in the initializer.
Add an element for the list of types.
(linux_xfer_osdata_info_os_types): New function.
(linux_common_xfer_osdata): Use common_getter for the list of types.
Replace getter call by common_getter.
(linux_xfer_osdata_cpus): Remove args READBUF, OFFSET, LEN.
Add arg BUFFER. Only keep the code that adds data in BUFFER.
(linux_xfer_osdata_fds): Likewise.
(linux_xfer_osdata_modules): Likewise.
(linux_xfer_osdata_msg): Likewise.
(linux_xfer_osdata_processes): Likewise.
(linux_xfer_osdata_processgroups): Likewise.
(linux_xfer_osdata_sem): Likewise.
(linux_xfer_osdata_shm): Likewise.
(linux_xfer_osdata_isockets): Likewise.
(linux_xfer_osdata_threads): Likewise.
|
|
|
|
|
|
The FPU is optional on RISC-V. The gdb.base/float.exp test currently
assumes that an fpu is always available on RISC-V. Update the test so
that this is not the case.
gdb/testsuite/ChangeLog:
* gdb.base/float.exp: Handle RISC-V targets without an FPU.
|
|
This fixes an ARI warning in riscv-tdep.c that whitespace before a
gdb/ChangeLog:
* riscv-tdep.c (riscv_register_name): Fix ARI warning by removing
leading whitespace before #include line.
|
|
A failure that seems to cause a long/infinite time is the following:
For a not clear reason, tid-reuse.c spawner thread sometimes gets an error:
tid-reuse: /bd/home/philippe/gdb/git/build_moreaa/gdb/testsuite/../../../moreaa/gdb/testsuite/gdb.threads/tid-reuse.c:58: spawner_thread_func: Assertion `rc == 0' failed.
which causes a SIGABRT to be trapped by gdb, and tid-reuse does not reach the
after_count breakpoint:
Thread 2 "tid-reuse" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff7518700 (LWP 10368)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_count
After that, tid-reuse.exp gets the value of reuse_time, but this one kept its
initial value of -1 (as unsigned) :
print reuse_time
$1 = 4294967295
(gdb) PASS: gdb.threads/tid-reuse.exp: get reuse_time
tid-reuse then dies, and the .exp script continues (with some FAIL)
till it executes:
set timeout [expr $reuse_time * 2]
leading to the error:
(gdb) ERROR: integer value too large to represent as non-long integer
while executing
"expect {
-i exp8 -timeout 8589934590
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_intern..."
("uplevel" body line 1)
invoked from within
"uplevel $body" ARITH IOVERFLOW {integer value too large to represent as non-long integer} integer value too large to represent as non-long integer
ERROR: GDB process no longer exists
and then everything blocks.
This last 'GDB process no longer exists' is strange, as I still see the gdb
when this all blocks, e.g.
philippe 16058 31085 0 20:30 pts/15 00:00:00 /bin/bash -c rootme=`pwd`; export rootme; srcdir=../../../binutils-gdb/gdb/testsuite ; export srcdir ; EXPECT=`if [
philippe 16386 16058 0 20:30 pts/15 00:00:00 expect -- /usr/share/dejagnu/runtest.exp --status GDB_PARALLEL=yes --outdir=outputs/gdb.threads/tid-reuse gdb.thre
philippe 24848 16386 0 20:30 pts/20 00:00:00 /bd/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /bd/home/philip
This patch gives a default value of 60, so that if ever something wrong happens
in tid-reuse, then the value retrieved by the .exp script stays in a reasonable
range.
Simon verified the patch by:
"I replaced the pthread_create call with the value 1 to simulate a
failure, and the test succeeds to fail quickly with your patch applied.
Without your patch, I get the infinite hang that you describe."
Compared to V1:
As suggested by Pedro, this version checks the pthread calls return
code (in particular of pthread_create) and reports the failure reason,
instead of just aborting.
gdb/testsuite/ChangeLog
2018-12-09 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.threads/tid-reuse.c (REUSE_TIME_CAP): Declare as 60.
(reuse_time): Initialize to REUSE_TIME_CAP.
(check_rc): New function.
(main): Use REUSE_TIME_CAP instead of hardcoded 60.
Check pthread_create rc.
(spawner_thread_func): Check pthread_create and pthread_join rc.
|
|
On some systems where ncurses is only available in the "wide" version
(compiled with --with-widec), there might be no libtinfo.so, only a
libtinfow.so. Look for libtinfow in addition to libtinfo.
gdb/ChangeLog:
YYYY-MM-DD Simon Marchi <simon.marchi@ericsson.com>
Дилян Палаузов <dilyan.palauzov@aegee.org>
PR gdb/23950
* configure.ac: Search for tgetent in libtinfow.
* configure: Re-generate.
|
|
internal process handle.
Valgrind reports the below leak:
==25327== VALGRIND_GDB_ERROR_BEGIN
==25327== 672 bytes in 1 blocks are definitely lost in loss record 2,759 of 3,251
==25327== at 0x4C2E07C: calloc (vg_replace_malloc.c:752)
==25327== by 0x7FDCB3E: ???
==25327== by 0x532A7A: try_thread_db_load_1 (linux-thread-db.c:828)
==25327== by 0x532A7A: try_thread_db_load(char const*, int) (linux-thread-db.c:997)
==25327== by 0x53354D: try_thread_db_load_from_sdir (linux-thread-db.c:1074)
==25327== by 0x53354D: thread_db_load_search (linux-thread-db.c:1129)
==25327== by 0x53354D: thread_db_load() (linux-thread-db.c:1187)
==25327== by 0x611AF1: operator() (functional:2127)
==25327== by 0x611AF1: notify (observable.h:106)
==25327== by 0x611AF1: symbol_file_add_with_addrs(bfd*, char const*, enum_flags<symfile_add_flag>, std::vector<other_sections, std::allocator<other_sections> >*, enum_flags<objfile_flag>, objfile*) (symfile.c:1158)
==25327== by 0x5F5C4A: solib_read_symbols(so_list*, enum_flags<symfile_add_flag>) (solib.c:691)
==25327== by 0x5F6A8B: solib_add(char const*, int, int) (solib.c:1003)
==25327== by 0x5F6BF7: handle_solib_event() (solib.c:1281)
==25327== by 0x3D0A94: bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const*, bpstats*) (breakpoint.c:5417)
==25327== by 0x4FF133: handle_signal_stop(execution_control_state*) (infrun.c:5874)
==25327== by 0x502C29: handle_inferior_event_1 (infrun.c:5300)
==25327== by 0x502C29: handle_inferior_event(execution_control_state*) (infrun.c:5335)
==25327== by 0x5041DB: fetch_inferior_event(void*) (infrun.c:3868)
==25327== by 0x4A1E7C: gdb_wait_for_event(int) (event-loop.c:859)
...
This leak is created because a call to td_ta_new allocates some resources
that must be freed with td_ta_delete, and that was missing.
With this patch, the nr of GDB executions leaking during regression tests
decreases further from 566 to 380.
Note that the gdbserver equivalent code is properly calling
td_ta_delete: see thread_db_mourn in thread-db.c.
Tests run natively on debian/amd64, and run under valgrind.
gdb/ChangeLog
2018-12-08 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* linux-thread-db.c (struct thread_db_info): Add td_ta_delete_p.
(thread_db_err_str): Forward declare.
(delete_thread_db_info): Call td_ta_delete_p if available.
(try_thread_db_load_1): Acquire td_ta_delete address.
* nat/gdb_thread_db.h (td_ta_delete_ftype): Declare.
|
|
Back in:
commit 85ae1317add94adef4817927e89cff80b92813dd
Author: Stan Shebs <shebs@codesourcery.com>
AuthorDate: Thu Dec 8 02:27:47 1994 +0000
* source.c: Various cosmetic changes.
(forward_search_command): Handle very long source lines correctly.
a buffer with a hard limit was converted to a heap buffer:
@@ -1228,15 +1284,26 @@ forward_search_command (regex, from_tty)
stream = fdopen (desc, FOPEN_RT);
clearerr (stream);
while (1) {
-/* FIXME!!! We walk right off the end of buf if we get a long line!!! */
- char buf[4096]; /* Should be reasonable??? */
- register char *p = buf;
+ static char *buf = NULL;
+ register char *p;
+ int cursize, newsize;
+
+ cursize = 256;
+ buf = xmalloc (cursize);
+ p = buf;
However, reverse_search_command has the exact same problem, and that
wasn't fixed. We still have that "we walk right off" comment...
Recently, the xmalloc above was replaced with a xrealloc, because as
can be seen above, that 'buf' variable above was a static local,
otherwise we'd be leaking. This commit replaces that and the
associated manual buffer growing with a gdb::def_vector<char>. I
don't think there's much point in reusing the buffer across command
invocations.
While doing this, I realized that reverse_search_command is almost
identical to forward_search_command. So this commit factors out a
common helper function instead of duplicating a lot of code.
There are some tests for "forward-search" in gdb.base/list.exp, but
since they use the "search" alias, they were a bit harder to find than
expected. That's now fixed, both by testing both variants, and by
adding some commentary. Also, there are no tests for the
"reverse-search" command, so this commit adds some for that too.
gdb/ChangeLog:
2018-12-08 Pedro Alves <palves@redhat.com>
* source.c (forward_search_command): Rename to ...
(search_command_helper): ... this. Add 'forward' parameter.
Tweak to use a gdb::def_vector<char> instead of a xrealloc'ed
buffer. Handle backward searches too.
(forward_search_command, reverse_search_command): Reimplement by
calling search_command_helper.
gdb/testsuite/ChangeLog:
2018-12-08 Pedro Alves <palves@redhat.com>
* gdb.base/list.exp (test_forward_search): Rename to ...
(test_forward_reverse_search): ... this. Also test reverse-search
and the forward-search alias.
|
|
The current .dir-locals file for GDB causes files that would usually
open in c-mode (for example, files ending in .c) to open in c++-mode.
However, all of the other settings applied for c-mode appear to get
reset when the file is switched over to c++-mode.
For example, we currently say:
(c-mode . ((c-file-style . "GNU")
(mode . c++)
(indent-tabs-mode . t)
(tab-width . 8)
(c-basic-offset . 2)
(eval . (c-set-offset 'innamespace 0))
))
(c++-mode . ((eval . (when (fboundp 'c-toggle-comment-style)
(c-toggle-comment-style 1)))))
So, when we enter c++-mode `indent-tabs-mode` is reset to its global
value, as are all of the other settings listed for c-mode.
This commit copies all of the settings (except the `mode` setting)
from the c-mode list to the c++-mode list.
The emacs documentation doesn't mention that `mode` causes this
resetting behaviour, so, in case this is an emacs bug, I'm using emacs
version 26.1. Having the settings duplicated shouldn't cause any
problems except for a slight maintenance overhead.
gdb/ChangeLog:
* .dir-locals.el: Copy most of the settings from c-mode over to
c++-mode.
|
|
Up until now OpenRISC GDB only has supported bare metal debugging. This
patch adds linux userspace debugging and core dump analysis support.
The changes are loosely based on nios2 and riscv implementations.
This was tested with linux 4.20 core dumps for executables linked
against musl libc.
bfd/ChangeLog:
* elf32-or1k.c (or1k_grok_prstatus): New function.
(or1k_grok_psinfo): Likewise.
gdb/ChangeLog:
* Makefile.in (ALL_TARGET_OBS): Add or1k-linux-tdep.o.
* configure.tgt: Add or1k*-*-linux*.
* or1k-linux-tdep.c: New file.
* or1k-tdep.c (or1k_gdbarch_init): Call gdbarch_init_osabi.
|
|
Building for x86_64/-m32 with --enable-64-bit-bfd, compilation fails
with:
src/gdb/dwarf2read.c: In instantiation of ‘gdb::array_view<const unsigned char> get_gdb_index_contents_from_section(objfile*, T*) [with T = dwarf2_per_objfile]’:
src/gdb/dwarf2read.c:6266:54: required from here
src/gdb/dwarf2read.c:6192:37: error: narrowing conversion of ‘section->dwarf2_section_info::size’ from ‘bfd_size_type {aka long long unsigned int}’ to ‘size_t {aka unsigned int}’ inside { } [-Werror=narrowing]
return {section->buffer, section->size};
~~~~~~~~~^~~~
This fixes it.
gdb/ChangeLog:
2018-12-07 Pedro Alves <palves@redhat.com>
* dwarf2read.c (get_gdb_index_contents_from_section): Use
gdb::make_array_view.
|
|
Valgrind detects the following leak:
==28395== VALGRIND_GDB_ERROR_BEGIN
==28395== 5 bytes in 1 blocks are definitely lost in loss record 20 of 2,770
==28395== at 0x4C2BE2D: malloc (vg_replace_malloc.c:299)
==28395== by 0x41D9E7: xmalloc (common-utils.c:44)
==28395== by 0x78BF39: xstrdup (xstrdup.c:34)
==28395== by 0x51F1AC: _initialize_language() (language.c:1175)
==28395== by 0x6B3356: initialize_all_files() (init.c:308)
==28395== by 0x66D194: gdb_init(char*) (top.c:2159)
==28395== by 0x554C11: captured_main_1 (main.c:863)
==28395== by 0x554C11: captured_main (main.c:1167)
==28395== by 0x554C11: gdb_main(captured_main_args*) (main.c:1193)
==28395== by 0x29D837: main (gdb.c:32)
==28395==
==28395== VALGRIND_GDB_ERROR_END
This is a very small leak (1 block/5 bytes), happening only once
per GDB startup as far as I can see. But this fix make the nr of leaking
GDB in the testsuite decreasing from 628 to 566.
It is unclear why a xstrdup-ed value is assigned to 'language'
at initialization time, while a static "auto" string is assigned
as part of the set_language_command.
So, that shows that it is ok to initialize 'language' directly
with "auto".
Also, I cannot find any place where 'language' is xfree-d.
No leak was detected for 'range' and 'case_sensitive', but
similarly, no indication why a static string cannot be assigned.
Regression-tested on debian/x86_64.
Also, full testsuite run under valgrind, less tests leaking,
and no dangling pointer problem detected.
gdb/ChangeLog
2018-12-05 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* language.c (_initialize_language): Fix leak by assigning
a static string to language. Same for range and case_sensitive,
even if no leak is detected for these variables.
|
|
Not all sed implementations support alternation via \| in the default
regular expressions. Instead, resort to separate sed expressions via
-e for $debugdir and $datadir. This fixes the default setting of the
auto-load directories on FreeBSD. Previously on FreeBSD the sed
invocation was a no-op causing the debugdir and datadir values to be
expanded yielding an autoload path of ':${prefix}/share/gdb'.
gdb/ChangeLog:
* configure: Re-generate.
* configure.ac: Use separate sed expressions to escape variables
in auto-load directories.
|
|
Currently, if the target announces that it has floating point
registers in its target description then GDB assumes that the hardware
float ABI should be used. However, there's nothing stopping a user
compiling a program for the soft-float abi, and then trying to run
this on a target with hardware floating point registers.
This commit adjusts the logic that decides if GDB should use the
hardware float abi. The primary decision now is based on what the ELF
currently being executed says in its headers. If the file was
compiled for h/w float abi, then GDB uses h/w float abi, otherwise s/w
float is used.
If the current BFD is not an ELF then we don't currently have a
mechanism for figuring out if the file was compiled for float or not.
In this case we disable the h/w float abi. This shouldn't be a
problem as, right now, the RISC-V linker can only produce ELFs.
If there is NO current BFD (can this happen?) then we will enable h/w
float abi if the target has floating point hardware, otherwise, s/w
float abi is used.
This commit also adds some sanity checking that the features requested
in the BFD (xlen and flen) match the target description.
For testing I ran the testsuite on a target that returns a target
description containing both integer and floating point registers, but
used a compiler that didn't have floating point support. Before this
commit I would see failures on may tests that made inferior calls
using floating point arguments, after this commit, all of these issues
are resolved. One example from the testsuite is
gdb.base/infcall-nested-structs.exp.
gdb/ChangeLog:
* riscv-tdep.c (riscv_features_from_gdbarch_info): New function.
(riscv_find_default_target_description): Use new function to
extract feature from gdbarch_info.
(riscv_gdbarch_init): Add error checks for xlen and flen between
target description and bfd headers. Be smarter about when we
think the hardware floating point abi should be used.
|
|
In the config/sim.exp file two functions are defined. Both of these
functions define local timeout variables and then call gdb_expect,
which (through a call to get_largest_timeout) will find the local
definition of timeout.
However, both of these functions set the local timeout to some
arbitrary value and print a log message for this "new" timeout just
before returning.
As in both cases, the timeout is a local variable, this final setting
of the timeout has no effect and can be removed.
As having log messages about the timeout being adjusted could cause
confusion I've removed all logging related to timeouts in this
function, timeouts are adjusted throughout the testsuite without any
logging, there doesn't seem to be any good reason why these functions
should get their own logging.
With the logging gone there seems to be little need to a local timeout
variable at all, and so I've folded the local timeout directly into
the call to gdb_expect.
gdb/testsuite/ChangeLog:
* config/sim.exp (gdb_target_sim): Remove redundant adjustment of
local timeout variable before return, and remove all local timeout
variable entirely.
(gdb_load): Likewise.
|
|
On some heavily loaded AArch64 boxes, GDB will sometimes hang forever when
the inferior creates a thread. This hang happens inside the kernel during
the ptrace call to set hardware watchpoints or hardware breakpoints.
Currently, GDB will always set hw wp/bp at the start of each thread even if
there are none set in the process.
This patch works around the issue by avoiding setting hw wp/bp if there
are none set for the process.
On an effected machine, this fix drastically reduces the racy nature of the
gdb.threads test set. I ran the entire gdb test suite across all processors
for 100 iterations, then ran the results through the racy tests script.
Without the patch, 58 .exp files in gdb.threads were marked as racy. After
the patch this reduced to the same ~14 tests as the non effected boxes.
Clearly GDB will still be subject to hangs on an effect box if hw wp/bp's are
used prior to creating inferior threads on a heavily loaded system.
To enable this in gdbserver, the sequence in gdbserver add_lwp() is switched
to the same as gdb order as gdb, to ensure the thread is registered before
calling new_thread(). This allows aarch64_linux_new_thread() to read the
ptid.
gdb/ChangeLog:
* nat/aarch64-linux-hw-point.c
(aarch64_linux_any_set_debug_regs_state): New function.
* nat/aarch64-linux-hw-point.h
(aarch64_linux_any_set_debug_regs_state): New declaration.
* nat/aarch64-linux.c (aarch64_linux_new_thread): Check if any
BPs or WPs are set.
gdb/gdbserver/ChangeLog:
* linux-low.c (add_lwp): Switch ordering.
|
|
When caching a proc using gdb_caching_proc, it will become less likely to
be executed, and consequently it's going to be harder to detect that the
proc is racy. OTOH, in general the proc is easy to rerun. So, add a
test-case to run all uncached gdb_caching_procs a number of times and detect
inconsistent results.
The purpose of caching is to reduce runtime, so rerunning is somewhat
counter-productive in that aspect, but it's better than uncached, because the
number of reruns is constant-bounded, and the increase in runtime is bound to
this test-case, and can be disabled on slow targets.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2018-12-01 Tom de Vries <tdevries@suse.de>
* gdb.base/gdb-caching-proc.exp: New file.
|
|
kinfo_getfile() requires a couple of system calls to fetch the list of
open file descriptors. This can be much cheaper than invoking fstat
on all of the values from 0 to the open file resource limit maximum.
gdb/ChangeLog:
* common/filestuff.c [HAVE_KINFO_GETFILE]: Include headers.
(fdwalk) [HAVE_KINFO_GETFILE]: Use kinfo_getfile.
|
|
Valgrind reports this leak:
==798== VALGRIND_GDB_ERROR_BEGIN
==798== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 447 of 3,143
==798== at 0x4C2C48C: operator new(unsigned long) (vg_replace_malloc.c:334)
==798== by 0x51D401: linespec_parser_new(ls_parser*, int, language_defn const*, program_space*, symtab*, int, linespec_result*) (linespec.c:2756)
==798== by 0x524BF7: decode_line_full(event_location const*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3271)
==798== by 0x3E8893: parse_breakpoint_sals(event_location const*, linespec_result*) (breakpoint.c:9067)
==798== by 0x3E4E7F: create_breakpoint(gdbarch*, event_location const*, char const*, int, char const*, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) (breakpoint.c:9248)
==798== by 0x3E55F5: break_command_1(char const*, int, int) (breakpoint.c:9434)
==798== by 0x40BA68: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1888)
==798== by 0x665300: execute_command(char const*, int) (top.c:630)
...
linespec_parser_new allocates a std::vector<symtab *> at line 2756, and stores
the pointer to this vector in PARSER_RESULT (parser)->file_symtabs. At 3
different places in linespec.c, another std::vector is assigned to a
linespec->file_symtabs, without first deleting the current value.
The leak is fixed by assigning the vector itself instead of the pointer.
Everything should be moved, so there is no significant data copy
involved.
Tested on debian/amd64, + a bunch of tests re-run under valgrind
(including the test that throws an error).
gdb/ChangeLog:
* linespec.c (symtab_vector_up): Remove.
(symtabs_from_filename): Change return type to std::vector.
(collect_symtabs_from_filename): Likewise.
(create_sals_line_offset): Assign return value of
collect_symtabs_from_filename to *ls->file_symtabs.
(convert_explicit_location_to_linespec): Remove call to release.
(parse_linespec): Likewise.
(symtab_collector) <symtab_collector>: Remove initialization of
m_symtabs.
<release_symtabs>: Change return type to std::vector<symtab *>.
<operator ()>: Adjust.
|
|
Not all of the architecture-specific FreeBSD target files were
including the right headers to enable conditionals in fbsd-nat.h after
the C++ target conversion. As a result, certain operations like 'info
auxv' and 'p $_siginfo' were not working for some native targets
(noticed on RISC-V). Fix this in a couple of ways:
1) Declare fbsd_nat_target::xfer_partial unconditionally and only use
conditionals in the function body for individual target objects.
Originally this function was only used to read the ELF auxiliary
vector, so the entire function was conditional on a macro required
for that object (KERN_AUXV_PROC). However, xfer_partial has since
grown support for additional objects. Making the function
unconditional avoids needing to add the right header to fbsd-nat.h
and allows each target object to use independent requirements.
This did require using a more explicit conditional test for the
$_siginfo support. Removing the "outer" KERN_PROC_AUXV test
enabled $_siginfo for all kernels with PT_LWPINFO, but some older
kernels (FreeBSD 6.0) exposed PT_LWPINFO with a different siginfo
format. Instead use an explicit test for when the current siginfo
format was adopted (shipped in FreeBSD 7.0). This actually enables
$_siginfo on a wider range of kernels as KERN_PROC_AUXV wasn't
introduced until FreeBSD 9.1/10.0.
2) Include <sys/proc.h> in fbsd-nat.h for the definition of
TDP_RFPPWAIT that governs support for fork following.
gdb/ChangeLog:
* fbsd-nat.c [__FreeBSD_version >= 700009] (USE_SIGINFO): Macro
defined.
(union sigval32, struct siginfo32, fbsd_siginfo_size)
(fbsd_convert_siginfo): Make conditional on USE_SIGINFO instead
of KERN_PROC_AUXV and PT_LWPINFO.
(fbsd_nat_target::xfer_partial): Define method unconditionally.
Make TARGET_OBJECT_SIGNAL_INFO conditional on USE_SIGINFO.
Make TARGET_OBJECT_AUXV conditional on KERN_PROC_AUXV.
Make TARGET_OBJECT_FREEBSD_VMMAP and
TARGET_OBJECT_FREEBSD_PS_STRINGS conditional on KERN_PROC_VMMAP
and KERN_PROC_PS_STRINGS.
* fbsd-nat.h: Include <sys/proc.h>.
(fbsd_nat_target::xfer_partial): Declare method unconditionally.
|
|
Adds riscv_linux_nat_target::read_description method to find a
suitable target description for the native linux target we are running
on.
Currently this will supply a suitably sized set of x-registers, and
will probe the kernel to see if the f-registers are readable. If they
are readable then we currently assume that the f-registers are the
same size as the x-registers as I don't know of a good way to probe
the f-register length. This will obviously need fixing in future.
As of Linux 4.19 there is no ptrace support for reading the
f-registers, this should appear in 4.20, so right now we only return
target descriptions without f-registers.
gdb/ChangeLog:
* riscv-linux-nat.c: Add 'inferior.h' and 'target-descriptions.h'
header files.
(riscv_linux_nat_target::read_description): New method.
|
|
GDB relies on the fact that if two target descriptions have the same
contents, then they will be the same object instance (having the same
address). One place where this is a requirement is in
GDBARCH_LIST_LOOKUP_BY_INFO which is used to find previously created
gdbarch objects.
In GDBARCH_LIST_LOOKUP_BY_INFO a pointer comparison is made on the
gdbarch's target description, if the pointers are different then it is
assumed the gdbarches have different, non-compatible target
descriptions.
Previously we would create duplicate target descriptions in the belief
that RISCV_GDBARCH_INIT would spot this duplication and discard the
second instance. However, this was incorrect, and instead we ended up
creating duplicate gdbarch objects.
With this commit every unique feature set will create one and only one
target description, the feature set and resulting target description
is then cached so that the same target description object can be
returned later.
Many other target avoid this problem by creating a small number of
named target descriptions, and returning one of these. However, we
currently have 8 possible target descriptions (32 vs 64 bit for x-reg
and f-reg, and h/w or s/w float abi) and creating each of these just
to avoid a dynamic cache seems pointless.
gdb/ChangeLog:
* arch/riscv.h (riscv_gdbarch_features::hash): New method.
* arch/riscv.c (struct riscv_gdbarch_features_hasher): New.
(riscv_tdesc_cache): New global.
(riscv_create_target_description): Look in the cache before
creating a new target description.
|
|
Add '==' and '!=' operators for the struct riscv_gdb_features,
allowing a small simplification.
gdb/ChangeLog:
* arch/riscv.h (riscv_gdb_features::operator==): New.
(riscv_gdb_features::operator!=): New.
* riscv-tdep.c (riscv_gdbarch_init): Make use of the inequality
operator.
|
|
Makes more of the interface related to fetching target descriptions
constant.
gdb/ChangeLog:
* arch/riscv.h (riscv_create_target_description): Make return type
const.
* arch/riscv.c (riscv_create_target_description): Likewise.
* riscv-tdep.c (riscv_find_default_target_description): Likewise.
|
|
First of all, I would like to express my gratitude to Keith Seitz, Jan
Kratochvil and Tom Tromey, who were really kind and helped a lot with
this bug. The patch itself was authored by Jan.
This all began with:
https://bugzilla.redhat.com/show_bug.cgi?id=1639242
py-bt is broken, results in exception
In summary, the error reported by the bug above is:
$ gdb -args python3
GNU gdb (GDB) Fedora 8.1.1-3.fc28
(...)
Reading symbols from python3...Reading symbols from /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug...done.
done.
Dwarf Error: could not find partial DIE containing offset 0x316 [in module /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug]
After a long investigation, and after thinking that the problem might
actually be on DWZ's side, we were able to determine that there's
something wrong going on when
dwarf2read.c:dwarf2_find_containing_comp_unit performs a binary search
over all of the CUs belonging to an objfile in order to find the CU
which contains a DIE at an specific offset. The current algorithm is:
static struct dwarf2_per_cu_data *
dwarf2_find_containing_comp_unit (sect_offset sect_off,
unsigned int offset_in_dwz,
struct dwarf2_per_objfile *dwarf2_per_objfile)
{
struct dwarf2_per_cu_data *this_cu;
int low, high;
const sect_offset *cu_off;
low = 0;
high = dwarf2_per_objfile->all_comp_units.size () - 1;
while (high > low)
{
struct dwarf2_per_cu_data *mid_cu;
int mid = low + (high - low) / 2;
mid_cu = dwarf2_per_objfile->all_comp_units[mid];
cu_off = &mid_cu->sect_off;
if (mid_cu->is_dwz > offset_in_dwz
|| (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off))
high = mid;
else
low = mid + 1;
}
For the sake of this example, let's consider that "sect_off =
0x7d".
There are a few important things going on here. First,
"dwarf2_per_objfile->all_comp_units ()" will be sorted first by
whether the CU is a DWZ CU, and then by cu->sect_off. In this
specific bug, "offset_in_dwz" is false, which means that, for the most
part of the loop, we're going to do "high = mid" (i.e, we'll work with
the lower part of the vector).
In our particular case, when we reach the part where "mid_cu->is_dwz
== offset_in_dwz" (i.e, both are false), we end up with "high = 2" and
"mid = 1". I.e., there are only 2 elements in the vector who are not
DWZ. The vector looks like this:
#0: cu->sect_off = 0; length = 114; is_dwz = false <-- low
#1: cu->sect_off = 114; length = 7796; is_dwz = false <-- mid
#2: cu->sect_off = 0; length = 28; is_dwz = true <-- high
...
The CU we want is #1, which is exactly where "mid" is. Also, #1 is
not DWZ, which is also exactly what we want. So we perform the second
comparison:
(mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off)
^^^^^^^^^^^^^^^^^^^
Because "*cu_off = 114" and "sect_off = 0x7d", this evaluates to
false, so we end up with "low = mid + 1 = 2", which actually gives us
the wrong CU (i.e., a CU that is DWZ). Next in the code, GDB does:
gdb_assert (low == high);
this_cu = dwarf2_per_objfile->all_comp_units[low];
cu_off = &this_cu->sect_off;
if (this_cu->is_dwz != offset_in_dwz || *cu_off > sect_off)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{
if (low == 0 || this_cu->is_dwz != offset_in_dwz)
error (_("Dwarf Error: could not find partial DIE containing "
"offset %s [in module %s]"),
sect_offset_str (sect_off),
bfd_get_filename (dwarf2_per_objfile->objfile->obfd));
...
Triggering the error we saw in the original bug report.
It's important to notice that we see the error message because the
selected CU is a DWZ one, but we're looking for a non-DWZ CU here.
However, even when the selected CU is *not* a DWZ (and we don't see
any error message), we still end up with the wrong CU. For example,
suppose that the vector had:
#0: cu->sect_off = 0; length = 114; is_dwz = false
#1: cu->sect_off = 114; length = 7796; is_dwz = false
#2: cu->sect_off = 7910; length = 28; is_dwz = false
...
I.e., #2's "is_dwz" is false instead of true. In this case, we still
want #1, because that's where the DIE is located. After the loop ends
up in #2, we have "is_dwz" as false, which is what we wanted, so we
compare offsets. In this case, "7910 >= 0x7d", so we set "mid = high
= 2". Next iteration, we have "mid = 0 + (2 - 0) / 2 = 1", and thus
we examining #1. "is_dwz" is still false, but "114 >= 0x7d" also
evaluates to false, so "low = mid + 1 = 2", which makes the loop stop.
Therefore, we end up choosing #2 as our CU, even though #1 is the
right one.
The problem here is happening because we're comparing "sect_off"
directly against "*cu_off", while we should actually be comparing
against "*cu_off + mid_cu->length" (i.e., the end offset):
...
|| (mid_cu->is_dwz == offset_in_dwz
&& *cu_off + mid_cu->length >= sect_off))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
And this is what the patch does. The idea is that if GDB is searching
for an offset that falls above the *end* of the CU being
analyzed (i.e., "mid"), then the next iteration should try a
higher-offset CU next. The previous algorithm was using
the *beginning* of the CU.
Unfortunately, I could not devise a testcase for this problem, so I am
proposing a fix with this huge explanation attached to it in the hope
that it is sufficient. After talking a bit to Keith (our testcase
guru), it seems that one would have to create an objfile with both DWZ
and non-DWZ sections, which may prove very hard to do, I think.
I ran this patch on our BuildBot, and no regressions were detected.
gdb/ChangeLog:
2018-11-30 Jan Kratochvil <jan.kratochvil@redhat.com>
Keith Seitz <keiths@redhat.com>
Tom Tromey <tom@tromey.com>
Sergio Durigan Junior <sergiodj@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1613614
* dwarf2read.c (dwarf2_find_containing_comp_unit): Add
'mid_cu->length' to '*cu_off' when checking if 'sect_off' is
inside the CU.
|
|
Given that a target's stratum is a property of the type, and not of an
instance of the type, get rid of to_stratum data field and replace it
with a virtual method.
I.e., when we have e.g., 10 target remote instances active, there's no
need for each of the instances to have their own to_stratum copy.
gdb/ChangeLog:
2018-11-30 Pedro Alves <palves@redhat.com>
* aix-thread.c (aix_thread_target) <aix_thread_target>: Delete.
<stratum>: New override.
* bfd-target.c (aix_thread_target) <aix_thread_target>: Delete.
<stratum>: New override.
* bsd-uthread.c (bsd_uthread_target) <bsd_uthread_target>: Delete.
<stratum>: New override.
* exec.c (exec_target) <exec_target>: Delete.
<stratum>: New override.
* gdbarch-selftests.c (register_to_value_test): Adjust to use the
stratum method instead of the to_stratum field.
* linux-thread-db.c (thread_db_target) <thread_db_target>: Delete.
<stratum>: New override.
(thread_db_target::thread_db_target): Delete.
* make-target-delegates (print_class): Don't print a ctor
declaration. Print a stratum method override declaration.
* process-stratum-target.h (process_stratum_target)
<process_stratum_target>: Delete.
<stratum>: New override.
* ravenscar-thread.c (ravenscar_thread_target)
<ravenscar_thread_target>: Delete.
<stratum>: New override.
* record-btrace.c (record_btrace_target)
<record_btrace_target>: Delete.
<stratum>: New override.
* record-full.c (record_full_base_target)
<record_full_base_target>: Delete.
<stratum>: New override.
* record.c (record_disconnect, record_detach)
(record_mourn_inferior, record_kill): Adjust to use the stratum
method instead of the to_stratum field.
* regcache.c (cooked_read_test, cooked_write_test): Likewise.
* sol-thread.c (sol_thread_target)
<sol_thread_target>: Delete.
<stratum>: New override.
* spu-multiarch.c (spu_multiarch_target)
<spu_multiarch_target>: Delete.
<stratum>: New override.
* target-delegates.c: Regenerate.
* target.c (target_stack::push, target_stack::unpush)
(pop_all_targets_above, pop_all_targets_at_and_above)
(info_target_command, target_require_runnable)
(target_stack::find_beneath): Adjust to use the stratum method
instead of the to_stratum field.
(dummy_target::dummy_target): Delete.
(dummy_target::stratum): New.
(debug_target::debug_target): Delete.
(debug_target::stratum): New.
(maintenance_print_target_stack): Adjust to use the stratum method
instead of the to_stratum field.
* target.h (struct target_ops) <stratum>: New method.
<to_stratum>: Delete.
<is_pushed>: Adjust to use the stratum method
instead of the to_stratum field.
|
