A while back I typed "info pretty-printers" with a large number of
printers installed, and I typed "q" to stop the pagination. I noticed
that gdb printed a Python exception in this case.
It seems to me that, instead, quitting pagination (or control-c'ing a
Python command generally) should be handled the same way that gdb
normally handles a quit.
This patch implements this idea by changing gdbpy_handle_exception to
treat PyExc_KeyboardInterrupt specially.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* python/py-utils.c (gdbpy_handle_exception): Translate
PyExc_KeyboardInterrupt to quit.
gdb/testsuite/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* gdb.python/py-cmd.exp (test_python_inline_or_multiline): Add
pagination test.
A few places in the Python code would either call gdbpy_print_stack,
or throw a gdb "quit", depending on the pending exception. This patch
consolidates these into a helper function.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* python/python-internal.h (gdbpy_print_stack_or_quit): Declare.
* python/py-unwind.c (pyuw_sniffer): Use
gdbpy_print_stack_or_quit.
* python/py-framefilter.c (throw_quit_or_print_exception):
Remove.
(gdbpy_apply_frame_filter): Use gdbpy_print_stack_or_quit.
* python/python.c (gdbpy_print_stack_or_quit): New function.
I noticed a few places were converting a gdb exception to a Python
exception "by hand". It's better to use the existing
gdbpy_convert_exception helper function, as this handles memory errors
correctly, and in the future may be enhanced in other ways.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* python/py-value.c (convert_value_from_python): Use
gdbpy_convert_exception.
* python/py-param.c (parmpy_init): Use gdbpy_convert_exception.
* python/py-cmd.c (cmdpy_init): Use gdbpy_convert_exception.
* python/py-breakpoint.c (bppy_init): Use
gdbpy_convert_exception.
This moves the various "nat" object files into the nat/ subdirectory.
This allows for the removal of a pattern rule from the gdb Makefile,
which is a small cleanup.
I made the configure.nat change in a (semi-) automated way, hopefully
meaning that it is more likely to be correct than had I done it by
hand.
Eventually I would like for the various configure scripts to only
mention source files, and let the Makefile compute the object file
names.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* configure.nat (NATDEPFILES): Use nat/ prefix.
* Makefile.in (CONFIG_SRC_SUBDIR): Add nat.
(%.o: ${srcdir}/nat/%.c): Remove rule.
(INIT_FILES): Do not filter out NATDEPFILES.
I noticed that init.c depends on the object files that go into gdb.
Because init.c actually only requires the contents of the
corresponding source files, this unnecessarily serializes the step
that builds init.c.
This patch changes gdb's Makefile to make init.c depend on the source
files. This also simplifies the rule to build init.c.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* Makefile.in (INIT_FILES): Redefine.
(stamp-init): Remove sed, tr invocations. Use for loop. Don't
set LANG or LC_ALL.
The rule to make init.c has a special case for gdbtypes, with a long
explanatory comment. All of this is obsolete, as the globals referred
to by the comment no longer exist. This patch simplifies the rule.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* Makefile.in (stamp-init): Remove gdbtypes special case.
This changes minimal_symbol_reader to use DISABLE_COPY_AND_ASSIGN,
rather than the manual approach it currently uses.
Tested by rebuilding.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* minsyms.h (class minimal_symbol_reader): Use
DISABLE_COPY_AND_ASSIGN.
This changes the Python code to remove some more calls to xfree, in
favor of self-managing data structures.
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* python/python.c (python_interactive_command): Use std::string.
(gdbpy_parameter): Likewise.
* python/py-utils.c (unicode_to_encoded_string): Update comment.
* python/py-symtab.c (salpy_str): Use PyString_FromFormat.
* python/py-record-btrace.c (recpy_bt_insn_data): Use
byte_vector.
* python/py-objfile.c (objfpy_get_build_id): Use
unique_xmalloc_ptr.
* python/py-inferior.c (infpy_read_memory): Use
unique_xmalloc_ptr.
* python/py-cmd.c (gdbpy_parse_command_name): Use std::string.
The test fails due to conflict between var 'next' and s-pooloc.adb next:
(gdb) print next(1)
Multiple matches for next
[0] cancel
[1] pack.next (integer) return integer at /bd/home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/fun_renaming/pack.adb:19
[2] system.pool_local.next (system.address) return system.pool_local.acc_address at s-pooloc.adb:151
> FAIL: gdb.ada/fun_renaming.exp: print next(1) (timeout)
Fix by making the names and renamings more unique.
gdb/testsuite/ChangeLog
2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.ada/fun_renaming/pack.ads (Next): Rename to Fun_Rename_Test_Next.
(Renamed_Next): Rename to Renamed_Fun_Rename_Test_Next.
gdb.ada/fun_renaming/pack.adb (Next): Rename to Fun_Rename_Test_Next.
gdb.ada/fun_renaming/fun_renaming.adb (N): Rename to Fun_Rename_Test_N.
gdb.ada/fun_renaming.exp: Update accordingly.
With old compilers, the test fails because no debug info is generated
for 'B' and GDB finds some 'b' in atnat.h:
(gdb) print b
Multiple matches for b
[0] cancel
[1] b at ../sysdeps/ieee754/dbl-64/atnat.h:106
[2] b at ../sysdeps/ieee754/dbl-64/atnat.h:106
[3] b at ../sysdeps/ieee754/dbl-64/atnat.h:106
> FAIL: gdb.ada/rename_subscript_param.exp: print b before changing its value (timeout)
Avoid the timeout by renaming 'b' to rename_subscript_param_b.
Also, change 'before' to 'after' in the gdb_test message that prints
the value after changing it.
The test still fails with old compilers that do not properly
generate debug info for this renaming:
(gdb) print rename_subscript_param_b
No definition of "rename_subscript_param_b" in current context.
(gdb) FAIL: gdb.ada/rename_subscript_param.exp: print rename_subscript_param_b before changing its value
Note: if the compiler would generate the correct debug info, the test should
succeed with the name B. However, waiting for this fix, changing the name
ensures that the test fails directly, instead of causing a timeout.
2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
PR ada/23381
* gdb.ada/rename_subscript_param/pkg.adb (B): Rename to
Rename_Subscript_Param_B. All users updated.
gdb.ada/rename_subscript_param.exp: Test names made unique.
Note that PR ada/23381 is only fully fixed when using a recent
compiler.
The test gdb.ada/packed_array_assign fails due to conflict between component 'w'
and system.dim.mks.w:
(gdb) print pra := ((x => 2, y => 0, w => 17), pr, (x => 7, y => 1, w => 23))
Unknown component name: system.dim.mks.w.
(gdb) FAIL: gdb.ada/packed_array_assign.exp: print pra := ((x => 2, y => 0, w => 17), pr, (x => 7, y => 1, w => 23))
Also, depending on the compiler version, the component w might be reordered
and placed before components x and y.
So, change the component order in the source, so that both an old
compiler (GNATMAKE 6.3.0, gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516)
and a new compiler (GNATMAKE Pro 20.0w (20181210-82), based on gcc 8.2.1)
produce the same component order (checked by using -gnatR3s).
So, update to test the new (more unique) names in the source order.
2018-12-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.ada/packed_array_assign/aggregates.ads (Packed_Rec):
Rename components to Packed_Array_Assign_[X|Y|W]. Place
component Packed_Array_Assign_W as first component, to ensure
old and new compilers have the same representation.
All users updated.
I get this when compiling with a gcc 6.3.0-based cross-compiler:
CXX target.o
/home/simark/src/binutils-gdb/gdb/target.c: In static member function 'static void target_terminal::restore_inferior()':
/home/simark/src/binutils-gdb/gdb/target.c:396:10: error: types may not be defined in a for-range-declaration [-Werror]
for (struct inferior *inf : all_inferiors ())
^~~~~~
Accomodate it by dropping the unnecessary struct keyword. Actually, I used
"::inferior", otherwise it resolves to the inferior method of the
target_terminal class.
gdb/ChangeLog:
* target.c (target_terminal::restore_inferior): Remove struct keyword.
"set debug separate-debug-file" shows which candidates are considered,
when trying to find separate debug info. But it's not clear if GDB used
a certain candidate, and if not, why not. This patch adds some
precision:
Before:
Looking for separate debug info (debug link) for /lib/x86_64-linux-gnu/libc.so.6
Trying /lib/x86_64-linux-gnu/libc-2.23.so
Trying /lib/x86_64-linux-gnu/.debug/libc-2.23.so
Trying /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.23.so
After:
Looking for separate debug info (debug link) for /lib/x86_64-linux-gnu/libc.so.6
Trying /lib/x86_64-linux-gnu/libc-2.23.so... no, same file as the objfile.
Trying /lib/x86_64-linux-gnu/.debug/libc-2.23.so... no, unable to open.
Trying /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.23.so... yes!
gdb/ChangeLog:
* build-id.c (build_id_to_debug_bfd): Enhance debug output.
* symfile.c (separate_debug_file_exists): Likewise.
The 64-bit RISC-V target currently models the floating point registers
as having the following type:
union riscv_double
{
builtin_type_ieee_single float;
builtin_type_ieee_double double;
}
Notice the choice of names for the fields of this struct, possibly not
ideal choices, as these are not valid field names in C. However, this
type is only ever defined within GDB (or in the target description),
and no restriction seems to exist on the field names in that case.
The problem though is that currently:
(gdb) info registers $ft0
ft0 {float = 0, double = 0} (raw 0x0000000000000000)
(gdb) p $ft0.float
$1 = 0
(gdb) p $ft0.double
A syntax error in expression, near `double'.
We can access the 'float' field, but not the 'double' field. This is
because the string 'double' is handled differently to the string
'float' in c-exp.y.
In both cases the string '$ft0' is parsed as a VARIABLE expression.
In the 'float' case, the string 'float' becomes a generic NAME token
in 'lex_one_token', which then allows the rule "exp '.' name" to match
and the field name lookup to occur.
The 'double' case is different. In order to allow parsing of the type
string 'long double', the 'double' string becomes the token
DOUBLE_KEYWORD. At this point there's no rule to match "exp '.'
DOUBLE_KEYWORD", so we can never lookup the field named 'double'.
We could rename the fields for RISC-V, and maybe that would be the
best solution. However, its not hard to allow for fields named
'double', which is what this patch does.
A new case is added to the 'field_name' rule to match the
DOUBLE_KEYWORD, and create a suitable 'struct stoken'. With this done
the "exp '.' field_name" pattern can now match, and we can lookup the
double field.
With this patch in place I now see this behaviour:
(gdb) info registers $ft0
ft0 {float = 0, double = 0} (raw 0x0000000000000000)
(gdb) p $ft0.float
$1 = 0
(gdb) p $ft0.double
$2 = 0
I've gone ahead and handled INT_KEYWORD, LONG, SHORT, SIGNED_KEYWORD,
and UNSIGNED as well within field_name.
I've added a new test for this functionality.
This change was tested on x86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* c-exp.y (field_name): Allow DOUBLE_KEYWORD, INT_KEYWORD, LONG,
SHORT, SIGNED_KEYWORD, and UNSIGNED tokens to act as a field
names.
(typename_stoken): New function.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-unusual-field-names.c: New file.
* gdb.dwarf2/dw2-unusual-field-names.exp: New file.
Introduces a new rule in c-exp.y for matching structure field names.
This is a restructure in preparation for the next commit, this commit
shouldn't result in any user visible changes.
gdb/ChangeLog:
* c-exp.y (field_name): New %token, and new rule.
(exp): Replace uses of 'name' with 'field_name' where appropriate.
In an attempt to fix PR gdb/13368 this commit adds some comments to
c-exp.y which hopefully makes the type parsing code a little clearer.
There are no code changes here, so there should be no user visible
changes after this commit.
gdb/ChangeLog:
PR gdb/13368
* c-exp.y (typebase): Extend the comment.
(ident_tokens): Likewise.
In an earlier patch discussion we noticed that
dwarf2_find_containing_comp_unit takes the address of sect_off, but
doesn't actually need to. This is a leftover from before
C++-ification. This patch simplifies the function.
Tested using gdb.dwarf2 on x86-64 Fedora 28.
gdb/ChangeLog
2018-12-18 Tom Tromey <tom@tromey.com>
* dwarf2read.c (dwarf2_find_containing_comp_unit): Don't take
address of sect_off.
The test fails (timeout) due to:
(gdb) PASS: gdb.ada/bp_fun_addr.exp: break *a'address
run
Starting program: /bd/home/philippe/gdb/git/build_info_t/gdb/testsuite/outputs/gdb.ada/bp_fun_addr/a
Multiple matches for a
[0] cancel
[1] a at /bd/home/philippe/gdb/git/info_t/gdb/testsuite/gdb.ada/bp_fun_addr/a.adb:18
[2] system.dim.mks.a at s-dimmks.ads:115
> FAIL: gdb.ada/bp_fun_addr.exp: run until breakpoint at a'address (timeout)
testcase /home/philippe/gdb/git/build_info_t/gdb/testsuite/../../../info_t/gdb/testsuite/gdb.ada/bp_fun_addr.exp completed in 10 seconds
Fix this by using a fun name that has more chances to be unique.
2018-12-24 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.ada/bp_fun_addr/a.adb (a): Rename to bp_fun_addr.
Filename a.adb changed to bp_fun_addr.adb.
gdb.ada/bp_fun_addr.exp: Update test accordingly.
The existing code for reading and writing the return value can
overflow the passed in buffers in a couple of situations. This commit
aims to resolve these issues.
The problems were detected using valgrind, here are two examples,
first from gdb.base/structs.exp:
(gdb) p/x fun9()
==31353== Invalid write of size 8
==31353== at 0x4C34153: memmove (vg_replace_strmem.c:1270)
==31353== by 0x632EBB: memcpy (string_fortified.h:34)
==31353== by 0x632EBB: readable_regcache::raw_read(int, unsigned char*) (regcache.c:538)
==31353== by 0x659D3F: riscv_return_value(gdbarch*, value*, type*, regcache*, unsigned char*, unsigned char const*) (riscv-tdep.c:2593)
==31353== by 0x583641: get_call_return_value (infcall.c:448)
==31353== by 0x583641: call_thread_fsm_should_stop(thread_fsm*, thread_info*) (infcall.c:546)
==31353== by 0x59BBEC: fetch_inferior_event(void*) (infrun.c:3883)
==31353== by 0x53890B: check_async_event_handlers (event-loop.c:1064)
==31353== by 0x53890B: gdb_do_one_event() [clone .part.4] (event-loop.c:326)
==31353== by 0x6CA34B: wait_sync_command_done() (top.c:503)
==31353== by 0x584653: run_inferior_call (infcall.c:621)
...
And from gdb.base/call-sc.exp:
(gdb) advance fun
fun () at /gdb/gdb/testsuite/gdb.base/call-sc.c:41
41 return foo;
(gdb) finish
==1968== Invalid write of size 8
==1968== at 0x4C34153: memmove (vg_replace_strmem.c:1270)
==1968== by 0x632EBB: memcpy (string_fortified.h:34)
==1968== by 0x632EBB: readable_regcache::raw_read(int, unsigned char*) (regcache.c:538)
==1968== by 0x659D01: riscv_return_value(gdbarch*, value*, type*, regcache*, unsigned char*, unsigned char const*) (riscv-tdep.c:2576)
==1968== by 0x5891E4: get_return_value(value*, type*) (infcmd.c:1640)
==1968== by 0x5892C4: finish_command_fsm_should_stop(thread_fsm*, thread_info*) (infcmd.c:1808)
==1968== by 0x59BBEC: fetch_inferior_event(void*) (infrun.c:3883)
==1968== by 0x53890B: check_async_event_handlers (event-loop.c:1064)
==1968== by 0x53890B: gdb_do_one_event() [clone .part.4] (event-loop.c:326)
==1968== by 0x6CA34B: wait_sync_command_done() (top.c:503)
...
There are a couple of problems with the existing code, that are all
related.
In riscv_call_arg_struct we incorrectly rounded up the size of a
structure argument. This is unnecessary, and caused GDB to read too
much data into the output buffer when extracting a struct return
value.
In fixing this it became clear that we were incorrectly assuming that
any value being placed in a register (or read from a register) would
always access the entire register. This is not true, for example a
9-byte struct on a 64-bit target places 8-bytes in one registers and
1-byte in a second register (assuming available registers). To handle
this I switch from using cooked_read to cooked_read_part.
Finally, when processing basic integer return value types these are
extended to xlen sized types and then passed in registers. We
currently don't handle this type expansion in riscv_return_value, but
we do in riscv_push_dummy_call. The result is that small integer
types (like char) result in a full xlen sized register being written
into the output buffer, which results in buffer overflow. To address
this issue we now create a value of the expanded type and use this
values contents buffer to hold the return value before casting the
value down to the smaller expected type.
This patch resolves all of the valgrind issues I have found so far,
and causes no regressions. Tested against RV32/64 with and without
floating point support.
gdb/ChangeLog:
* riscv-tdep.c (riscv_call_arg_struct): Don't adjust size before
assigning locations.
(riscv_return_value): Take more care not to read/write outside of
argument buffer. Cast return value between the declared type and
the abi type.
We should save and restore the floating point status registers. This
became an issue when testing 32-bit float on a target with 64-bit with
the gdb.base/callfuncs.exp test.
gdb/ChangeLog:
* riscv-tdep.c (riscv_register_reggroup_p): Save and restore fcsr,
fflags, and frm registers.
Provide a mapping between GDB's register numbers and DWARF's register
numbers. This resolves some failures that I was seeing on
gdb.base/store.exp when running on an rv64imfdc target.
gdb/ChangeLog:
* riscv-tdep.c (riscv_dwarf_reg_to_regnum): New function.
(riscv_gdbarch_init): Register new function with gdbarch.
* riscv-tdep.h: New enum to define RISC-V DWARF register numbers.
While discussing this issue:
https://sourceware.org/ml/gdb-patches/2018-12/threads.html#00082
I added a printf gated by "set debug symtab-create" to be able to
quickly see all minimal symbols recorded by GDB. I thought it would be
useful to have it built-in, for the future. Here's how the output
looks:
Recording minsym: mst_data 0x400780 15 _IO_stdin_used
Recording minsym: mst_text 0x400700 13 __libc_csu_init
Recording minsym: mst_bss 0x601058 25 _end
gdb/ChangeLog:
* minsyms.c (mst_str): New.
(minimal_symbol_reader::record_full): Add debug output.
Various tests use test code written in i386 / x86_64 assembly that cannot
be used to create PIE executables. Therefore compilation of test programs
failed on systems where the compiler default is to create PIE executable.
The solution is to use -no-pie linker flag, however, such flag may not
(is not) supported by all compilers GDB needs to support (e.g. gcc 4.8).
To handle this, introduce a new flag to gdb_compile - nopie - which
inserts -no-pie linker flag where supported and is no-op where it is
not. By default, -no-pie flag is inserted since most modern compiler do
support it.
The ptrace command PT_LWPINFO to request detailed information about a
stopped thread can return stale signal information from an earlier
stop. Events which are reporting an intercepted signal will always
report the correct information, but signal stops for some other events
such as system call enter/exit events might include stale siginfo from
an earlier signal. In particular, if a thread reports a system call
entry or exit event after previously reporting a single-step or
breakpoint event via SIGTRAP, fbsd_handle_debug_trap believed the
system call event was the previous event and claimed it resulting in a
spurious SIGTRAP event.
True breakpoint and single-step events will never report another event
in the pl_flags member of struct ptrace_lwpinfo. Use this to detect
stale siginfo by requiring pl_flags to have only the PL_FLAG_SI flag
and no other flags before treating a SIGTRAP as a single-step or
breakpoint trap.
gdb/ChangeLog:
* fbsd-nat.c (fbsd_handle_debug_trap): Require pl.pl_flags to
equal PL_FLAG_SI.
(fbsd_nat_target::stopped_by_sw_breakpoint): Likewise.
Running `info os someUnknownOsType` is crashing when gdb is built with
-D_GLIBCXX_DEBUG:
/usr/include/c++/5/debug/vector:439:error: attempt to
access an element in an empty container.
In target_read_stralloc from target.c, the call to
target_read_alloc_1 can return an empty vector, we then call vector::back on
this vector, which is invalid.
This commit adds a check for emptiness before trying to call
vector::back on it. It also adds test to check for `info os <unknown>`
to return the proper error message.
This is a regression in gdb 8.2 and this patch restores the behavior of
previous versions.
gdb/ChangeLog:
PR gdb/23974
* target.c (target_read_stralloc): Check for empty vector.
gdb/testsuite/ChangeLog:
PR gdb/23974
* gdb.base/info-os.exp: Check return for unknown "info os" type.
When using the --configuration command line switch, or using
the "show configuration" command with a version of GDB which
was configured without Python supoprt, this patch changes
the resulting output to include...
--without-python
... instead of not printing anything about Python support.
gdb/ChangeLog:
* top.c (print_gdb_configuration): Print "--without-python"
if GDB was configured without Python.
Tested on x86_64-linux by rebuilding GDB with and without Python,
and checking the output of "gdb --configuration" in both cases.
Avoid compiler errors caused by trying to print CORE_ADDR using '%ld'
format, instead convert to a string and print that instead.
gdb/ChangeLog:
* riscv-tdep.c (riscv_scan_prologue): Use plongest to format
a signed offset as a string.
When compiling with clang 3.8 (default clang version on Debian
Stretch, the current stable), we get errors like this:
CXX dtrace-probe.o
../../binutils-gdb/gdb/dtrace-probe.c:103:31: error: default initialization of an object of const type 'const dtrace_static_probe_ops' without a user-provided default constructor
const dtrace_static_probe_ops dtrace_static_probe_ops;
^
Silence them by value-initializing those objects. It's not necessary
with other compilers (later clang versions, gcc), but it shouldn't
hurt either.
* elf32-i386.c (elf_i386_relocate_section): Call
elf_i386_rtype_to_howto to get reloc_howto_type pointer.
* elf64-x86-64.c (elf_x86_64_relocate_section): Call
elf_x86_64_rtype_to_howto to get reloc_howto_type pointer.
standard_ada_testfile, standard_test_file and the explicit
csrcfile assignment in info_auto_lang.exp all gives similar pathnames
prefix for a source, such as
/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>.
Note that the above pathnames contain ../ which appears when a relative
pathname is used to call configure.
In any case, the gnat compiler normalizes Ada sources path when compiling.
So, the 'Ada' .o object are referencing a pathname such as
/home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb,
while the 'C' .o object still references the not normalized pathname.
As the results of 'info functions | ...' are sorted by pathname first,
the order of the results depends on the comparison between different directories,
leading to results that can change depending on these directories.
=> Ensure the result order is always the same, by normalising the C source file,
which makes the results independent of the way configure is launched.
Tested by running the testcase in 2 different builds, that without normalize
were giving different results.
Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C.
After discussion, it was deemed sufficient to just normalize the pathname
for this test.
gdb/testsuite/ChangeLog
2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.ada/info_auto_lang.exp: Normalize some_c source file.
Update order of results accordingly.
Supply default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp. This patch doesn't actually
convert any targets to use these methods, and so, there will be no
user visible changes after this commit.
The implementations for default_dummy_id and default_unwind_sp are
fairly straight forward, these just take on the pattern used by most
targets. Once these default methods are in place then most targets
will be able to switch over.
The implementation for default_unwind_pc is also fairly straight
forward, but maybe needs some explanation.
This patch has gone through a number of iterations:
https://sourceware.org/ml/gdb-patches/2018-03/msg00165.htmlhttps://sourceware.org/ml/gdb-patches/2018-03/msg00306.htmlhttps://sourceware.org/ml/gdb-patches/2018-06/msg00090.htmlhttps://sourceware.org/ml/gdb-patches/2018-09/msg00127.html
and the implementation of default_unwind_pc has changed over this
time. Originally, I took an implementation like this:
CORE_ADDR
default_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
{
int pc_regnum = gdbarch_pc_regnum (gdbarch);
return frame_unwind_register_unsigned (next_frame, pc_regnum);
}
This is basically a clone of default_unwind_sp, but using $pc. It was
pointed out that we could potentially do better, and in version 2 the
implementation became:
CORE_ADDR
default_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
{
struct type *type;
int pc_regnum;
CORE_ADDR addr;
struct value *value;
pc_regnum = gdbarch_pc_regnum (gdbarch);
value = frame_unwind_register_value (next_frame, pc_regnum);
type = builtin_type (gdbarch)->builtin_func_ptr;
addr = extract_typed_address (value_contents_all (value), type);
addr = gdbarch_addr_bits_remove (gdbarch, addr);
release_value (value);
value_free (value);
return addr;
}
The idea was to try split out some of the steps of unwinding the $pc,
steps that are on some (or many) targets no-ops, and so allow targets
that do override these methods, to make use of default_unwind_pc.
This implementation remained in place for version 2, 3, and 4.
However, I realised that I'd made a mistake, most targets simply use
frame_unwind_register_unsigned to unwind the $pc, and this throws an
error if the register value is optimized out or unavailable. My new
proposed implementation doesn't do this, I was going to end up
breaking many targets.
I considered duplicating the code from frame_unwind_register_unsigned
that throws the errors into my new default_unwind_pc, however, this
felt really overly complex. So, what I instead went with was to
simply revert back to using frame_unwind_register_unsigned. Almost
all existing targets already use this. Some of the ones that don't can
be converted to, which means almost all targets could end up using the
default.
One addition I have made over the version 1 implementation is to add a
call to gdbarch_addr_bits_remove. For most targets this is a no-op,
but for a handful, having this call in place will mean that they can
use the default method. After all this, the new default_unwind_pc now
looks like this:
CORE_ADDR
default_unwind_pc (struct gdbarch *gdbarch, struct frame_info *next_frame)
{
int pc_regnum = gdbarch_pc_regnum (gdbarch);
CORE_ADDR pc = frame_unwind_register_unsigned (next_frame, pc_regnum);
pc = gdbarch_addr_bits_remove (gdbarch, pc);
return pc;
}
gdb/ChangeLog:
* gdb/dummy-frame.c (default_dummy_id): Defined new function.
* gdb/dummy-frame.h (default_dummy_id): Declare new function.
* gdb/frame-unwind.c (default_unwind_pc): Define new function.
(default_unwind_sp): Define new function.
* gdb/frame-unwind.h (default_unwind_pc): Declare new function.
(default_unwind_sp): Declare new function.
* gdb/frame.c (frame_unwind_pc): Assume gdbarch_unwind_pc is
available.
(get_frame_sp): Assume that gdbarch_unwind_sp is available.
* gdb/gdbarch.c: Regenerate.
* gdb/gdbarch.h: Regenerate.
* gdb/gdbarch.sh: Update definition of dummy_id, unwind_pc, and
unwind_sp. Add additional header files to be included in
generated file.
For PLT expressions, we should subtract the PLT relocation size only for
jump instructions. Since PLT relocations are PC relative, we only allow
"symbol@PLT" in PLT expression.
gas/
PR gas/23997
* config/tc-i386.c (x86_cons): Check for invalid PLT expression.
(md_apply_fix): Subtract the PLT relocation size only for jump
instructions.
* testsuite/gas/i386/reloc32.s: Add test for invalid PLT
expression.
* testsuite/gas/i386/reloc64.s: Likewise.
* testsuite/gas/i386/ilp32/reloc64.s: Likewise.
* testsuite/gas/i386/reloc32.l: Updated.
* testsuite/gas/i386/reloc64.l: Likewise.
* testsuite/gas/i386/ilp32/reloc64.l: Likewise.
ld/
PR gas/23997
* testsuite/ld-i386/i386.exp: Run PR gas/23997 test.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-x86-64/pr23997a.s: New file.
* testsuite/ld-x86-64/pr23997b.c: Likewise.
* testsuite/ld-x86-64/pr23997c.c: Likewise.
A recent patch [1] to fix a GCC PR [2] actually broke the GDB build.
To fix, remove the stack pointer clobber. GCC will ignore the clobber
marker, and will not save or restore the stack pointer.
I ran "make check-gdb" on x86_64 to ensure there are no regressions.
gdb/ChangeLog:
2018-12-17 Dimitar Dimitrov <dimitar@dinux.eu>
* nat/linux-ptrace.c (linux_ptrace_test_ret_to_nx): Remove sp clobbers.
[1] https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00532.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
This test checks code layout by function symbol ordering, but that
doesn't work on powerpc64 ELFv1 where the function symbol is on a
descriptor. A simple work-around is to have nm emit synthetic symbols
marking the code entry point of functions. Since the text segment is
laid out before the data segment, the synthetic symbols will have
lower addresses than function descriptor symbols and be seen first in
nm -n output.
On other targets, nm --synthetic typically emits symbols on plt
entries. Since the testcase doesn't call any of the functions of
interest there shouldn't be plt entries for those functions, so there
should be no potentially confusing extra symbols.
* testsuite/Makefile.am (keep_text_section_prefix_nm.stdout):
Pass --synthetic to nm.
* testsuite/Makefile.in: Regenerate.
