It is possible for the created thread to reach the breakpoint before
the main thread has set errno to 23.
Prevent this using a pthread barrier.
* gdb.threads/check-libthread-db.c (thread_routine): Use a
pthread barrier.
(main): Likewise.
This commit improves the prologue scanning stack unwinder, to better
support AUIPC, LUI, and more variants of ADD and ADDI.
This allows unwinding over frames containing large local variables,
where the frame size does not fit into a single instruction immediate,
and is first loaded into a temporary register, before being added to
the stack pointer.
A new test is added that tests this behaviour. As there's nothing
truely RiscV specific about this test I've added it into gdb.base, but
as this depends on target specific code to perform the unwind it is
possible that some targets might fail this new test.
gdb/ChangeLog:
* riscv-tdep.c (riscv_insn::decode): Decode c.lui.
(riscv_scan_prologue): Split handling of AUIPC, LUI, ADD, ADDI,
and NOP.
gdb/testsuite/ChangeLog:
* gdb.base/large-frame-1.c: New file.
* gdb.base/large-frame-2.c: New file.
* gdb.base/large-frame.exp: New file.
* gdb.base/large-frame.h: New file.
It is unused, removing it fixes this error when building with clang:
/home/emaisin/src/binutils-gdb/bfd/elf32-nds32.c:3172:1: error: unused function 'elf32_nds32_allocate_dynrelocs' [-Werror,-Wunused-function]
elf32_nds32_allocate_dynrelocs (struct bfd_link_info *info, asection *sreloc,
^
1 error generated.
gcc only reports the error if you remove "inline". I don't know if this
is actually a mistake and it should actually be used though.
gdb/ChangeLog:
* elf32-nds32.c (elf32_nds32_allocate_dynrelocs): Remove.
This removes a variable definition in valops.c that has been
surrounded by "#if 0" since gdb moved to sourceware.
gdb/ChangeLog
2018-09-26 Tom Tromey <tom@tromey.com>
* valops.c (auto_abandon): Remove dead code.
I noticed that the usage string for "winheight" has a couple of
extraneous ">"s in it. I must have forgotten to remove these back
when I changed the text to use the GNU style for metasyntactic
variables.
gdb/ChangeLog
2018-09-26 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (WIN_HEIGHT_USAGE): Remove extra ">"s.
gdbserver's configure removes -Wmissing-prototypes from the warning
flags. However, this flag is only useful for C, so this deletion is
no longer needed.
gdb/gdbserver/ChangeLog
2018-09-25 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac (WARN_CFLAGS): Don't remove -Wmissing-prototypes.
When opening a BFD for update, as gdb --write does, modifications to
anything but the contents of sections is restricted.
Do not try to write back any ELF headers in this case.
bfd/ChangeLog
2018-09-24 Jozef Lawrynowicz <jozef.l@mittosystems.com>
PR gdb/20948
* elf.c (_bfd_elf_write_object_contents): Return from function
early if abfd->direction == both_direction.
gdb/testsuite/ChangeLog
2018-09-24 Jozef Lawrynowicz <jozef.l@mittosystems.com>
PR gdb/20948
* gdb.base/write_mem.exp: New test.
* gdb.base/write_mem.c: Likewise.
I noticed that some code in gdb was doing:
char *mumble = getenv (...)
However, using "const char *" here would be clearer.
This patch fixes the instances I could readily build.
Tested by rebuilding.
gdb/ChangeLog
2018-09-24 Tom Tromey <tom@tromey.com>
* common/pathstuff.c (get_standard_cache_dir): Make
"xdg_cache_home" and "home" const.
* top.c (init_history): Make "tmpenv" const.
* main.c (get_init_files): Make "homedir" const.
A convention in the Python layer is that raising a gdb.GdbError will
not print the Python stack -- instead the exception is treated as any
other gdb exception.
PR python/18852 asks that this treatment be extended the the
get_set_value method of gdb.Parameter. This makes sense, because it
lets Python-created parameters act like gdb parameters.
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/18852:
* python/py-param.c (get_set_value): Use gdbpy_handle_exception.
gdb/doc/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/18852:
* python.texi (Parameters In Python): Document exception behavior
of get_set_string.
gdb/testsuite/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/18852:
* gdb.python/py-parameter.exp: Add test for parameter that throws
on "set".
I noticed two nearly identical copies of the same code for handling
gdb.GdbError. The only differences were in some error messages.
These differences didn't seem very important, so this patch pulls the
code out into a new function.
2018-09-23 Tom Tromey <tom@tromey.com>
* python/py-function.c (fnpy_call): Use gdbpy_handle_exception.
* python/py-cmd.c (cmdpy_function): Use gdbpy_handle_exception.
* python/python-internal.h (gdbpy_handle_exception): Declare.
* python/py-utils.c (gdbpy_handle_exception): New function.
typy_template_argument did not check if the template argument was
non-negative. A negative value could cause a gdb crash.
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/17284:
* python/py-type.c (typy_template_argument): Check for negative
argument number.
gdb/testsuite/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/17284:
* gdb.python/py-template.exp (test_template_arg): Add test for
negative template argument number.
PR python/14062 points out that errors coming from the gdb.post_event
callback are not reported. This can make it hard to understand why
your Python code in gdb isn't working.
Because users have control over whether exceptions are printed at all,
it seems good to simply have post_event report errors in the usual
way.
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/14062:
* python/python.c (gdbpy_run_events): Do not ignore exceptions.
gdb/testsuite/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/14062:
* gdb.python/python.exp: Add test for post_event error.
PR python/18170 questions why it's not possible to convert a pointer
value to a Python int.
Digging a bit shows that the Python 2.7 int() constructor will happily
return a long in some cases. And, it seems gdb already understands
this in other places -- this is what gdb_py_object_from_longest
handles.
So, this patch simply extends valpy_int to allow pointer conversions,
as valpy_long does.
gdb/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/18170:
* python/py-value.c (valpy_int): Allow conversion from pointer
type.
gdb/testsuite/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/18170:
* gdb.python/py-value.exp (test_value_numeric_ops): Add tests to
convert pointers to int and long.
PR python/20126 points out that sometimes the conversion of a
gdb.Value can result in a negative Python integer. This happens
because valpy_int does not examine the signedness of the value's type.
gdb/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/20126:
* python/py-value.c (valpy_int): Respect type sign.
gdb/testsuite/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/20126:
* gdb.python/py-value.exp (test_value_numeric_ops): Add
signed-ness conversion tests.
PR python/18352 points out that the gdb Python code can't convert an
integer-valued gdb.Value to a Python float. While writing the test I
noticed that, similarly, converting integer gdb.Values to float does
not work. However, all of these cases seem reasonable.
gdb/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/18352;
* python/py-value.c (valpy_float): Allow conversions from int or
char.
(valpy_int, valpy_long): Allow conversions from float.
gdb/testsuite/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
PR python/18352;
* gdb.python/py-value.exp (test_float_conversion): New proc.
Use it.
I noticed a couple of spots in gdb that were opening files but not
marking the file descriptors as close-on-exec. This patch fixes
these.
There are still a few more of these, but they are in code that I can't
compile, so I'd prefer not to touch.
gdb/ChangeLog
2018-09-23 Tom Tromey <tom@tromey.com>
* ctf.c (ctf_start): Use gdb_fopen_cloexec.
* common/scoped_mmap.c (mmap_file): Use gdb_open_cloexec.
Unlike Solaris/SPARC, the __sighndlr function isn't recognized as part
of a signal handler, causing a couple of testcases to fail.
The following patch fixes that. A followup patch will move this to
common code to avoid such unnecessary discrepancies between
Solaris/SPARC and x86 in the future.
While this fixes a couple of backtraces to now correctly print
#1 <signal handler called>
they often fail later with
#2 0x0ff3ffffff00857f in ?? ()
Backtrace stopped: Cannot access memory at address 0xff3000002e0886f
which needs further investigation.
Tested on amd64-pc-solaris2.11 (running the tests with both -m64 and
-m32).
* amd64-sol2-tdep.c (amd64_sol2_sigtramp_p): Also recognize
__sighndlr.
* i386-sol2-tdep.c (i386_sol2_sigtramp_p): Likewise.
This causes the inferior to stop with SIGTTIN if it tries to read from the
terminal after it has been continued.
See https://cygwin.com/ml/cygwin/2016-09/msg00285.html for reproduction.
Since MinGW doesn't have a tcsetpgrp(), I don't think this problem would be
observed there, but Cygwin does so target_terminal::ours() will call it.
Calling target_terminal::ours() here seems to be is no longer appropriate
after the "Merge async and sync code paths" changes (as the inferior is now
in a separate process group even in sync mode(?), which is always used on
Windows targets)
This call was added in commit c44537cf (and see
https://sourceware.org/ml/gdb-patches/2007-02/msg00167.html for what it
fixed, which is not regressed by this change)
When windows_nat_target::wait() is entered, the inferior is running (either
it's been just been started or attached to, or windows_continue() was
called), so grabbing the controlling terminal away from it here seems to be
wrong, since infrun.c takes care of calling target_terminal::ours() when the
inferior stops.
gdb/ChangeLog:
2018-08-02 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (windows_nat_target::wait): Remove a spurious
target_terminal::ours().
When building with --enable-targets=all on macOS, I get this error:
CXX aarch64-linux-tdep.o
/Users/simark/src/binutils-gdb/gdb/aarch64-linux-tdep.c:328:7: error: no matching function for call to 'store_integer'
store_integer ((gdb_byte *)&vg_target, sizeof (uint64_t), byte_order,
^~~~~~~~~~~~~
/Users/simark/src/binutils-gdb/gdb/defs.h:556:13: note: candidate template ignored: requirement 'Or<is_same<unsigned long long, long>, is_same<unsigned long long, unsigned long> >::value' was not satisfied [with T = unsigned long long]
extern void store_integer (gdb_byte *addr, int len, enum bfd_endian byte_order,
^
I believe it's because uint64_t is defined as "unsigned long long" on macOS,
even though "unsigned long" is also 64 bits. Other 64-bits platforms define
uint64_t as "unsigned long".
This makes the type of the argument to store_integer (unsigned long long) not
match the requirement that it must be the same as ULONGEST, which is unsigned
long.
Fix it by changing the type of the vl variable to be ULONGEST, which is what
extract_unsigned_integer returns anyway.
gdb/ChangeLog:
* aarch64-linux-tdep.c (aarch64_linux_supply_sve_regset): Change type
of vl to ULONGEST.
This procfs.c (and friends) cleanup patch grew along a couple of lines:
* First I noticed that PR_MODEL_NATIVE is always defined now that
Solaris 10 is the minimum supported version.
* Then there was a cleanup that I'd missed when removing support for
!NEW_PROC_API, IRIX, and Tru64 UNIX: given that sysset_t is no longer
dynamic, there's no need for the special sysset_t_alloc, but we can
just use XNEW instead.
* Then I found one of those ARI warning mails on gdb-patches, discovered
how to run it myself and fixed a large number of the warnings, among
them all uses of sprintf.
I had to silence the warnings in only 3 instances of the same issue,
namely references to LDT in function names which are due to the
libthread_db API.
* Even so, there were several formatting glitches, like braces around
single statements in an if, which I chose to fix while I was at it.
The result has been tested on amd64-pc-solaris2.11 and
amd64-pc-solaris2.11.
* proc-utils.h (PROC_CTL_WORD_TYPE): Remove.
* procfs.c: Don't check for PR_MODEL_NATIVE definition.
* sparc-sol2-nat.c: Likewise. Remove Linux, __arch64__ references.
* sol-thread.c (ps_pdmodel): Don't guard definition.
* procfs.c: Fix formatting.
* procfs.c (sysset_t_alloc): Remove.
(create_procinfo): Use XNEW instead of sysset_t_alloc.
(procfs_debug_inferior): Likewise.
(procfs_set_exec_trap): Likewise.
(proc_set_traced_sysentry): Don't allocate argp dynamically.
(proc_set_traced_sysexit): Likewise.
* procfs.c (create_procinfo): Use xsnprintf to fix ARI warning.
(dead_procinfo): Likewise.
(proc_warn): Likewise.
(proc_error): Likewise.
(proc_get_LDT_entry): Likewise.
(do_attach): Likewise.
(procfs_target::pid_to_str): Likewise.
(iterate_over_mappings): Likewise.
* procfs.c (create_procinfo): Fix ARI warning.
(proc_get_status): Likewise.
(proc_stop_process): Likewise.
(proc_run_process): Likewise.
(proc_kill): Likewise.
(proc_get_LDT_entry): Likewise.
(procfs_find_LDT_entry): Likewise.
(proc_update_threads): Likewise.
(proc_iterate_over_threads): Likewise.
(do_attach): Likewise.
(procfs_xfer_memory): Likewise.
(invalidate_cache): Likewise.
(procfs_target::resume): Likewise.
(procfs_init_inferior): Likewise.
(procfs_set_exec_trap): Likewise.
(procfs_target::thread_alive): Likewise.
(procfs_target::pid_to_exec_file): Likewise.
(iterate_over_mappings): Likewise.
(procfs_target::make_corefile_notes): Likewise.
* sol-thread.c (sol_thread_target::thread_alive): Likewise.
* procfs.c (procfs_find_LDT_entry): Silence ARI warning.
(procfs_find_LDT_entry): Likewise.
* sol-thread.c (ps_lgetLDT): Likewise.
I was looking at GDB testcase results for arm-eabi target with qemu and
noticed that register groups returned by the qemu can have '_' in the
name e.g. 'cp_regs'. The reggroups.exp fails to recognize that as group
name. Fixed by adding '_' in the pattern.
2018-09-20 Hafiz Abid Qadeer <abidh@codesourcery.com>
gdb.base/reggroups.exp (fetch_reggroups): Add '_' in match pattern.
While looking through gdb.log, I found that two tests FAIL like this:
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x00400dc4 in ?? ()
(gdb) FAIL: gdb.base/attach.exp: attach2, with no file
The other is gdb.base/quit-live.exp. I've implemented the following
patch that fixes both failures, only then detecting that I'd previously
reported the issue as PR tdep/17903.
Tested on amd64-pc-solaris2.10 and amd64-pc-solaris2.11.
PR tdep/17903
* procfs.c (procfs_target): Declare pid_to_exec_file.
(procfs_target::pid_to_exec_file): New.
Currently, three tests FAIL on Solaris 11.4+ (amd64-pc-solaris2.11 and
sparcv9-sun-solaris2.11):
info auxv
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
FAIL: gdb.base/auxv.exp: info auxv on live process
info auxv
4294969310 ??? 0x7fffbfffe410
9225589753816 ??? 0x7fffbfffe45c
[...]
WARNING: Unrecognized tag value: 4294969310 ??? 0x7fffbfffe410
WARNING: Unrecognized tag value: 9225589753816 ??? 0x7fffbfffe45c
WARNING: Unrecognized tag value: 140733193388037 ??? 0x6
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
UNRESOLVED: gdb.base/auxv.exp: info auxv on native core dump
info auxv
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
FAIL: gdb.base/auxv.exp: info auxv on gcore-created dump
The following patch fixes this by introducing the missing AT_SUN_*
values from Solaris 11.4+ <sys/auxv.h>. This lets the live and
gcore-created dump tests PASS.
I don't know yet what's the reason for those weird 'Unrecognized tag
value' warnings with native core dumps is; elfdump -n certainly doesn't
show them. However, native core dumps still need quite some work
(mostly in bfd) in this and other areas.
Tested on amd64-pc-solaris2.11.
gdb:
* auxv.c (default_print_auxv_entry): Reflect AT_SUN_CAP_HW1
renaming.
Handle AT_SUN_EMULATOR, AT_SUN_BRANDNAME, AT_SUN_BRAND_AUX1,
AT_SUN_BRAND_AUX2, AT_SUN_BRAND_AUX3, AT_SUN_CAP_HW2.
include:
* elf/common.h (AT_SUN_HWCAP): Rename to ...
(AT_SUN_CAP_HW1): ... this. Retain old name for backward
compatibility.
(AT_SUN_EMULATOR, AT_SUN_BRANDNAME, AT_SUN_BRAND_AUX1)
(AT_SUN_BRAND_AUX2, AT_SUN_BRAND_AUX3, AT_SUN_CAP_HW2): Define.
I've been carrying around the following patch for some time. I noticed
that both i386-sol2-nat.c and i386-v4-nat.c are Solaris-only now and it
seems confusing to carry both around.
So this patch merges i386-v4-nat.c into i386-sol2-nat.c, simplifying it
in a couple of places, like removing checks for macros that are always
defined.
Tested on 64-bit Solaris 11.5/x86 (amd64-pc-solaris2.11) and 32-bit
Solaris 11.3/x86 (i386-pc-solaris2.11) half a year ago.
* i386-v4-nat.c (regmap, supply_gregset, fill_gregset)
(supply_fpregset, fill_fpregset): Move ...
* i386-sol2-nat.c [PR_MODEL_NATIVE != PR_MODEL_LP64]: ... here.
Remove HAVE_GREGSET_T, HAVE_FPREGET_T guards.
Remove references to ioctl-based procfs.
Include <sys/reg.h>.
Remove PR_MODEL_NATIVE guards.
* configure.nat <sol2, i386> (NATDEPFILES): Remove i386-v4-nat.o.
* Makefile.in (ALLDEPFILES): Remove i386-v4-nat.c.
On Darwin, debugging an helloworld program with GDB does
not work and ends with:
(gdb) set startup-with-shell off
(gdb) start
Temporary breakpoint 1 at 0x100000fb4: file /tmp/helloworld.c, line 1.
Starting program: /private/tmp/helloworld
[New Thread 0x2703 of process 18906]
[New Thread 0x2603 of process 18906]
[1]+ Stopped ./gdb/gdb /tmp/helloworld
When debugging with lldb, instead of having the STOP signal, we can
see that a breakpoint is not set to a proper location:
Warning:
Cannot insert breakpoint -1.
Cannot access memory at address 0xf726
Command aborted.
The inserted breakpoint is the one used when GDB has to stop the target
when a shared library is loaded or unloaded. The notifier address used
for adding the breakpoint is wrong thus the above failure.
This notifier address is an offset relative to dyld base address, so
the value calculation has to be updated to reflect this.
This was tested on High Sierra by trying to run a simple "hello world"
program.
gdb/ChangeLog:
PR gdb/20981:
* solib-darwin.c (darwin_get_dyld_bfd): New function.
(darwin_solib_get_all_image_info_addr_at_init): Update call.
(darwin_handle_solib_event): New function.
(darwin_solib_create_inferior_hook): Handle unrelocated dyld.
Change-Id: I7dde5008c9158f17b78dc89bd7f4bd8a12d4a6e1
When evaluating Fortran expressions such as the following:
print truth_table(1,1) .OR. truth_table(2,1)
where truth_table(1,1) evaluates to true, the debugger would report that
it could not perform substring operations on this type. This patch
addresses this issue.
Investigation revealed that EVAL_SKIP was not being handled correctly
for all types serviced by the OP_F77_UNDETERMINED_ARGLIST case in
evaluate_subexp_standard. While skipping an undetermined argument list
the type is resolved to be an integer (as this is what evaluate_subexp
returns when skipping) and so it was not possible to delegate to the
appropriate case (e.g. array, function call).
The solution implemented here updates OP_VAR_VALUE to return correct
type information when skipping. This way OP_F77_UNDETERMINED_ARGLIST
can delegate the skipping to the appropriate case or routine, which
should know how to skip/evaluate the type in question.
koenig.exp was updated to include a testcase which exercises the
modified skip logic in OP_VAR_VALUE, as it falls through from
OP_ADL_FUNC.
This patch has been tested for regressions with GCC 7.3 on aarch64,
ppc64le and x86_64.
gdb/ChangeLog:
* eval.c (skip_undetermined_arglist): Skip argument list helper.
(evaluate_subexp_standard): Return a dummy type when
honoring EVAL_SKIP in OP_VAR_VALUE and handle skipping in the
OP_F77_UNDETERMINED_ARGLIST case.
* expression.h (enum noside): Update comment.
gdb/testsuite/ChangeLog:
* gdb.cp/koenig.exp: Extend to test logical short circuiting.
* gdb.fortran/short-circuit-argument-list.exp: New file.
* gdb.fortran/short-circuit-argument-list.f90: New test.
The next patch from the solaris-userland github repo
https://github.com/oracle/solaris-userland/tree/master/components/gdb/patches
(007-solib-svr4.patch) is equally trivial, creating partity between
Solaris/SPARC and x86.
Tested on amd64-pc-solaris2.11.
2018-09-19 George Vasick <george.vasick@oracle.com>
* solib-svr4.c (svr4_same_1): Also handle amd64 ld.so.1.
I'm slowly working my way through the gdb patches from the
solaris-userland repo
https://github.com/oracle/solaris-userland/tree/master/components/gdb/patches
This one (001-fix-proc-name-size.patch) should be obvious given the
patches' comment:
# In Solaris, PID_MAX is 999999 (6 digit pid).
# In Solaris, lwpid_t is an unsigned int, so theoretically the lwp id
# could be 10 digits.
Tested on i386-pc-solaris2.11.
2018-09-19 Stefan Teleman <stefan.teleman@oracle.com>
April Chin <april.chin@oracle.com>
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* procfs.c (MAX_PROC_NAME_SIZE): Allow for 6-digit PID_MAX and
uint_t lwpid_t.
(create_procinfo): Print pids in /proc without leading zeros.
Commit
e2fc52e745 ("Fix PR gdb/23558: Use system's 'getcwd' when cross-compiling GDB")
backported some changes from a future gnulib version to our import.
However, this means that every time someone wants to change our gnulib
import (e.g. add a module), they must make sure not to include that
backported change. It also means that someone running the
update-gnulib.sh script without changes will get some diffs and wonder
why.
Instead, I suggest we carry that backport as a patch applied by the
update-gnulib.sh script after running the import tool. It will make it
clear what backport or local modification we have and should make
running update-gnulib.sh give a reproducible result.
There is a hunk in the configure file in this patch, this is because the
commit that backported the getcwd bits didn't include the re-generated
configure.
Note: you'll need this patch as well to get deterministic results:
Generate aclocal-m4-deps.mk more deterministically and portably.
https://sourceware.org/ml/gdb-patches/2018-09/msg00643.html
gdb/ChangeLog:
* patches/0001-Fix-PR-gdb-23558-Use-system-s-getcwd-when-cross-comp.patch:
New file.
* update-gnulib.sh: Apply patch.
* configure: Re-generate.
Remove "running" in a few places since "info proc" can be used with
core dumps as well as running processes on both Linux and FreeBSD.
Use "the specified process" in the description of most "info proc"
subcommands.
Use "additional information" instead of "/proc process information" in
the "info proc" description to more closely match the language in the
manual.
gdb/ChangeLog:
* infcmd.c (_initialize_infcmd): Remove "running" from "info proc"
description. Make "info proc" command descriptions more
consistent.
gdb/doc/ChangeLog:
* gdb.texinfo (info proc): Remove "running".
(info proc mappings): Replace "program" with "process".
This walks the list of struct kinfo_file objects returned by a call to
kinfo_getfile outputting a description of each open file descriptor.
gdb/ChangeLog:
* fbsd-nat.c (fbsd_nat_target::info_proc): List open file
descriptors for IP_FILES and IP_ALL.
Walk the list of struct kinfo_file objects in the
NT_FREEBSD_PROCSTAT_FILES core dump note outputting a description of
each open file descriptor. For sockets, the local and remote socket
addresses are displayed in place of the file name field. For UNIX
local domain sockets, only a single address is displayed since most
UNIX sockets only have one valid address and printing both pathnames
could be quite long. The output format was somewhat inspired by the
output of the "procstat -f" command on FreeBSD, but with a few less
details and some fields were condensed.
gdb/ChangeLog:
* fbsd-tdep.c (KF_FLAGS, KF_OFFSET, KF_VNODE_TYPE, KF_SOCK_DOMAIN)
(KF_SOCK_TYPE, KF_SOCK_PROTOCOL, KF_SA_LOCAL, KF_SA_PEER)
(KINFO_FILE_TYPE_SOCKET, KINFO_FILE_TYPE_PIPE)
(KINFO_FILE_TYPE_FIFO, KINFO_FILE_TYPE_KQUEUE)
(KINFO_FILE_TYPE_CRYPTO, KINFO_FILE_TYPE_MQUEUE)
(KINFO_FILE_TYPE_SHM, KINFO_FILE_TYPE_SEM, KINFO_FILE_TYPE_PTS)
(KINFO_FILE_TYPE_PROCDESC, KINFO_FILE_FD_TYPE_ROOT)
(KINFO_FILE_FD_TYPE_JAIL, KINFO_FILE_FD_TYPE_TRACE)
(KINFO_FILE_FD_TYPE_CTTY, KINFO_FILE_FLAG_READ)
(KINFO_FILE_FLAG_WRITE, KINFO_FILE_FLAG_APPEND)
(KINFO_FILE_FLAG_ASYNC, KINFO_FILE_FLAG_FSYNC)
(KINFO_FILE_FLAG_NONBLOCK, KINFO_FILE_FLAG_DIRECT)
(KINFO_FILE_FLAG_HASLOCK, KINFO_FILE_FLAG_EXEC)
(KINFO_FILE_VTYPE_VREG, KINFO_FILE_VTYPE_VDIR)
(KINFO_FILE_VTYPE_VCHR, KINFO_FILE_VTYPE_VLNK)
(KINFO_FILE_VTYPE_VSOCK, KINFO_FILE_VTYPE_VFIFO, FBSD_AF_UNIX)
(FBSD_AF_INET, FBSD_AF_INET6, FBSD_SOCK_STREAM, FBSD_SOCK_DGRAM)
(FBSD_SOCK_SEQPACKET, FBSD_IPPROTO_ICMP, FBSD_IPPROTO_TCP)
(FBSD_IPPROTO_UDP, FBSD_IPPROTO_SCTP): New defines.
(struct fbsd_sockaddr_in, struct fbsd_sockaddr_in6)
(struct fbsd_sockaddr_un): New types.
(fbsd_file_fd, fbsd_file_type, fbsd_file_flags, fbsd_ipproto)
(fbsd_print_sockaddr_in, fbsd_print_sockaddr_in6)
(fbsd_info_proc_files_header, fbsd_info_proc_files_entry)
(fbsd_core_info_proc_files): New functions.
(fbsd_core_info_proc): List open file descriptors for IP_FILES and
IP_ALL.
* fbsd-tdep.h (fbsd_info_proc_files_header)
(fbsd_info_proc_files_entry): New.
This command displays a list of open file descriptors.
gdb/ChangeLog:
* defs.h (enum info_proc_what) [IP_FILES]: New value.
* infcmd.c (info_proc_cmd_files): New function.
(_initialize_infcmd): Register 'info proc files' command.
Sort the list of files generated by find to make the order of the
entries deterministic. When sorting, use explicit "C" collation. Use
an explicit tab character instead of '\t' as some sed implementations
treat '\t' as an escaped 't' instead of a tab.
gdb/ChangeLog:
* gnulib/aclocal-m4-deps.mk: New file.
* gnulib/update-gnulib.sh: Generate "aclocal-m4-deps.mk"
deterministically.
fbsd_core_vnode_path needs to use the offset of the kf_path member of
struct kinfo_file as the minimum size of a struct kinfo_file object.
However, it was using KVE_PATH instead due to a copy and paste bug.
While here, fix another copy and paste bug in the error message for a
truncated kinfo_file object.
gdb/ChangeLog:
* fbsd-tdep.c (fbsd_core_vnode_path): Use KF_PATH instead of
KVE_PATH.
Another case of incomplete regexp. The problem is very similar to the
one happening with gdb.arch/amd64-invalid-stack-middle.exp.
The output when GDB is compiled with "--enable-targets" is:
(gdb) interpreter-exec mi "-stack-list-frames"
^done,stack=[frame={level="0",addr="0x00000000004005e7",func="func2",arch="i386:x86-64"}]
While the output when "--enable-targets" is not specified is:
(gdb) interpreter-exec mi "-stack-list-frames"
^done,stack=[frame={level="0",addr="0x00000000004005e7",func="func2"}]
The fix is, again, to extend the current regexp and expect for the
optional "arch=" part. With this patch, the test now passes on both
scenarios.
OK?
gdb/testsuite/ChangeLog:
2018-09-18 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/amd64-invalid-stack-top.exp: Expect optional
"arch=" keyword when executing "-stack-list-frames".
While regression-testing GDB on Fedora Rawhide, I saw the following
output when running gdb.arch/amd64-invalid-stack-middle.exp's
"-stack-list-frames" test:
(gdb) interpreter-exec mi "-stack-list-frames"
^done,stack=[frame={level="0",addr="0x000000000040115a",func="breakpt",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/fedora/gdb/master/gdb-8.2.50.20180917/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="27",arch="i386:x86-64"},frame={level="1",addr="0x000000000040116a",func="func5",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/fedora/gdb/master/gdb-8.2.50.20180917/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="32",arch="i386:x86-64"},frame={level="2",addr="0x000000000040117a",func="func4",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/fedora/gdb/master/gdb-8.2.50.20180917/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="38",arch="i386:x86-64"},frame={level="3",addr="0x000000000040118a",func="func3",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/fedora/gdb/master/gdb-8.2.50.20180917/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="44",arch="i386:x86-64"}]
This test is currently failing on Rawhide. However, this output is
almost the same as I get on my local Fedora 28 machine (where the test
is passing):
(gdb) interpreter-exec mi "-stack-list-frames"
^done,stack=[frame={level="0",addr="0x00000000004005da",func="breakpt",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/work/src/git/binutils-gdb/binutils-gdb/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="27"},frame={level="1",addr="0x00000000004005ea",func="func5",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/work/src/git/binutils-gdb/binutils-gdb/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="32"},frame={level="2",addr="0x00000000004005fa",func="func4",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/work/src/git/binutils-gdb/binutils-gdb/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="38"},frame={level="3",addr="0x000000000040060a",func="func3",file="amd64-invalid-stack-middle.c",fullname="/home/sergio/work/src/git/binutils-gdb/binutils-gdb/gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c",line="44"}]
With the exception that there's an "arch=" keyword on Fedora Rawhide's
version. This is because, on Rawhide, I've compiled GDB with
"--enable-targets=xyz,kqp,etc.", while locally I haven't.
This is easy to fix: we just have to extend the regexp and expect for
the optional "arch=" keyword there. It's what this patch does. With
it applied, the test now passes everywhere.
OK?
gdb/testsuite/ChangeLog:
2018-09-18 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.arch/amd64-invalid-stack-middle.exp: Expect optional
"arch=" keyword when executing "-stack-list-frames".
Currently, gdb.ada/complete.exp's "complete break ada" test fails
because the regexp used to match the command's output doesn't expect
"@", but we have an output like:
...
complete break ada
break ada.assertions.assert
break ada.calendar.arithmetic.difference
break ada.calendar.arithmetic_operations.add
break ada.calendar.arithmetic_operations.add.cold
break ada.calendar.arithmetic_operations.add@plt
break ada.calendar.arithmetic_operations.difference
break ada.calendar.arithmetic_operations.difference@plt
...
This patch adds "@" to the regexp, unbreaking the test.
OK?
gdb/testsuite/ChangeLog:
2018-09-18 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.ada/complete.exp: Expect for "@" when doing "complete
break ada".
This removes the remaining cleanups from compile-object-load.c.
gdb/ChangeLog
2018-09-18 Tom Tromey <tom@tromey.com>
* compile/compile-object-load.c (struct
link_hash_table_cleanup_data): Add constructor and destructor.
Use DISABLE_COPY_AND_ASSIGN.
(~link_hash_table_cleanup_data): Rename from
link_hash_table_free. Now a destructor.
(copy_sections): Use gdb::unique_xmalloc_ptr. Remove cleanups.
This removes munmap_listp_free_cleanup, replacing it with a
std::unique_ptr at one spot and an explicit delete in another. It
seemed simplest to completely change this data structure.
gdb/ChangeLog
2018-09-18 Tom Tromey <tom@tromey.com>
* compile/compile-object-run.c (do_module_cleanup): Use delete.
* compile/compile-object-load.c (struct munmap_list): Move to
header file.
(munmap_list::add): Rename from munmap_list_add; rewrite.
(munmap_list::~munmap_list): Rename from munmap_list_free.
(munmap_listp_free_cleanup): Remove.
(compile_object_load): Update.
* compile/compile-object-load.h (struct munmap_list): Move from
compile-object-load.c. Rewrite.
Using "call" on a function that passes arguments via float registers can cause
gdb to overflow buffers.
Ensure enough memory is reserved to hold a full FP register.
This fixes gdb.base/callfuncs.exp for Aarch64 SVE.
2018-09-18 Alan Hayward <alan.hayward@arm.com>
* aarch64-tdep.c (pass_in_v): Use register size.
(aarch64_extract_return_value): Likewise.
(aarch64_store_return_value): Likewise.
gdb doesn't currently build on 64-bit Solaris 10:
/vol/src/gnu/gdb/hg/master/local/gdb/utils.c: In function ‘void dump_core()’:
/vol/src/gnu/gdb/hg/master/local/gdb/utils.c:223:55: error: narrowing conversion
of ‘-3’ from ‘long int’ to ‘rlim_t’ {aka ‘long unsigned int’} inside {
} [-Wnarrowing]
struct rlimit rlim = { RLIM_INFINITY, RLIM_INFINITY };
^
/vol/src/gnu/gdb/hg/master/local/gdb/utils.c:223:55: error: narrowing conversion
of ‘-3’ from ‘long int’ to ‘rlim_t’ {aka ‘long unsigned int’} inside {
} [-Wnarrowing]
This was introduced by
2018-08-27 Tom Tromey <tom@tromey.com>
PR build/23087:
* configure: Rebuild.
* warning.m4 (AM_GDB_WARNINGS): Remove -Wno-narrowing.
and can be fixed by the following patch.
Solaris 11 isn't affected because there <sys/resource.h> has
#define RLIM_INFINITY ((rlim_t)-3l)
instead of
#define RLIM_INFINITY (-3l)
on Solaris 10.
Tested on amd64-pc-solaris2.10 and amd64-pc-solaris2.11.
* utils.c (dump_core) [HAVE_SETRLIMIT]: Cast RLIM_INFINITY to
rlim_t.
Without the patch:
(gdb) apropos able frame-filter
disable frame-filter -- GDB command to disable the specified frame-filter
enable frame-filter -- GDB command to disable the specified frame-filter
With the patch:
(gdb) apropos able frame-filter
disable frame-filter -- GDB command to disable the specified frame-filter
enable frame-filter -- GDB command to enable the specified frame-filter
Pushed as obvious
The Python CFLAGS include -DNDEBUG. This was apparently done
intentionally -- setting the flags is done manually because, according
to a comment, python-config passes too many things to the compiler
(which is true).
Per PR python/20445, this patch changes configure so that -DNDEBUG is
only used by release builds. This probably doesn't have very much
effect in practice, but I did see that some Python headers use assert,
so perhaps it will give some safety.
Tested by rebuilding and re-running gdb.python/*.exp on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
PR python/20445:
* configure: Rebuild.
* configure.ac: Conditionally use -DNDEBUG for Python.
There was a report on irc that the gdb check for mpfr failed when only
static libraries are available. The issue is that mpfr depends on
gmp, but this is not handled explicitly by gdb.
Ideally upstream would switch to pkg-config. Or even more ideally, we
would incorporate pkg-config into the compiler and not mess with any
of this.
Meanwhile, this changes gdb's configure to add gmp to the link line
when checking for mpfr.
gdb/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Use gmp as a library dependency when checking for
mpfr.
Commit 00431a78b2 ("Use thread_info and inferior pointers more
throughout") removed the declaration of find_inferior_object, but
missed removing the definition.
gdb/ChangeLog:
2018-09-17 Pedro Alves <palves@redhat.com>
* python/py-inferior.c (find_inferior_object): Delete.
Patch
d82b3862f1 ("compile: Remove non-const reference parameters")
introduced a regression in compile/compile-cplus-types.c. The new_scope
variable in compile_cplus_instance::enter_scope is used after it was
std::moved. This patch fixes it by referring to the back of the vector
where it was moved instead.
gdb/ChangeLog:
* compile/compile-cplus-types.c
(compile_cplus_instance::enter_scope): Don't use new_scope after
std::move.
On macOS the usual cache directory is ~/Library/Caches. This patch
changes get_standard_cache_dir to use that instead of XDG.
gdb/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
* common/pathstuff.c (get_standard_cache_dir): Use
~/Library/Caches on macOS.
* common/pathstuff.h (get_standard_cache_dir): Update comment.
gdb/doc/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Index Files): Update for cache directory change on
macOS.
Since commit
56bcdbea2b ("Let gdb.execute handle multi-line commands")
trying to use a command like gdb.execute("show commands") in Python
fails. GDB ends up trying to run the "commands" command.
The reason is that GDB gets confused with the special "commands"
command. In process_next_line, the lookup_cmd_1 function returns the
cmd_list_element representing the "commands" sub-command of "show".
Lower, we check the cmd_list_element to see if it matches various
control commands by name, including the "commands" command. This is
where we wrongfully conclude that the executed command must be
"commands", when in reality it was "show commands".
The fix proposed in this patch removes the comparisons by name, instead
comparing the cmd_list_element object by pointer with the objects
created at initialization time.
Tested on the buildbot, though on a single builder (Fedora-x86_64-m64).
gdb/ChangeLog:
PR python/23669
* breakpoint.c (commands_cmd_element): New.
(_initialize_breakpoint): Assign commands_cmd_element.
* breakpoint.h (commands_cmd_element): New.
* cli/cli-script.c (while_cmd_element, if_command,
define_cmd_element): New.
(command_name_equals): Remove.
(process_next_line): Compare commands by pointer, not by name.
(_initialize_cli_script): Assign the various cmd_list_element
variables.
* compile/compile.c (compile_cmd_element): New.
(_initialize_compile): Assign compile_cmd_element.
* compile/compile.h (compile_cmd_element): New.
* guile/guile.c (guile_cmd_element): New.
(install_gdb_commands): Assign guile_cmd_element.
* guile/guile.h (guile_cmd_element): New.
* python/python.c (python_cmd_element): New.
(_initialize_python): Assign python_cmd_element.
* python/python.h (python_cmd_element): New.
* tracepoint.c (while_stepping_cmd_element): New.
(_initialize_tracepoint): Assign while_stepping_cmd_element.
* tracepoint.h (while_stepping_cmd_element): New.
gdb/testsuite/ChangeLog:
PR python/23669
* gdb.python/python.exp: Test gdb.execute("show commands").
Simon pointed out that save_infcall_suspend_state and
save_infcall_control_state could return unique pointers. This patch
implements this idea.
gdb/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
* infrun.c (save_infcall_suspend_state): Return
infcall_suspend_state_up.
(save_infcall_control_state): Return infcall_control_state_up.
* inferior.h (save_infcall_suspend_state)
(save_infcall_control_state): Declare later. Return unique
pointers.
This removes release_stop_context_cleanup, replacing it with a
stop_context destructor. It also mildly c++-ifies this struct.
gdb/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
* infrun.c (struct stop_context): Declare constructor,
destructor, "changed" method.
(stop_context::stop_context): Rename from save_stop_context.
(stop_context::~stop_context): Rename from
release_stop_context_cleanup.
(normal_stop): Update.
(stop_context::changed): Rename from stop_context_changed. Return
bool.
This removes a couple of cleanups from infrun by introducing a couple
of unique_ptr specializations.
gdb/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
* inferior.h (struct infcall_suspend_state_deleter): New.
(infcall_suspend_state_up): New typedef.
(struct infcall_control_state_deleter): New.
(infcall_control_state_up): New typedef.
(make_cleanup_restore_infcall_suspend_state)
(make_cleanup_restore_infcall_control_state): Don't declare.
* infcall.c (call_function_by_hand_dummy): Update.
* infrun.c (do_restore_infcall_suspend_state_cleanup)
(make_cleanup_restore_infcall_suspend_state): Remove.
(do_restore_infcall_control_state_cleanup)
(make_cleanup_restore_infcall_control_state): Remove.
This removes a cleanup from infrun.c by taking advantage of the
previous patch to introduce a use of unique_xmalloc_ptr.
gdb/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
* infrun.c (struct infcall_suspend_state) <registers>: Now a
unique_ptr.
<siginfo_data>: Now a unique_xmalloc_ptr.
(save_infcall_suspend_state, restore_infcall_suspend_state)
(discard_infcall_suspend_state)
(get_infcall_suspend_state_regcache): Update.
This changes infrun.c to use new and delete for infcall_suspend_state.
This enables the coming cleanups.
gdb/ChangeLog
2018-09-17 Tom Tromey <tom@tromey.com>
* gdbthread.h (struct thread_suspend_state): Add initializers.
(class thread_info) <suspend>: Remove initializer.
* infrun.c (struct infcall_suspend_state): Add initializers.
(save_infcall_suspend_state): Use new.
(discard_infcall_suspend_state): Use delete.
Some Python APIs steal references from their caller, and the refcount
checker supports this via an attribute.
However, in gdb with C++ we have a better idiom available: we can use
std::move on a gdbpy_ref<> instead. This makes the semantics obvious
at the point of call, and is safer at runtime as well, because the
callee's gdbpy_ref<> will be emptied.
This patch changes the reference-stealing code in gdb to use rvalue
references instead.
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/python-internal.h (CPYCHECKER_STEALS_REFERENCE_TO_ARG):
Remove.
* python/py-varobj.c (py_varobj_iter_ctor): Change pyiter to
rvalue reference. Remove CPYCHECKER_STEALS_REFERENCE_TO_ARG.
(py_varobj_iter_new): Likewise.
(py_varobj_get_iterator): Use gdbpy_ref.
An review by Simon of an earlier showed a few spots related to
thread_to_thread_object that could be simplified. This also detected
a latent bug, where thread_to_thread_object was inconsistent about
setting the Python exception before a NULL return.
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/py-threadevent.c (py_get_event_thread): Simplify.
* python/py-inferior.c (infpy_thread_from_thread_handle):
Return immediately after calling thread_to_thread_object. Use
Py_RETURN_NONE.
(thread_to_thread_object): Set the exception on a NULL return.
Tom mentioned this a while ago, as a way to give you a cheap sense of
progression in your build, as all object files will be built
alphabetically (including the directory part). I tried it and I think
it's nice.
gdb/ChangeLog:
* Makefile.in (LIBGDB_OBS): Sort COMMON_OBS.
gdb/gdbserver/ChangeLog:
* Makefile.in (gdbserver$(EXEEXT)): Sort OBS.
(gdbreplay$(EXEEXT)): Sort GDBREPLAY_OBS.
($(IPA_LIB)): Sort IPA_OBJS.
ADD_DEPS is defined nowhere, so I presume it's not useful. If I'm wrong
and this is actually used, there should be a comment explaining where it
comes from.
gdb/gdbserver/ChangeLog:
* Makefile.in: Remove references to $(ADD_DEPS).
CPYCHECKER_RETURNS_BORROWED_REF is not used, and I think should never
be used. This patch removes it.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/python-internal.h (CPYCHECKER_RETURNS_BORROWED_REF):
Remove.
This changes thread_to_thread_object to return a new reference and
fixes up all the callers.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/python-internal.h (thread_to_thread_object): Change
return type.
* python/py-inferior.c (thread_to_thread_object): Return a new
reference.
(infpy_thread_from_thread_handle): Update.
* python/py-infthread.c (gdbpy_selected_thread): Update.
* python/py-stopevent.c (create_stop_event_object): Update.
* python/py-threadevent.c (py_get_event_thread): Return a new
reference.
(py_get_event_thread): Update.
* python/py-event.h (py_get_event_thread): Change return type.
* python/py-continueevent.c (create_continue_event_object):
Update.
This changes pspace_to_pspace_object to return a new reference and
fixes up all the callers.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/py-inferior.c (infpy_get_progspace): Update.
* python/python-internal.h (pspace_to_pspace_object): Change
return type.
* python/py-newobjfileevent.c
(create_clear_objfiles_event_object): Update.
* python/py-xmethods.c (gdbpy_get_matching_xmethod_workers):
Update.
* python/python.c (gdbpy_get_current_progspace): Update.
(gdbpy_progspaces): Update.
* python/py-progspace.c (pspace_to_pspace_object): Return a new
reference.
* python/py-objfile.c (objfpy_get_progspace): Update.
* python/py-prettyprint.c (find_pretty_printer_from_progspace):
Update.
There are a number of global functions in the gdb Python module which
really should be methods on Progspace. This patch adds new methods to
Progspace and then redefines these globals in terms of these new
methods.
This version has been rebased on the related changes that Simon
recently put in.
Built and regtested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python/lib/gdb/__init__.py (current_progspace, objfiles)
(solib_name, block_for_pc, find_pc_line): New functions.
(execute_unwinders): Update.
* python/py-block.c (gdbpy_block_for_pc): Remove.
* python/py-inferior.c (infpy_get_progspace): New function.
(inferior_object_getset) <progspace>: Add.
* python/py-progspace.c (pspy_objfiles): Rewrite.
(pspy_solib_name, pspy_block_for_pc)
(pspy_find_pc_line, pspy_is_valid): New functions.
(progspace_object_methods): Add entries for solib_name,
block_for_pc, find_pc_line, is_valid.
* python/python-internal.h (gdbpy_block_for_pc)
(build_objfiles_list): Don't declare.
* python/python.c: Don't include solib.h.
(gdbpy_solib_name, gdbpy_find_pc_line)
(gdbpy_get_current_progspace, build_objfiles_list)
(gdbpy_objfiles): Remove.
(GdbMethods) <current_progspace, objfiles, block_for_pc,
solib_name, find_pc_line>: Remove entries.
gdb/doc/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Update docs for find_pc_line,
solib_name.
(Progspaces In Python): Update docs for current_progspace.
Document block_for_pc, find_pc_line, is_valid, nsolib_name.
Move method documentation before example.
This changes a couple of places in gdbserver to use the GNU style for
metasyntactic variables.
gdb/gdbserver/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* remote-utils.c (remote_open): Use GNU style for metasyntactic
variables.
* gdbreplay.c (gdbreplay_usage): Use GNU style for metasyntactic
variables.
I searched for other spots that did not use the GNU style for
metasyntactic syntactic variables. This patch fixes most of the ones
I found in gdb proper. There are a few remaining in MI, but I was
unsure whether those should be touched.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* top.c (new_ui_command): Use GNU style for metasyntactic
variables.
* breakpoint.c (stopat_command): Use GNU style for metasyntactic
variables.
* maint.c (maintenance_translate_address): Remove "<>" around
text.
* interps.c (interpreter_exec_cmd): Use GNU style for
metasyntactic variables.
* nto-procfs.c (nto_procfs_target_info): Use GNU style for
metasyntactic variables.
* tracepoint.c (tfind_range_command): Use GNU style for
metasyntactic variables.
(tfind_outside_command): Likewise.
(_initialize_tracepoint): Likewise.
* remote.c (extended_remote_target::create_inferior): Use GNU
style for metasyntactic variables.
* sparc64-tdep.c (adi_examine_command): Use GNU style for
metasyntactic variables.
(adi_assign_command): Likewise.
gdb/testsuite/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* gdb.base/new-ui.exp (do_execution_tests): Update.
* gdb.base/dbx.exp (test_breakpoints): Update.
I typed this:
(gdb) help set disassembler-options
Set the disassembler options.
Usage: set disassembler-options OPTION [,OPTION]...
See: 'show disassembler-options' for valid option values.
... so I tried what it said and got:
(gdb) show disassembler-options
The current disassembler options are ''
This surprised me a little, so this patch adds some text to explain
the situation when an architecture does not have disassembler options.
While there I noticed one more spot where gdb was not using the GNU
style for metasyntactic variables. This patch fixes this as well.
gdb/ChangeLog
2018-09-16 Tom Tromey <tom@tromey.com>
* disasm.c (show_disassembler_options_sfunc): Use GNU style for
metasyntactic variables. Print message if no disassembler options
are available.
I noticed that get_inferior_args should return const char *, because
it is just returning a reference to something owned by the inferior.
I'm checking this in.
gdb/ChangeLog
2018-09-15 Tom Tromey <tom@tromey.com>
* infcmd.c (get_inferior_args): Return const char *.
* inferior.h (get_inferior_args): Return type now const.
* linux-tdep.c (linux_fill_prpsinfo): Update.
* procfs.c (procfs_target::make_corefile_notes): Update.
In the Python code, gdb exceptions may not leak into the Python core.
execute_gdb_command was calling bpstat_do_actions outside of a
TRY/CATCH; which seemed risky. I don't have a test case for this, but
if bpstat_do_actions could ever throw, it could crash gdb.
This patch introduces a new scope in order to preserve the current
semantics, so it is looks a bit bigger than it really is.
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2018-09-07 Tom Tromey <tom@tromey.com>
* python/python.c (execute_gdb_command): Call bpstat_do_actions
inside the TRY.
This patch started as an observation from valgrind that GDB appeared
to be loosing track of some memory associated with types. An example
valgrind stack would be:
24 bytes in 1 blocks are possibly lost in loss record 419 of 5,361
at 0x4C2EA1E: calloc (vg_replace_malloc.c:711)
by 0x623D26: xcalloc (common-utils.c:85)
by 0x623D65: xzalloc(unsigned long) (common-utils.c:95)
by 0x72A066: make_function_type(type*, type**) (gdbtypes.c:510)
by 0x72A098: lookup_function_type(type*) (gdbtypes.c:521)
by 0x73635D: gdbtypes_post_init(gdbarch*) (gdbtypes.c:5439)
by 0x727590: gdbarch_data(gdbarch*, gdbarch_data*) (gdbarch.c:5230)
by 0x735B99: builtin_type(gdbarch*) (gdbtypes.c:5313)
by 0x514D95: elf_rel_plt_read(minimal_symbol_reader&, objfile*, bfd_symbol**) (elfread.c:542)
by 0x51662F: elf_read_minimal_symbols(objfile*, int, elfinfo const*) (elfread.c:1121)
by 0x5168A5: elf_symfile_read(objfile*, enum_flags<symfile_add_flag>) (elfread.c:1207)
by 0x8520F5: read_symbols(objfile*, enum_flags<symfile_add_flag>) (symfile.c:794)
When we look in make_function_type we find a call to TYPE_ZALLOC
(inside the INIT_FUNC_SPECIFIC macro). It is this call to TYPE_ZALLOC
that is allocating memory with xcalloc, that is then getting lost.
The problem is tht calling TYPE_ALLOC or TYPE_ZALLOC currently
allocates memory from either the objfile obstack or by using malloc.
The problem with this is that types are allocated either on the
objfile obstack, or on the gdbarch obstack.
As a result, if we discard a type associated with an objfile then
auxiliary data allocated with TYPE_(Z)ALLOC will be correctly
discarded. But, if we were ever to discard a gdbarch then any
auxiliary type data would be leaked. Right now there are very few
places in GDB where a gdbarch is ever discarded, but it shouldn't hurt
to close down these bugs as we spot them.
This commit ensures that auxiliary type data is allocated from the
same obstack as the type itself, which should reduce leaked memory.
The one problem case that I found with this change was in eval.c,
where in one place we allocate a local type structure, and then used
TYPE_ZALLOC to allocate some space for the type. This local type is
neither object file owned, nor gdbarch owned, and so the updated
TYPE_ALLOC code is unable to find an objstack to allocate space on.
My proposed solution for this issue is that the space should be
allocated with a direct call to xzalloc. We could extend TYPE_ALLOC
to check for type->gdbarch being null, and then fall back to a direct
call to xzalloc, however, I think that making this rare case of a
local type require special handling is not a bad thing, this serves to
highlight that clearing up the memory will require special handling
too.
This special case of a local type is interesting as the types owner
field (contained within the main_type) is completely null. While
reflecting on this I looked at how types use the get_type_arch
function. It seems clear that, based on how this is used, it is never
intended that null will be returned from this function. This only
goes to reinforce, how locally alloctaed types, with no owner, are
both special, and need to be handled carefully. To help spot errors
earlier, I added an assert into get_type_arch that the returned arch
is not null.
Inside gdbarch.c I found a few other places where auxiliary type data
was being allocated directly on the heap rather than on the types
obstack. I have fixed these to call TYPE_ALLOC now.
Finally, it is worth noting that as we don't clean up our gdbarch
objects yet, then this will not make much of an impact on the amount
of memory reported as lost at program termination time. Memory
allocated for auxiliary type information is still not freed, however,
it is now on the correct obstack. If we do ever start freeing our
gdbarch structures then the associated type data will be cleaned up
correctly.
Tested on X86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* eval.c (fake_method::fake_method): Call xzalloc directly for a
type that is neither object file owned, nor gdbarch owned.
* gdbtypes.c (get_type_gdbarch): Add an assert that returned
gdbarch is non-NULL.
(alloc_type_instance): Allocate non-objfile owned types on the
gdbarch obstack.
(copy_type_recursive): Allocate TYPE_FIELDS and TYPE_RANGE_DATA
using TYPE_ALLOC to ensure memory is allocated on the correct
obstack.
* gdbtypes.h (TYPE_ALLOC): Allocate space on either the objfile
obstack, or the gdbarch obstack.
(TYPE_ZALLOC): Rewrite using TYPE_ALLOC.
I noticed that call_function_by_hand_dummy has a block that only
exists to declare a variable, like:
{
int i;
for (i = ...0)
...
}
This patch removes the unnecessary and the extra indentation by moving
the declaration into the "for".
gdb/ChangeLog
2018-09-14 Tom Tromey <tom@tromey.com>
* infcall.c (call_function_by_hand_dummy): Remove unnecessary
block.
I noticed that a variable in get_startup_shell is "static". However,
I couldn't see any reason it ought to be, so this removes the
"static".
gdb/ChangeLog
2018-09-14 Tom Tromey <tom@tromey.com>
* nat/fork-inferior.c (get_startup_shell): Remove "static".
Simplfy gdb.exp by adding a function that will attempt to
compile a piece of code, then clean up, leaving the created
object.
gdb/testsuite
* lib/gdb.exp (gdb_simple_compile): Add proc.
(is_elf_target): Use gdb_simple_compile.
(skip_altivec_tests): Likewise.
(skip_vsx_tests): Likewise.
(skip_tsx_tests): Likewise.
(skip_btrace_tests): Likewise.
(skip_btrace_pt_tests): Likewise.
(gdb_can_simple_compile): Likewise.
(gdb_has_argv0): Likewise.
(gdb_target_symbol_prefix): Likewise.
(target_supports_scheduler_locking): Likewise.
I noticed that the TAGS target in gdb/testsuite/Makefile does not pick
up Tcl procs defined with proc_with_prefix or gdb_caching_proc. This
patch fixes this by updating the regexp.
Tested in Emacs.
gdb/testsuite/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* Makefile.in (TAGS): Recognize proc_with_prefix and
gdb_caching_proc.
I noticed that infpy_thread_from_thread_handle is not static, but
should be. This patch changes it.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* python/py-inferior.c (infpy_thread_from_thread_handle): Now
static.
This removes a cleanup from try_open_exec_file, using std::string to
manage the storage instead.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* exec.c (try_open_exec_file): Use std::string.
This changes gdb_bfd_errmsg to return a std::string, removing a
cleanup. This approach may be slightly less efficient than the
previous code, but I don't believe this is very important in this
situation.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* utils.h (gdb_bfd_errmsg): Return std::string.
* exec.c (exec_file_attach): Update.
* compile/compile-object-load.c (compile_object_load): Update.
* utils.c (gdb_bfd_errmsg): Return std::string.
This removes the last remaining cleanup from procfs.c, replacing it
with a unique_ptr specialization.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* procfs.c (struct procinfo_deleter): New.
(procinfo_up): New typedef.
(do_destroy_procinfo_cleanup): Remove.
(procfs_target::info_proc): Use procinfo_up. Remove cleanups.
This removes a cleanup from add_path, replacing it with a use of
gdb::unique_xmalloc_ptr. Note that this declaration had to be hoisted
somewhat, to avoid inteference from the "goto"s in this function.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
* source.c (add_path): Use gdb::unique_xmalloc_ptr.
The code implementing gdb.objfiles() returns a list of objfiles for the
current program space (the program space of the selected inferior). The
documentation for the gdb.objfiles() Python method, however, states:
Return a sequence of all the objfiles current known to GDB.
That sounds wrong to me. I tried to phrase to be more precise.
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Update gdb.objfiles() doc.
This patch adds an objfiles method to the Progspace object, which
returns a sequence of the objfiles associated to that program space. I
chose a method rather than a property for symmetry with gdb.objfiles().
gdb/ChangeLog:
* python/py-progspace.c (PSPY_REQUIRE_VALID): New macro.
(pspy_get_objfiles): New function.
(progspace_object_methods): New.
(pspace_object_type): Add tp_methods callback.
* python/python-internal.h (build_objfiles_list): New
declaration.
* python/python.c (build_objfiles_list): New function.
(gdbpy_objfiles): Implement using build_objfiles_list.
* NEWS: Mention the Progspace.objfiles method.
gdb/doc/ChangeLog:
* python.texi (Program Spaces In Python): Document the
Progspace.objfiles method.
(Objfiles In Python): Mention that gdb.objfiles() is identical
to gdb.selected_inferior().progspace.objfiles().
gdb/testsuite/ChangeLog:
* gdb.python/py-progspace.exp: Test the Progspace.objfiles
method.
This patch adds a progspace property to the gdb.Inferior type, which
allows getting the gdb.Progspace object associated to that inferior.
In conjunction with the following patch, this will allow scripts iterate
on objfiles associated with a particular inferior.
gdb/ChangeLog:
* python/py-inferior.c (infpy_get_progspace): New function.
(inferior_object_getset): Add progspace property.
* NEWS: Mention the new property.
gdb/doc/ChangeLog:
* python.texi (Inferiors In Python): Document
Inferior.progspace.
(Program Spaces In Python): Document that
gdb.current_progspace() is the same as
gdb.selected_inferior().progspace.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Add tests for Inferior.progspace
and a few other Inferior properties when the Inferior is no
longer valid.
I noticed a spot in rust-lang.c where the placeholder "foo" was used
instead of the actual field name. This patch fixes the bug.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
PR rust/23650:
* rust-lang.c (rust_evaluate_subexp): Use field name, not "foo".
gdb/testsuite/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
PR rust/23650:
* gdb.rust/simple.exp: Add test for enum field access error.
While testing my Rust compiler patch to fix the DWARF representation
of Rust enums (https://github.com/rust-lang/rust/pull/54004), I found
a gdb crash coming from one of the Rust test cases.
The bug here is that the new variant support in gdb does not handle
the case where there are no variants in the enum.
This patch fixes the problem in a straightforward way. Note that the
new tests are somewhat lax because I did not want to try to fully fix
this corner case for older compilers. If you think that's
unacceptable, let meknow.
Tested on x86-64 Fedora 28 using several versions of the Rust
compiler. I intend to push this to the 8.2 branch as well.
gdb/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
PR rust/23626:
* rust-lang.c (rust_enum_variant): Now static.
(rust_empty_enum_p): New function.
(rust_print_enum, rust_evaluate_subexp, rust_print_struct_def):
Handle empty enum.
gdb/testsuite/ChangeLog
2018-09-13 Tom Tromey <tom@tromey.com>
PR rust/23626:
* gdb.rust/simple.rs (EmptyEnum): New type.
(main): Use it.
* gdb.rust/simple.exp (test_one_slice): Add empty enum test.
Printing a GDB Python object is notoriously not helpful:
>>> print(gdb.selected_inferior())
<gdb.Inferior object at 0x7fea59aed198>
>>> print(gdb.objfiles())
[<gdb.Objfile object at 0x7fea59b57c90>]
This makes printing debug traces more difficult than it should be. This
patch provides some repr() implementation for these two types (more to
come if people agree with the idea, but I want to test the water first).
Here's the same example as above, but with this patch:
>>> print(gdb.selected_inferior())
<gdb.Inferior num=1>
>>> print(gdb.objfiles())
[<gdb.Objfile filename=/home/emaisin/build/binutils-gdb-gcc-git/gdb/test>]
I implemented repr rather than str, because when printing a list (or
another container I suppose), Python calls the repr method of the
elements. This is useful when printing a list of inferiors or objfiles.
The print(gdb.objfiles()) above would not have worked if I had
implemented str.
I found this post useful to understand the difference between repr and
str:
https://stackoverflow.com/questions/1436703/difference-between-str-and-repr
gdb/ChangeLog:
* python/py-inferior.c (infpy_repr): New.
(inferior_object_type): Register infpy_repr.
* python/py-objfile.c (objfpy_repr): New.
(objfile_object_type): Register objfpy_repr.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Test repr() of gdb.Inferior.
* gdb.python/py-objfile.exp: Test repr() of gdb.Objfile.
* gdb.python/py-symtab.exp: Update test printing an objfile.
gdb/doc/ChangeLog:
* python.texi (Basic Python): Mention the string representation
of GDB Python objects.
This patch adds tests for trying to use property or methods on a
gdb.Inferior object that represents an inferior that does not exist
anymore. We expect an exception to be thrown.
gdb/testsuite/ChangeLog:
* gdb.python/py-inferior.exp: Test using an invalid gdb.Inferior
object.
There is no reason for 'is_regular_file' to be in common-utils.c; it
belongs to 'filestuff.c'. This commit moves the function definition
and its prototype to the appropriate files.
The motivation behind this move is a failure that happens on certain
cross-compilation environments when compiling the IPA library, due to
the way gnulib probes the need for a 'stat' call replacement. Because
configure checks when cross-compiling are more limited, gnulib decides
that it needs to substitute the 'stat' calls its own 'rpl_stat';
however, the IPA library doesn't link with gnulib, which leads to an
error when compiling 'common-utils.c':
...
/opt/x86-core2--musl--bleeding-edge-2018.09-1/bin/i686-buildroot-linux-musl-g++ -shared -fPIC -Wl,--soname=libinproctrace.so -Wl,--no-undefined -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -I. -I. -I./../common -I./../regformats -I./.. -I./../../include -I./../gnulib/import -Ibuild-gnulib-gdbserver/import -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -DGDBSERVER \
-Wl,--dynamic-list=./proc-service.list -o libinproctrace.so ax-ipa.o common-utils-ipa.o errors-ipa.o format-ipa.o print-utils-ipa.o regcache-ipa.o remote-utils-ipa.o rsp-low-ipa.o tdesc-ipa.o tracepoint-ipa.o utils-ipa.o vec-ipa.o linux-i386-ipa.o linux-x86-tdesc-ipa.o arch/i386-ipa.o -ldl -pthread
/opt/x86-core2--musl--bleeding-edge-2018.09-1/lib/gcc/i686-buildroot-linux-musl/8.2.0/../../../../i686-buildroot-linux-musl/bin/ld: common-utils-ipa.o: in function `is_regular_file(char const*, int*)':
common-utils.c:(.text+0x695): undefined reference to `rpl_stat'
collect2: error: ld returned 1 exit status
Makefile:413: recipe for target 'libinproctrace.so' failed
make[1]: *** [libinproctrace.so] Error 1
...
More details can also be found at:
https://sourceware.org/ml/gdb-patches/2018-09/msg00304.html
The most simple fix for this problem is to move 'is_regular_file' to
'filestuff.c', which is not used by IPA. This ends up making the
files more logically organized as well, since 'is_regular_file' is a
file operation.
No regressions found.
gdb/ChangeLog:
2018-09-12 Sergio Durigan Junior <sergiodj@redhat.com>
* common/common-utils.c: Don't include '<sys/stat.h>'.
(is_regular_file): Move to...
* common/filestuff.c (is_regular_file): ... here.
* common/common-utils.h (is_regular_file): Move to...
* common/filestuff.h (is_regular_file): ... here.
While trying to create skips for libstdc++, I found myself debugging GDB
quite a bit, mostly to find out what the exact function name to match
is. I thought it would make sense to have this information as debug
output.
This patch adds "set debug skip on|off".
gdb/ChangeLog:
* skip.c (debug_skip): New variable.
(skiplist_entry::do_skip_file_p): Add debug output.
(skiplist_entry::do_skip_gfile_p): Likewise.
(skiplist_entry::skip_function_p): Likewise.
(_initialize_step_skip): Create debug command.
* NEWS: Mention set/show debug skip.
gdb/doc/ChangeLog:
* gdb.texinfo (Skipping Over Functions and Files): Document
set/show debug skip.
Simplfy gdb.exp by adding a function that will attempt to
compile a piece of code, then clean up.
gdb/testsuite
* lib/gdb.exp (gdb_can_simple_compile): Add proc.
(support_complex_tests): Use gdb_can_simple_compile.
(is_ilp32_target): Likewise.
(is_lp64_target): Likewise.
(is_64_target): Likewise.
(is_amd64_regs_target): Likewise.
(is_aarch32_target): Likewise.
(gdb_int128_helper): Likewise.
On Mac OS X Sierra and later, the shell is not allowed to be
debug so add a check and disable startup with shell in that
case. This disabling is done temporary before forking
inferior and restored after the fork.
gdb/ChangeLog:
* darwin-nat.c (should_disable_startup_with_shell):
New function.
(darwin_nat_target::create_inferior): Add call.
Change-Id: Ie4d9090f65fdf2e83ecf7a0f9d0647fb1c27cdcc
Debugging a program under Darwin does not work:
(gdb) start
Temporary breakpoint 1 at 0x100000fb4: file /tmp/helloworld.c, line 1.
Starting program: /private/tmp/helloworld
[New Thread 0x2903 of process 60326]
During startup program terminated with signal SIGTRAP, Trace/breakpoint
trap.
Field signaled from darwin_thread_info is not initialized thus signal
sent to the debuggee is considered as not sent by GDB whereas it should.
This patch fixes this problem and also updates (change type and/or
initialize) other fields in the same structure at the same time.
gdb/ChangeLog:
* darwin-nat.h (struct darwin_thread_info) <gdb_port,
inf_port, msg_state>: Initialize.
(struct darwin_thread_info) <signaled, single_step>: Change
type and initialize.
(struct darwin_thread_info) <event>: Initialize.
Change-Id: I0fe2a6985df9d0dfcc8a2a258a3ef70cfa19b403
There was a typo in patch:
commit 5a6996172e
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date: Mon Aug 6 16:05:16 2018 +0200
Update dg-extract-results.* from gcc
gdb/testsuite/ChangeLog
2018-09-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* Makefile.in (check-parallel-racy): Fix dg-extract-results.sh path.
This is a backport of a gnulib fix for the following bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=23558
The problem reported there is about the replacement of 'getcwd' when
cross-compiling GDB. With our current gnulib copy, the mechanism for
deciding whether to use the system's 'getcwd' or gnulib's version is
too simplistic and pessimistic, so when cross-compiling we always end
up using gnulib's version, which has a limitation: it cannot handle
the situation when the parent directory doesn't have read permissions.
The solution is to backport the following gnulib commit:
commit a96d2e67052c879b1bcc5bc461722beac75fc372
Author: Bruno Haible <bruno@clisp.org>
Date: Thu Aug 23 21:13:19 2018 +0200
getcwd: Add cross-compilation guesses.
gdb/ChangeLog:
2018-09-10 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/23555
PR gdb/23558
* gnulib/import/m4/getcwd-path-max.m4: Add cross-compilation
guesses.
old_inferior_ptid is unused, this is caught by a gcc built from git
recently, not sure about previous versions:
/home/emaisin/src/binutils-gdb/gdb/record-btrace.c: In function ‘frame_info* get_thread_current_frame(thread_info*)’:
/home/emaisin/src/binutils-gdb/gdb/record-btrace.c:1974:10: error: unused variable ‘old_inferior_ptid’ [-Werror=unused-variable]
1974 | ptid_t old_inferior_ptid;
| ^~~~~~~~~~~~~~~~~
gdb/ChangeLog:
* record-btrace.c (get_thread_current_frame): Remove
old_inferior_ptid.
ada_value_struct_elt is used when displaying a component (say, 'N') of
a record object (say, 'Obj') of type, say, 't1'. Now if Obj is tagged
(Ada parlance: "tagged types" are what other object-oriented languages
call "classes"), then 'N' may not be visible in the current view and
we need to look for it in its actual type. We do that at the same time
as resolving variable-length fields. This would typically be done by
the following call to ada_value_struct_elt, with the last parameter
check_tag set to 1:
t1 = ada_to_fixed_type (ada_get_base_type (t1), NULL,
address, NULL, 1);
This is the general logic, but recently we introduced a special case
to handle homonyms. Different components may have the same name in a
tagged type. For instance:
type Top_T is tagged record
N : Integer := 1;
end record;
type Middle_T is new Top.Top_T with record
N : Character := 'a';
end record;
Middle_T extends Top_T and both define a (different) component with
the same name ('N'). In such a case, using the actual type of a
Middle_T object would create a confusion, since we would have two
component 'N' in this actual type.
So, to handle homonyms, we convert t1 to the actual type *if
and only if* N cannot be found in the current view. For example, if Obj
has been created as a Middle_T but is seen as a Top_T'Class at our
point of execution, then "print Obj.N" will display the integer field
defined in Top_T's declaration.
Now, even if we find N in the current view, we still have to get a
fixed type: for instance, the record can be unconstrained and we still
need a fixed type to get the proper offset to each field. That is
to say, in this case:
type Dyn_Top_T (Disc : Natural) is tagged record
S : Integer_Array (1 .. Disc) := (others => Disc);
N : Integer := 1;
end record;
type Dyn_Middle_T is new Dyn_Top.Dyn_Top_T with record
N : Character := 'a';
U : Integer := 42;
end record;
If we have an object Obj of type Dyn_Middle_T and we want to display
U, we don't need to build, from its tag, a real type with all its real
fields. In other words, we don't need to add the parent components:
Disc, S, and the integer N. We only need to access U and it is
directly visible in Dyn_Middle_T. So no tag handling. However, we do
need to build a fixed-size type to have the proper offset to U (since
this offset to U depends on the size of Obj.S, which itself is dynamic
and depends on the value of Obj.Disc).
We accidentally lost some of this treatment when we introduced the
resolution of homonyms. This patch re-install this part by uncoupling
the tag resolution from the "fixing" of variable-length components.
This change also slightly simplifies the non-tagged case: in the
non-tagged case, no need to set check_tag to 1, since we already know
that there is no tag.
gdb/ChangeLog:
* ada-lang.c (ada_value_struct_elt): Call ada_to_fixed_type
with check_tag to 1 if and only if the type is tagged and the
component being searched cannot been found in the current
view. Otherwise, always call ada_to_fixed_type with
check_tag to 0.
gdb/testsuite/ChangeLog:
* gdb.ada/same_component_name: Add test for case of tagged record
with variable-length fields.
This patch just avoids code duplication by using a function we
introduced recently (ada_is_access_to_unconstrained_array).
gdb/ChangeLog:
* ada-lang.c (ada_is_access_to_unconstrained_array): Remove static
declaration.
* ada-lang.h: add ada_is_access_to_unconstrained_array prototype.
* ada-varobj.c (ada_varobj_get_number_of_children,
ada_varobj_describe_child, ada_value_is_changeable_p): Cleanup code.
Tested on x86_64-linux.
No new testcase provided, as this is just a refactoring.
Using this Ada code:
type String_Access is access String;
type Array_Of_String is array (1 .. 2) of String_Access;
Aos : Array_Of_String := (new String'("ab"), new String'("cd"));
When debugging with GDB, printing each Aos element displays:
(gdb) print Aos(1)
$2 = "ab"
(gdb) print Aos(2)
$3 = "cd"
Whereas it should display:
(gdb) print Aos(1)
$2 = (foo_r118_024.string_access) 0x635018
(gdb) print Aos(2)
$3 = (foo_r118_024.string_access) 0x635038
Notice that printing the entire array works:
(gdb) print Aos
$1 = (0x635018, 0x635038)
The problem was located in ada_value_print function and due to the fact
that the value_type used in this function was based on
value_enclosing_type rather than value_type itself.
In our example, the difference between the value_type and the
value_enclosing_type of the value is that the value_type contains an
additional typedef layer which is not present in the value_enclosing_type.
This typedef layer is GNAT's way to specify that the element is, at the
source level, an access to the unconstrained array, rather than the
unconstrained array.
Moreover, the value_enclosing_type is not really needed in that case and
the value_type can be used instead in this function, and this patch fixes
this.
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Use type instead of
enclosing type.
testsuite/ChangeLog:
* gdb.ada/access_to_unbounded_array.exp: New testcase.
* gdb.ada/access_to_unbounded_array/foo.adb: New file.
* gdb.ada/access_to_unbounded_array/pack.adb: New file.
* gdb.ada/access_to_unbounded_array/pack.ads: New file.
Tested: x86_64-linux
Using this Ada code:
type String_Access is access String;
type Array_Of_String is array (1 .. 2) of String_Access;
Aos : Array_Of_String := (new String'("ab"), new String'("cd"));
In GDB/MI mode, create a variable which type is Aos, evaluate it:
(gdb) -var-create var1 * Aos
^done,name="var1",numchild="2",value="[2]",type="bar.array_of_string",thread-id="1",has_more="0"
Now print it:
(gdb) -var-list-children 1 var1
^done,numchild="2",children=[child={name="var1.1",exp="1",numchild="1",value="[2] \"ab\"", type="bar.string_access",thread-id="1"},child={name="var1.2",exp="2",numchild="1",value="[2] \"cd\"", type="bar.string_access",thread-id="1"}],has_more="0"
But printed fields "value" are wrong, since it should be:
^done,numchild="2",children=[child={name="var1.1",exp="1",numchild="1",value="0x634018",type="bar.string_access",thread-id="1"},child={name="var1.2",exp="2",numchild="1",value="0x634038",type="bar.string_access",thread-id="1"}],has_more="0"^M
Print each child of var1:
(gdb) -var-evaluate-expression var1.1
^done,value="[2] \"ab\""
(gdb) -var-evaluate-expression var1.2
^done,value="[2] \"cd\""
Whereas it should be
(gdb) -var-evaluate-expression var1.1
^done,value="0x635018"
(gdb) -var-evaluate-expression var1.2
^done,value="0x635038"
This patch fixes this.
gdb/ChangeLog:
* ada-lang.c (ada_value_subscript): Handle case when parameter is
an array of access to unconstrained array.
testsuite/ChangeLog
* gdb.ada/mi_string_access.exp: New testcase.
* gdb.ada/mi_string_access/bar.adb: New file.
* gdb.ada/mi_string_access/pck.adb: New file.
* gdb.ada/mi_string_access/pck.asd: New file.
Tested on x86_64-linux.
Add a new function to check if a given type is an access to an
unconstrained array. This function contains code that is present only
once in the current sources but will be used in a future patch.
gdb/ChangeLog:
* ada-lang.c (ada_is_access_to_unconstrained_array): New function.
(ada_check_typedef): Use it.
Tested on x86_64-linux.
Using this Ada code:
type Union_Type (A : Boolean := False) is record
case A is
when True => B : Integer;
when False => C : Float;
end case;
end record;
pragma Unchecked_Union (Union_Type);
Ut : Union_Type := (A => True, B => 3);
In GDB/MI mode, once creating a varobj from variable "Ut" as follow:
(gdb) -var-create var1 * ut
^done,name="var1",numchild="2",value="{...}",type="foo.union_type",thread-id="1",has_more="0"
Printing the list of its children displays:
(gdb) -var-list-children 1 var1
^error,msg="Duplicate variable object name"
Whereas it should be
(gdb) -var-list-children 1 var1
^done,numchild="2",children=[child={name="var1.b",exp="b",numchild="0",value="3",type="integer",thread-id="1"},child={name="var1.c",exp="c",numchild="0",value="4.20389539e-45",type="float",thread-id="1"}],has_more="0"
The problem occurs because ada_varobj_describe_struct_child wasn't
handling unions. This patch fixes this.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_describe_struct_child)
(ada_varobj_describe_child): Handle union case like struct one.
testsuite/ChangeLog
* gdb.ada/mi_var_union.exp: New testcase.
* gdb.ada/mi_var_union/bar.adb: New file.
* gdb.ada/mi_var_union/pck.adb: New file.
* gdb.ada/mi_var_union/pck.asd: New file.
Tested on x86_64-linux.
This removes the remaining trailing periods from the Python section
titles. I thought these looked weird and I don't this is generally
done in the gdb documentation.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
* python.texi (Frames In Python, Blocks In Python)
(Symbols In Python, Symbol Tables In Python)
(Lazy Strings In Python): Remove periods from section titles.
I thought the start of the Pretty Printing API node read a bit
strangely. This patch swaps the first two sentences, which seems
better.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
* python.texi (Pretty Printing API): Swap sentence order.
PR python/16461 asks that the Python dynamic_type documentation
mention virtual tables; this patch implements that request.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/16461:
* python.texi (Values From Inferior): Mention use of virtual
table.
I noticed that the decode_line documentation did not have parens
around the argument:
-- Function: gdb.decode_line [expression]
This patch fixes this oversight.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Parenthesize argument to
decode_line.
This updates python.texi to note that gdb can be compiled against
either major version of Python. It also removes the "execfile"
example, because that is specific to Python 2.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
* python.texi (Python): Mention Python versions. Don't mention
execfile.
PR python/19808 points out a few issues in the Python unwinder
documentation. This patch update the documentation for
create_unwind_info and read_register to address the issues noted, and
adds a cautionary note about writing an unwinder.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/19808:
* python.texi (Unwinding Frames in Python): Rewrite
create_unwind_info documentation. Update read_register
documentation and add a note about unwinder caution.
PR python/18909 points out that the gdb.events.inferior_call
documentation was incorrect. This patch brings it in line with the
code.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/18909:
* python.texi (Events In Python): Fix inferior_call
documentation.
This fixes a few frame filter documentation omissions noted in
PR python/17752.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/17752:
* python.texi (Frame Filter API): Remove period from subsection
title. Mention 100 as good default priority.
(Frame Decorator API): Remove period from subsection title.
Mention FrameDecorator module.
PR python/23108 points out that the gdb.GdbError documentation is
somewhat difficult to find. The exception is apparently just
mentioned in passing. This patch introduces a new table and adds a
bit more text to try to make it more obvious.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/23108:
* python.texi (Exception Handling): Rearrange gdb.GdbError text
and add a table.
"make info" gives a number of warnings about the use of a "." in
@ref-like commands. These come from the ".info" suffix. I think this
suffix is redundant, and removing the suffix also removes the warning.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Compilation): Use "gcc", not "gcc.info", in @xref.
(Machine Code): Use "binutils", not "binutils.info", in @pxref.
(Separate Debug Files): Use "ld", not "ld.info", in @ref.
* python.texi (Objfiles In Python): Use "ld", not "ld.info", in @ref.
PR python/18380 points out that the example in the "help python" text
will only work in Python 2. This changes the example to be valid
syntax for both Python 2 and Python 3.
gdb/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/18380:
* python/python.c (_initialize_python): Make example in "python"
help work in Python 3.
PR python/16484 points out that Frame.block can throw an exception,
but this is not documented.
This patch fixes the documentation. Changing Frame.block to return
None would be nice, but I suspect it's too late for that change.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/16484:
* python.texi (Frames In Python): Document that Frame.block can
throw.
PR python/23487 points out that the "disable pretty-printer" example
has a typo that makes it incorrect. This patch fixes the typo.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/23487:
* gdb.texinfo (Pretty-Printer Commands): Fix typo in example.
PR python/16033 points out that Block.end doesn't describe whether it
is inclusive or exclusive. This patch fixes the documentation.
gdb/doc/ChangeLog
2018-09-10 Tom Tromey <tom@tromey.com>
PR python/16033:
* python.texi (Blocks In Python): Document that Block.end is
exclusive.
gdb/ChangeLog:
2018-09-10 Eli Zaretskii <eliz@gnu.org>
* Makefile.in (transformed_name): Use INSTALL_SCRIPT instead of
INSTALL_PROGRAM to install gdb-add-index.sh. Don't append
$(EXEEXT) to the script, as it is not a program.
I noticed that we release a gdbpy_ref in pretty_print_one_value only to
create it again later. This patch fills the gap by returning a
gdbpy_ref all the way.
gdb/ChangeLog:
* python/py-prettyprint.c (pretty_print_one_value): Return
gdbpy_ref<>.
(print_string_repr): Adjust.
(apply_varobj_pretty_printer): Return gdbpy_ref<>.
* python/python-internal.h (apply_varobj_pretty_printer): Return
gdbpy_ref<>.
* varobj.c (varobj_value_get_print_value): Adjust.
I noticed that the py-prettyprint.exp test names were not unique.
This patch fixes the problem via with_test_prefix.
gdb/testsuite/ChangeLog
2018-09-08 Tom Tromey <tom@tromey.com>
* gdb.python/py-prettyprint.exp: Use with_test_prefix.
PR python/16047 points out that, while the documentation says that the
to_string method is optional for a pretty-printer, the code disagrees
and throws an exception. This patch fixes the problem. varobj is
already ok here.
Tested on x86-64 Fedora 26.
gdb/ChangeLog
2018-09-08 Tom Tromey <tom@tromey.com>
PR python/16047:
* python/py-prettyprint.c (pretty_print_one_value): Check for
to_string method.
gdb/testsuite/ChangeLog
2018-09-08 Tom Tromey <tom@tromey.com>
PR python/16047:
* gdb.python/py-prettyprint.py (pp_int_typedef3): New class.
(register_pretty_printers): Register new printer.
* gdb.python/py-prettyprint.exp (run_lang_tests): Add int_type3
test.
* gdb.python/py-prettyprint.c (int_type3): New typedef.
(an_int_type3): New global.
Consider the following function, which takes no parameter and returns
an integer:
function Something return Integer;
For the purpose of this discussion, our function has been implemented
to always return 124:
function Something return Integer is
begin
return 124;
end Something;
In Ada, such function can been called without using the parentheses.
For instance, in the statement below, variable My_Value is assigned
the returned value from the call to Something:
My_Value := Something;
The Ada expression interpeter in GDB supports this case, as we can
see below:
(gdb) print something
$1 = 124
However, we get fairly strange results when trying to use this feature
as part of a larger expression. For instance:
(gdb) print something + 1
$2 = 248
The problem occurs while doing the resolution pass of the expression.
After prefixying the expression, we obtain the following expression:
0 BINOP_ADD
1 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
5 OP_LONG Type @0x1e3c170 (int), value 1 (0x1)
The resolution pass is then expected to remove the OP_VAR_VALUE
entry, and replace it with an OP_FUNCALL. This is what the call
to replace_operator_with_call in ada-lang.c::resolve_subexp is
expected to do:
if (deprocedure_p
&& (TYPE_CODE (SYMBOL_TYPE (exp->elts[pc + 2].symbol))
== TYPE_CODE_FUNC))
{
replace_operator_with_call (expp, pc, 0, 0,
exp->elts[pc + 2].symbol,
exp->elts[pc + 1].block);
exp = expp->get ();
}
The problem is that we're passing OPLEN (zero -- 4th parameter in
the call), and so replace_operator_with_call ends up removing zero
element from our expression, and inserting the corresponding OP_FUNCALL
instead. As a result, instead of having the OP_LONG (1) as the second
argument of the BINOP_ADD, it is now the OP_VAR_VALUE that we were
meant to replace. That OP_VAR_VALUE then itself gets transformed into
an OP_FUNCALL, with the same issue, and eventually, the resolved
expression now looks like this:
0 BINOP_ADD
1 OP_FUNCALL Number of args: 0
4 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
8 OP_FUNCALL Number of args: 0
11 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
15 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
19 OP_LONG Type @0x1e3c170 (int), value 1 (0x1)
This explains why we get twice the result of the function call
instead of its value plus one. The extra entries in the expression
at the end are just ignored.
This patch fixes the issue by calling replace_operator_with_call
with the correct OPLEN equal to the size of an OP_VAR_VALUE (4).
gdb/ChangeLog:
* ada-lang.c (resolve_subexp): Pass correct OPLEN in call to
replace_operator_with_call.
gdb/testsuite/ChangeLog:
* gdb.ada/expr_with_funcall: New testcase.
Consider the following code:
type Enumerated is (Enum_A, Enum_B, Enum_C, Enum_Last);
type Table is array (Enumerated) of Integer;
-- Declare a variable of type Table to make sure the compiler
-- does emit the debugging information for that type.
V : Table := (others => 1);
Trying to print the type description of type Table, or of variable V
yields:
(gdb) ptype v
type = array (0 .. 3) of integer
(gdb) ptype example.table
type = array (0 .. 3) of integer
The compiler generates an XA type for the bounds...
<1><cf6>: Abbrev Number: 13 (DW_TAG_structure_type)
<cf7> DW_AT_name : example__table___XA
... whose member is described as being as:
<2><cfe>: Abbrev Number: 14 (DW_TAG_member)
<cff> DW_AT_name : example__enumerated
<d05> DW_AT_type : <0xc69>
This leads us to DIE 0xc69, which is our enumeration type:
<2><c69>: Abbrev Number: 4 (DW_TAG_enumeration_type)
<c6a> DW_AT_name : example__enumerated
Normally, for arrays, we expect a range type, rather than an enumerated
type. However, for a situation like this, where the range of the array
index is the full enumeration type, it seems like a waste to require
an extra range layer.
Instead, looking at print_range, we see that we print the bounds
of our range using the target type:
target_type = TYPE_TARGET_TYPE (type);
if (target_type == NULL)
target_type = type;
[...]
ada_print_scalar (target_type, lo, stream);
fprintf_filtered (stream, " .. ");
ada_print_scalar (target_type, hi, stream);
In this case, this causes us to use the enumerated type's subtype,
which is a plain integer type, hence the output we get. However,
there is no reason for using the target type, even in the TYPE_CODE_RANGE
situation. So this patch fixes the issue by simply printing the bounds
using the type being given, instead of its target type.
gdb/ChangeLog:
* ada-typeprint.c (print_range): Print the bounds using TYPE
rather than its TYPE_TARGET_TYPE.
A new test for this isn't necessary, as existing tests will demonstrate
this issue once a change in the compiler triggering the generation of
this type of debugging info gets pushed.
The arguments in the call to ada_to_fixed_value_create where
improperly aligned. But I also noticed that all the arguments
do fit on a single-line (up to 79 characters). So this patch
just fixes the code by putting everything on that same line.
gdb/ChangeLog:
* ada-lang.c (ada_to_fixed_value): Minor reformatting in
call to ada_to_fixed_value_create.
On PPC64, the entry point of the function "FN" is ".FN" when a function
descriptor is used. One of the consequences of this is that GDB then
presents the name of the function to the user (eg: in backtraces) with
the leading dot, which is a low-level internal detail that the user
should not be seeing. The Ada decoding should strip it.
gdb/ChangeLog:
* ada-lang.c (ada_decode): strip dot prefix in symbol name.
No testcase added, as a number of existing testcases should already
demonstrate that problem.
We noticed while debugging a program compiled without assertions
enabled and using an older compiler that inserting a catchpoint
on failed assertions would cause an internal error:
(gdb) catch assert
../../src/gdb/ada-lang.c:13321: internal-error: ada_exception_sal:
Assertion`sym != NULL' failed.
A problem internal to GDB has been detected,
This is due to a combination of factors:
1. With older versions of the compiler, the function used as a hook
was provided by a unit that's different from the unit which
provides the hooks for the other exception catchpoints.
2. The program either does not use any assertion, or is compiled
without the assertions enabled.
With newer versions of the compiler, all such functions are provided
by the same unit, so should normally always be available. However,
there can still be reasons why this is not the case. Consider, for
instance, the case of a runtime compiled with -ffunction-sections,
in which case the hook might be eliminated unless assertions are
used and enabled.
So this patch transforms the internal error into a simple error.
gdb/ChangeLog:
* ada-lang.c (ada_exception_sal): Replace gdb_assert calls
by calls to error.
No testcase added, as the existing testcase gdb.ada/catch_ex.exp
should trigger it when using an older version of GNAT as the Ada
compiler.
When debugging a program compiled with an older version of GNAT,
hitting a catchpoint on unhandled exceptions can caused GDB to
got into an infinite loop. This happens while trying to find
the name of the exception that was raised. For that, it searches
for a frame corresponding to a specific function we know gets
called during the exeption handling.
In our particular case, the compiler was too old, and so GDB never
found that frame, and eventually got past the "main" subprogram,
all the way to system frames, where no symbol was available.
As a result, the code addresses could not be resolved into
a function name, leading to the infinite loop because of
a misplaced update of our loop variable "fi":
while (fi != NULL)
{
char *func_name;
enum language func_lang;
find_frame_funname (fi, &func_name, &func_lang, NULL);
if (func_name != NULL)
{
make_cleanup (xfree, func_name);
if (strcmp (func_name,
data->exception_info->catch_exception_sym) == 0)
break; /* We found the frame we were looking for... */
fi = get_prev_frame (fi);
}
}
If FUNC_NAME is NULL, then FI never gets updated ever after!
gdb/ChangeLog:
* ada-lang.c (ada_unhandled_exception_name_addr_from_raise):
Move update of loop variable "fi".
No testcase added, as the existing testcase gdb.ada/catch_ex.exp
should trigger it when using an older version of GNAT as the Ada
compiler.
Consider a variable "PRA" defined as a packed array of packed
records as follow:
subtype Int is Integer range 0 .. 7;
type Packed_Rec is record
X, Y : Int;
W : Integer;
end record;
pragma Pack (Packed_Rec);
type Packed_RecArr is array (Integer range <>) of Packed_Rec;
pragma Pack (Packed_RecArr);
PRA : Packed_RecArr (1 .. 3);
Consider also a variable "PR", which is a Packed_Rec record,
declared as follow:
PR : Packed_Rec := (2, 2, 2);
Trying to assign a new value to PRA using an aggregate expression
where one of the components is our variable PR yields the wrong
result on big-endian machines (e.g. on ppc-linux):
(gdb) p pra := (pr, (2,2,2), (2,2,2))
$6 = ((x => 1, y => 0, w => 8), [...]
On the other hand, replacing "pr" by "(2,2,2)" does work.
I tracked the issue down to the bit offset we use to extract
the value of "PR" and copy it inside PRA. in value_assign_to_component,
we have:
if (gdbarch_bits_big_endian (get_type_arch (value_type (container))))
move_bits ([target buffer], [bit offset in target buffer],
[source buffer where PR is stored],
TYPE_LENGTH (value_type (component)) * TARGET_CHAR_BIT - bits,
bits, 1);
The issue is with the third-to-last argument, which provides the bit
offset where the value of PR is stored relative to its start address,
and therefore the bit offset relative to the start of the source
buffer passed as the previous argument.
In our case, component is a 38bit packed record whose TYPE_LENGTH
is 5 bytes, so the bit-offset that gets calculated is 2 (bits).
However, that formula only really applies to scalars, whereas
in our case, we have a record (struct). The offset in the non-scalar
case should be zero.
gdb/ChangeLog:
* ada-lang.c (value_assign_to_component): In the case of
big-endian targets, extract the bits of the given VAL
using an src_offset of zero if container is not a scalar.
gdb/testsuite/ChangeLog:
* gdb.ada/packed_array_assign: New testcase.
Add int24 and uint24. These are used by the upcoming S12Z target, but will be
needed for any arch which features 24 bit registers.
* gdb/gdbtypes.h (struct builtin_type): New members builtin_int24
and builtin_uint24;
* gdb/gdbtypes.c: Initialize them.
* gdb/doc/gdb.texinfo (Predefined Target Types): Mention types int24 and uint24.
Extend test names and add test name prefixes to make test names
unique.
gdb/testsuite/ChangeLog:
* gdb.base/watchpoint.exp (test_complex_watchpoint): Extend test
names, and add test prefixes to make test names unique.
gcore generates NT_AUXV and NT_FILE notes for Linux targets. On
FreeBSD auxv is stored in a NT_PROCSTAT_AUXV section, virtual memory
mappings are stored in a NT_PROCSTAT_VMMAP, and both are prefixed with
the struct size. In addition, store a NT_PROCSTAT_PS_STRINGS note
saving the initial location of the argv[] and environment[] arrays.
gdb/ChangeLog:
PR gdb/23105
* fbsd-nat.c (fbsd_nat_target::xfer_partial): Add support for
TARGET_OBJECT_FREEBSD_VMMAP and TARGET_OBJECT_FREEBSD_PS_STRINGS.
* fbsd-tdep.c (fbsd_make_note_desc): New.
(fbsd_make_corefile_notes): Write NT_PROCSTAT_AUXV,
NT_PROCSTAT_VMMAP and NT_PROCSTAT_PS_STRINGS notes.
* target.h (enum target_object) Add FreeBSD-specific
TARGET_OBJECT_FREEBSD_VMMAP and TARGET_OBJECT_FREEBSD_PS_STRINGS.
After looking into why the build failed for Simon but not for me, we
found that the underlying cause was due to how gcc treats
-Wformat-nonliteral. gcc requires -Wformat to be given first; but
warning.m4 was not doing this, so -Wformat-nonliteral was not being
used.
This patch changes warning.m4 to account gcc's requirement.
This then showed that the target-float.c build change in the earlier
Makefile patch was also incorrect. Simon didn't see this in his
build, but gcc now points it out. So, this patch fixes this problem
as well.
2018-09-05 Tom Tromey <tom@tromey.com>
* warning.m4 (AM_GDB_WARNINGS): Add -Wformat when testing
-Wformat-nonliteral.
* target-float.c (host_float_ops<T>::to_string)
(host_float_ops<T>::from_string): Use
DIAGNOSTIC_IGNORE_FORMAT_NONLITERAL.
* configure: Rebuild.
gdb/gdbserver/ChangeLog
2018-09-05 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
commit 3322c5d9a1 ("Remove unneeded explicit .o targets") broke the
build with clang, because -Wno-format-nonliteral was in fact needed.
This patch fixes the problem by introducing
DIAGNOSTIC_IGNORE_FORMAT_NONLITERAL and using it in printcmd.c. This
seems preferable to reverting the patch because now the warning
suppression is more targeted.
gdb/ChangeLog
2018-09-05 Simon Marchi <simon.marchi@ericsson.com>
* printcmd.c (printf_c_string): Use
DIAGNOSTIC_IGNORE_FORMAT_NONLITERAL.
(printf_wide_c_string, printf_pointer, ui_printf): Likewise.
include/ChangeLog
2018-09-05 Simon Marchi <simon.marchi@ericsson.com>
* diagnostics.h (DIAGNOSTIC_IGNORE_FORMAT_NONLITERAL): New macro.
I noticed a couple of unnecessary casts in cli-cmds.c. This patch
removes them.
Tested by rebuilding. I'm checking this in.
gdb/ChangeLog
2018-09-05 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (shell_escape, edit_command): Remove cast.
Consider a vla variable 'a' in function f1:
...
<2><1a7>: Abbrev Number: 11 (DW_TAG_variable)
<1a8> DW_AT_description : a
<1aa> DW_AT_abstract_origin: <0x311>
...
with abstract origin 'a':
...
<2><311>: Abbrev Number: 3 (DW_TAG_variable)
<312> DW_AT_name : a
<317> DW_AT_type : <0x325>
...
and inherited abstract vla type:
...
<1><325>: Abbrev Number: 9 (DW_TAG_array_type)
<326> DW_AT_type : <0x33a>
<2><32e>: Abbrev Number: 10 (DW_TAG_subrange_type)
<32f> DW_AT_type : <0x2ea>
<333> DW_AT_upper_bound : 5 byte block: fd 1b 3 0 0
(DW_OP_GNU_variable_value: <0x31b>)
...
where the upper bound refers to this artificial variable D.1922 without location
attribute:
...
<2><31b>: Abbrev Number: 8 (DW_TAG_variable)
<31c> DW_AT_description : (indirect string, offset: 0x39a): D.1922
<320> DW_AT_type : <0x2ea>
<324> DW_AT_artificial : 1
...
Currently, when we execute "p sizeof (a)" in f1, the upper bound is calculated
by evaluating the DW_OP_GNU_variable_value expression referring to D.1922, but
since that die doesn't have a location attribute, we get:
...
value has been optimized out
...
However, there's also artificial variable D.4283 that is sibling of vla
variable 'a', has artificial variable D.1922 as abstract origin, and has a
location attribute:
...
<2><1ae>: Abbrev Number: 12 (DW_TAG_variable)
<1af> DW_AT_description : (indirect string, offset: 0x1f8): D.4283
<1b3> DW_AT_abstract_origin: <0x31b>
<1b7> DW_AT_location : 11 byte block: 75 1 8 20 24 8 20 26 31 1c 9f
(DW_OP_breg5 (rdi):1; DW_OP_const1u: 32;
DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra;
DW_OP_lit1; DW_OP_minus; DW_OP_stack_value)
...
The intended behaviour for DW_OP_GNU_variable_value is to find a die that
refers to D.1922 as abstract origin, has a location attribute and is
'in scope', so the expected behaviour is:
...
$1 = 6
...
The 'in scope' concept can be thought of as variable D.1922 having name
attribute "D.1922", and variable D.4283 inheriting that attribute, resulting
in D.4283 being declared with name "D.1922" alongside vla a in f1, and when we
lookup "DW_OP_GNU_variable_value D.1922", it should work as if we try to find
the value of a variable named "D.1922" on the gdb command line using
"p D.1922", and we should return the value of D.4283.
This patch fixes the case described above, by:
- adding a field abstract_to_concrete to struct dwarf2_per_objfile,
- using that field to keep track of which concrete dies are instances of an
abstract die, and
- using that information when getting the value DW_OP_GNU_variable_value.
Build and reg-tested on x86_64-linux.
2018-09-05 Tom de Vries <tdevries@suse.de>
* dwarf2loc.c (sect_variable_value): Call indirect_synthetic_pointer
with resolve_abstract_p == true.
(indirect_synthetic_pointer): Add resolve_abstract_p parameter,
defaulting to false. Propagate resolve_abstract_p to
dwarf2_fetch_die_loc_sect_off.
* dwarf2loc.h (dwarf2_fetch_die_loc_sect_off): Add resolve_abstract_p
parameter, defaulting to false.
* dwarf2read.c (read_variable): Add variable to abstract_to_concrete.
(dwarf2_fetch_die_loc_sect_off): Add and handle resolve_abstract_p
parameter.
* dwarf2read.h (struct die_info): Forward-declare.
(die_info_ptr): New typedef.
(struct dwarf2_per_objfile): Add abstract_to_concrete field.
* gdb.dwarf2/varval.exp: Add test.
When we update gnulib using our "update-gnulib.sh" tool, it doesn't
automatically update the list of M4 files present at
gnulib/Makefile.in:aclocal_m4_deps. This patch extends the tool to do
that. It also puts "aclocal_m4_deps" in its own file (a Makefile
fragment), so that it's easier to update it programatically.
Tested by generating the file and diff'ing the results against the
current version of "aclocal_m4_deps".
gdb/ChangeLog:
2018-09-04 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* gnulib/Makefile.in (aclocal_m4_deps): Move to
"aclocal-m4-deps.mk". Include file here.
$(srcdir)/aclocal.m4: Add "configure.ac".
* gnulib/aclocal-m4-deps.mk: New file.
* gnulib/update-gnulib.sh: Automatically update
"aclocal-m4-deps.mk".
Alan Hayward
Andrew Burgess
Simon Marchi
Tom Tromey
Jozef Lawrynowicz
Rainer Orth
Jon Turney
Yacov Simhony
Hafiz Abid Qadeer
Sandra Loosemore
Xavier Roirand
John Baldwin
Richard Bunt
Sergio Durigan Junior
Philippe Waroquiers
Pedro Alves
Simon Marchi
Jan Kratochvil
Jerome Guitton
Eli Zaretskii
Joel Brobecker
John Darrington
Simon Ser
Tom de Vries