Jaydeep Patil [Thu, 1 Feb 2024 04:42:27 +0000 (04:42 +0000)]
sim: riscv: Add support for compressed integer instructions
Added support for simulation of compressed integer instruction set ("c").
Added test file sim/testsuite/riscv/c-ext.s to test compressed instructions.
The compressed instructions are available for models implementing C extension.
Such as RV32IC, RV64IC, RV32GC, RV64GC etc.
Tom de Vries [Tue, 13 Feb 2024 08:10:54 +0000 (09:10 +0100)]
[gdb/tdep] Fix reverse execution of LDR(immediate) T4
When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux with
target board unix/-mthumb, we run into:
...
(gdb) reverse-step
func2 () at func-map-to-same-line.c:26
26 {
(gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \
column_info_flag=column-info: step-test: reverse-step into func2
...
The FAIL is caused by incorrect recording of this insn:
...
4f6: f85d 7b04 ldr.w r7, [sp], #4
...
The insn updates the sp, but we don't record this:
...
$ gdb -q -batch func-map-to-same-line \
-ex "b *func2+8" \
-ex run \
-ex record \
-ex "set debug record 2" \
-ex stepi
Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27.
Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27
27 } /* END FUNC2 */
Process record: arm_process_record addr = 0xaaaaa4f6
Process record: add register num = 15 to record list.
Process record: record_full_arch_list_add 0xabc6c460.
Process record: add register num = 7 to record list.
Process record: record_full_arch_list_add 0xabc3b868.
Process record: add register num = 25 to record list.
...
[ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ]
The problem is that the specific insn, an LDR(immediate) T4, is not handled in
thumb2_record_ld_word.
Fix this by detecting the insn in thumb2_record_ld_word, and recording the
updated base register.
Tom Tromey [Mon, 12 Feb 2024 21:25:03 +0000 (14:25 -0700)]
Introduce bfd_print_error function
gdb likes to control its own output; for example, this is important
for gdb's pager, and for logging. While BFD provides a way to
intercept error output, via bfd_set_error_handler, it turns out to be
difficult for this function to truly generate the desired output in a
gdb-friendly way -- the error handler is expected to implement some
BFD printf format extensions.
This patch introduces a new function that an error handler can use to
format the text. This way, gdb can set the error handler and arrange
for the output to be displayed as it likes.
* bfd.c (bfd_print_callback): Rename from print_func. Move into
comment.
(_bfd_doprnt): Update.
(bfd_print_error): New function.
(error_handler_fprintf, error_handler_sprintf): Use
bfd_print_error.
* bfd-in2.h: Rebuild.
Tom Tromey [Mon, 12 Feb 2024 21:25:03 +0000 (14:25 -0700)]
Do not call fputc from _bfd_doprnt
I noticed that _bfd_doprnt can unconditionally call fputc. However,
when called from error_handler_sprintf, this will likely result in a
crash, as the stream argument does not actually point to a FILE.
Tom de Vries [Mon, 12 Feb 2024 19:07:46 +0000 (20:07 +0100)]
[gdb/dap] Catch and log exceptions in dap threads
When running test-case gdb.dap/eof.exp, it occasionally coredumps.
The thread triggering the coredump is:
...
#0 0x0000ffff42bb2280 in __pthread_kill_implementation () from /lib64/libc.so.6
#1 0x0000ffff42b65800 [PAC] in raise () from /lib64/libc.so.6
#2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11)
at gdb/event-top.c:926
#3 0x00000000007b0470 in handle_sigsegv (sig=11)
at gdb/event-top.c:976
#4 <signal handler called>
#5 0x0000000000606080 in cli_ui_out::do_message (this=0xffff2f7ed728, style=...,
format=0xffff0c002af1 "%s", args=...) at gdb/cli-out.c:232
#6 0x0000000000ce6358 in ui_out::call_do_message (this=0xffff2f7ed728, style=...,
format=0xffff0c002af1 "%s") at gdb/ui-out.c:584
#7 0x0000000000ce6610 in ui_out::vmessage (this=0xffff2f7ed728, in_style=...,
format=0x16f93ea "", args=...) at gdb/ui-out.c:621
#8 0x0000000000ce3a9c in ui_file::vprintf (this=0xfffffbea1b18, ...)
at gdb/ui-file.c:74
#9 0x0000000000d2b148 in gdb_vprintf (stream=0xfffffbea1b18, format=0x16f93e8 "%s",
args=...) at gdb/utils.c:1898
#10 0x0000000000d2b23c in gdb_printf (stream=0xfffffbea1b18, format=0x16f93e8 "%s")
at gdb/utils.c:1913
#11 0x0000000000ab5208 in gdbpy_write (self=0x33fe35d0, args=0x342ec280, kw=0x345c08b0)
at gdb/python/python.c:1464
#12 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
#13 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
from /lib64/libpython3.12.so.1.0
#14 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#15 0x0000ffff434d8cd0 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
#16 0x0000ffff434b9824 [PAC] in PyObject_CallOneArg () from /lib64/libpython3.12.so.1.0
#17 0x0000ffff43557674 [PAC] in PyFile_WriteObject () from /lib64/libpython3.12.so.1.0
#18 0x0000ffff435577a0 [PAC] in PyFile_WriteString () from /lib64/libpython3.12.so.1.0
#19 0x0000ffff43465354 [PAC] in thread_excepthook () from /lib64/libpython3.12.so.1.0
#20 0x0000ffff434ac6e0 [PAC] in cfunction_vectorcall_O ()
from /lib64/libpython3.12.so.1.0
#21 0x0000ffff434a32d8 [PAC] in PyObject_Vectorcall () from /lib64/libpython3.12.so.1.0
#22 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#23 0x0000ffff434d8d88 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
#24 0x0000ffff435e0ef4 [PAC] in thread_run () from /lib64/libpython3.12.so.1.0
#25 0x0000ffff43591ec0 [PAC] in pythread_wrapper () from /lib64/libpython3.12.so.1.0
#26 0x0000ffff42bb0584 [PAC] in start_thread () from /lib64/libc.so.6
#27 0x0000ffff42c1fd4c [PAC] in thread_start () from /lib64/libc.so.6
...
The direct cause for the coredump seems to be that cli_ui_out::do_message
is trying to write to a stream variable which does not look sound:
...
(gdb) p *stream
$8 = {_vptr.ui_file = 0x0, m_applied_style = {m_foreground = {m_simple = true, {
m_value = 0, {m_red = 0 '\000', m_green = 0 '\000', m_blue = 0 '\000'}}},
m_background = {m_simple = 32, {m_value = 65535, {m_red = 255 '\377',
m_green = 255 '\377', m_blue = 0 '\000'}}},
m_intensity = (unknown: 0x438fe710), m_reverse = 255}}
...
The string that is being printed is:
...
(gdb) p str
$9 = "Exception in thread "
...
so AFAICT this is a DAP thread running into an exception and trying to print
it.
If we look at the state of gdb's main thread, we have:
...
#0 0x0000ffff42bac914 in __futex_abstimed_wait_cancelable64 () from /lib64/libc.so.6
#1 0x0000ffff42bafb44 [PAC] in pthread_cond_timedwait@@GLIBC_2.17 ()
from /lib64/libc.so.6
#2 0x0000ffff43466e9c [PAC] in take_gil () from /lib64/libpython3.12.so.1.0
#3 0x0000ffff43484fe0 [PAC] in PyEval_RestoreThread ()
from /lib64/libpython3.12.so.1.0
#4 0x0000000000ab8698 [PAC] in gdbpy_allow_threads::~gdbpy_allow_threads (
this=0xfffffbea1cf8, __in_chrg=<optimized out>)
at gdb/python/python-internal.h:769
#5 0x0000000000ab2fec in execute_gdb_command (self=0x33fe35d0, args=0x34297b60,
kw=0x34553d20) at gdb/python/python.c:681
#6 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
#7 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
from /lib64/libpython3.12.so.1.0
#8 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#9 0x0000ffff4353bce8 [PAC] in _PyObject_VectorcallTstate.lto_priv.3 ()
from /lib64/libpython3.12.so.1.0
#10 0x0000000000ab87fc [PAC] in gdbpy_event::operator() (this=0xffff14005900)
at gdb/python/python.c:1061
#11 0x0000000000ab93e8 in std::__invoke_impl<void, gdbpy_event&> (__f=...)
at /usr/include/c++/13/bits/invoke.h:61
#12 0x0000000000ab9204 in std::__invoke_r<void, gdbpy_event&> (__fn=...)
at /usr/include/c++/13/bits/invoke.h:111
#13 0x0000000000ab8e90 in std::_Function_handler<..>::_M_invoke(...) (...)
at /usr/include/c++/13/bits/std_function.h:290
#14 0x000000000062e0d0 in std::function<void ()>::operator()() const (
this=0xffff14005830) at /usr/include/c++/13/bits/std_function.h:591
#15 0x0000000000b67f14 in run_events (error=0, client_data=0x0)
at gdb/run-on-main-thread.c:76
#16 0x000000000157e290 in handle_file_event (file_ptr=0x33dae3a0, ready_mask=1)
at gdbsupport/event-loop.cc:573
#17 0x000000000157e760 in gdb_wait_for_event (block=1)
at gdbsupport/event-loop.cc:694
#18 0x000000000157d464 in gdb_do_one_event (mstimeout=-1)
at gdbsupport/event-loop.cc:264
#19 0x0000000000943a84 in start_event_loop () at gdb/main.c:401
#20 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465
#21 0x000000000094567c in captured_main (data=0xfffffbea23e8)
at gdb/main.c:1335
#22 0x0000000000945700 in gdb_main (args=0xfffffbea23e8)
at gdb/main.c:1354
#23 0x0000000000423ab4 in main (argc=14, argv=0xfffffbea2578)
at gdb/gdb.c:39
...
AFAIU, there's a race between the two threads on gdb_stderr:
- the DAP thread samples the gdb_stderr value, and uses it a bit later to
print to
- the gdb main thread changes the gdb_stderr value forth and back,
using a temporary value for string capture purposes
The non-sound stream value is caused by gdb_stderr being sampled while
pointing to a str_file object, and used once the str_file object is already
destroyed.
The error here is that the DAP thread attempts to print to gdb_stderr.
Fix this by adding a thread_wrapper that:
- catches all exceptions and logs them to dap.log, and
- while we're at it, logs when exiting
and using the thread_wrapper for each DAP thread.
Tom Tromey [Thu, 18 Jan 2024 14:35:48 +0000 (07:35 -0700)]
Fix DAP launch and configurationDone requests
Co-workers at AdaCore pointed out that gdb incorrectly implements the
DAP launch and configurationDone requests. It's somewhat strange to
me, but the spec does in fact say that configuration requests should
occur before the executable is known to gdb. This was clarified in
this bug report against the spec:
Fixing 'launch' to start the inferior was straightforward, but this
then required some changes to how breakpoints are handled. In
particular, now gdb will emit the "pending" reason on a breakpoint,
and will suppress breakpoint events during breakpoint setting.
Tom Tromey [Tue, 23 Jan 2024 17:25:33 +0000 (10:25 -0700)]
Clean up suppress_new_breakpoint_event
Kévin pointed out that suppress_new_breakpoint_event would do the
wrong thing if it happened to be used reentrantly. While I don't
think this can happen, it's also easy and clearly better to make it
robust.
Carl Love [Tue, 23 Jan 2024 22:12:34 +0000 (17:12 -0500)]
rs6000, unwind-on-each-instruction fix.
The function rs6000_epilogue_frame_cache assumes the LR and gprs have been
restored. In fact register r31 and the link register, lr, may not have
been restored yet. This patch adds support to store the lr and gpr
register unrolling rules in the cache. The LR and GPR values can now be
unrolled correctly.
Patch fixes all 10 regresion test failures for the unwind-on-each-insn.exp.
remote.c: Make packet_check_result return a structure
packet_check_result currently returns an packet_result enum.
If GDB will recieve an error in a format E.errtext, which
is possible for some q packets, such errtext is lost if
treated by packet_check_result.
Introduce a new structure which bundles enum packet_result
with possible error message or error code returned by
the GDBserver.
I plan to make more GDBserver response checking functions to use
packet_check_result to make remote.c code more consistent.
This will also allow to use E.errtext more in the future.
Beside adding the unit test, I tested this by modifying
store_registers_using_G function to get an error message:
Hannes Domani [Sun, 11 Feb 2024 16:40:59 +0000 (17:40 +0100)]
Fix crash when calling Frame.static_link
If you try to call Frame.static_link for a frame without debug info,
gdb crashes:
```
Temporary breakpoint 1, 0x000000013f821650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
The problem was a missing check if get_frame_block returns nullptr
inside frame_follow_static_link.
With this, it works:
```
Temporary breakpoint 1, 0x000000013f941650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
None
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366 Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Sat, 10 Feb 2024 17:50:24 +0000 (17:50 +0000)]
gdb/python: fix 'set python ignore-environment' white space
I noticed that the help text for set/show python ignore-environment
was messed up, some lines had unwanted leading white space, like this:
(gdb) help set python ignore-environment
Set whether the Python interpreter should ignore environment variables.
When enabled GDB's Python interpreter will ignore any Python related
flags in the environment. This is equivalent to passing `-E' to a
python executable.
(gdb)
This has been present since the ignore-environment setting was added
in commit:
Hannes Domani [Fri, 9 Feb 2024 19:25:29 +0000 (20:25 +0100)]
Allow value repeat operator on references
Currently it's not possible to use the value repeat operator on references:
```
print ((int &) v_int_array_init[0])@2
Only values in memory can be extended with '@'.
```
This seems like an unnecessary restriction, since it also prevents
its use on iterators (which was the original reported problem):
```
(gdb) p *it@2
Only values in memory can be extended with '@'.
```
So this converts any references to the referenced value in value_repeat,
making this possible:
```
print ((int &) v_int_array_init[0])@2
$1 = {10, 20}
(gdb) p *it@2
$2 = {1, 2}
```
Simon Marchi [Wed, 7 Feb 2024 16:53:20 +0000 (11:53 -0500)]
gdb: add inferior parameter to breakpoint_init_inferior
By inspection, I believe that breakpoint_init_inferior doesn't call
anything that relies on the current program space or inferior. So,
add an inferior parameter, to make the current inferior / program space
references bubble up one level.
Change-Id: Ib07b7a6d360e324f6ae1aa502dd314b8cce421b7 Approved-By: Andrew Burgess <aburgess@redhat.com>
Pedro Alves [Wed, 7 Feb 2024 18:48:16 +0000 (18:48 +0000)]
Fix crash in aarch64-linux gdbserver
Since commit 393a6b5947d0 ("Thread options & clone events (Linux
GDBserver)"), aarch64-linux gdbserver crashes when the inferior
vforks. This happens in aarch64_get_debug_reg_state:
Here, find_process_pid returns nullptr -- the new inferior hasn't yet
been created in linux_process_target::handle_extended_wait.
This patch fixes the problem by having
linux_process_target::handle_extended_wait create the child process
earlier, before the child LWP is created. This is what the function
did before it was reorganized by the commit referred above.
Change-Id: Ib8b3a2e6048c3ad2b91a92ea4430da507db03c50 Co-Authored-By: Tom Tromey <tromey@adacore.com>
Jan Beulich [Fri, 9 Feb 2024 07:39:48 +0000 (08:39 +0100)]
x86/APX: with REX2 map 1 doesn't "chain" to maps 2 or 3
Don't wander into three_byte_table[] when REX2 is present.
While there also eliminate related confusion when accessing
dis386_twobyte[]: There's nothing 3-byte-ish involved there. Dropping
the odd variable gets things better in sync with 1-byte handling as
well.
Jan Beulich [Fri, 9 Feb 2024 07:39:20 +0000 (08:39 +0100)]
x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed
Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128 they weren't
even present in the x86-64-apx-egpr-inval testcase, hence why I
overlooked that these can actually be encoded, (again) using suitable
AVX512 counterparts.
While there also "modernize" the adjacent AVX/AVX2 entries.
Jan Beulich [Fri, 9 Feb 2024 07:38:04 +0000 (08:38 +0100)]
x86: change type of Dwarf2 register numbers in register table
Already the %bnd<N> registers used numbers beyond 127, and eGPR ones are
all out of reach for "signed char", at least when CHAR_BITS=8. Switch to
"unsigned char", covering appropriately in places where the value
returned for "none" actually matters (in tc_x86_parse_to_dw2regnum()
this is actually achieved by altering how X_op is set).
Indu Bhagat [Fri, 9 Feb 2024 07:10:27 +0000 (23:10 -0800)]
gas: scfi: fix failing test on Solaris2
It has been observed that the run of scfi-unsupported-1 test with --x32
arg on a Solaris2 x86_64 system fails:
Executing on host: sh -c {../as-new --x32 --scfi=experimental \
<...>/scfi-unsupported-1.s 2>&1} /dev/null dump.out (timeout = 300)
Assembler messages:
Fatal error: no compiled in support for 32bit x86_64
regexp_diff match failure
regexp "^Fatal error: SCFI is not supported for this ABI$"
line "Fatal error: no compiled in support for 32bit x86_64"
FAIL: x86_64 scfi-unsupported-1
Fix the above by adding a check for --x32 support before running the
test. While at it, also include a similar check for --32 support.
gas/testsuite/
* gas/scfi/x86_64/scfi-x86-64.exp: Add gas_x32_check and
gas_32_check. Conditionalize the execution of affected
testcases.
Alan Modra [Fri, 9 Feb 2024 01:43:13 +0000 (12:13 +1030)]
PR 14962 testcase xcoff failure
Like https://sourceware.org/pipermail/binutils/2002-August/021279.html
but for symbols defined in an xcoff object but then made absolute by a
linker script.
* xcofflink.c (xcoff_link_input_bfd): Set n_scnum correctly
for symbols made absolute by a linker script.
gdb.base/default.exp has an incomplete test for the "info copying" command,
as poetically pointed out by the FIXME removed by this patch.
The test omits the pattern argument to gdb_test, which causes it to just
check for a GDB prompt at the end of the command output.
The problem is that the command output is the whole GPLv3 license, which
due to its size causes the test to fail sometimes, making the testcase to
be out of sync with GDB's output and failing the tests that follow
it. E.g.,
FAIL: gdb.base/default.exp: info copying (timeout)
FAIL: gdb.base/default.exp: info display
FAIL: gdb.base/default.exp: info frame "f" abbreviation
PASS: gdb.base/default.exp: info frame
FAIL: gdb.base/default.exp: info files
FAIL: gdb.base/default.exp: info float
FAIL: gdb.base/default.exp: info functions
FAIL: gdb.base/default.exp: info locals
FAIL: gdb.base/default.exp: info program
FAIL: gdb.base/default.exp: info registers
FAIL: gdb.base/default.exp: info stack "s" abbreviation
Fix by by checking for a few excerpts at the beginning, middle and end of
the license text. This makes the test consume the command's output in
smallish chunks.
Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Thu, 8 Feb 2024 20:34:22 +0000 (07:04 +1030)]
PR31208, strip can break ELF alignment requirements
In https://sourceware.org/pipermail/binutils/2007-August/053261.html
(git commit 3dea8fca8b86) I disabled a then new linker feature that
removed empty PT_LOAD headers in cases where a user specified program
headers, and for objcopy. This can be a problem for objcopy/strip and
since objcopy operates on sections, any part of a PT_LOAD loading file
contents not covered by a section will be omitted anyway.
PR 31208
* elf.c (_bfd_elf_map_sections_to_segments): Pass remove_empty_load
as true to elf_modify_segment_map for objcopy/strip.
Tom Tromey [Sun, 17 Dec 2023 19:38:15 +0000 (12:38 -0700)]
Update TUI register window when the inferior exits
When the inferior exits, the TUI register window should clear.
Fixing this was mostly a matter of sticking an assignment into
tui_inferior_exit. However, some changes to the register window
itself were also needed.
While working on this, I realized that the TUI register window would
not work correctly when moving between frames of different
architectures. This patch attempts to fix this as well, though I have
no way to test it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600 Tested-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sun, 17 Dec 2023 19:15:00 +0000 (12:15 -0700)]
Remove redundant check from tui_refresh_frame_and_register_information
tui_refresh_frame_and_register_information checks 'from_stack' in a
block that's already guarded by a 'from_stack' check. This patch
removes the redundant check.
Tested-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sun, 17 Dec 2023 17:28:30 +0000 (10:28 -0700)]
Remove the TUI register window rerender overload
After these restructurings, it should be clear that the rerender
overload can be removed from the TUI register window. This is done by
moving a bit more logic from show_registers into update_register_data.
After this, update_register_data simply updates the internal state,
and rerender will write to the screen. All the actual rendering work
is done, ultimately, by display_registers_from. This split between
updating the model and rendering makes it clear that the recursive
case can't happen any longer.
Tested-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sun, 17 Dec 2023 02:57:57 +0000 (19:57 -0700)]
Simplify update_register_data
This changes update_register_data to always update the register data.
The idea here is that this is really only called when either the
desired register group changes, or when gdb transitions from not
having a frame to having a frame.
show_registers is also simplified slightly to account for this.
Tested-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sun, 17 Dec 2023 16:31:05 +0000 (09:31 -0700)]
Move scrollok call in register window
The register window calls scrollok each time a register is written to
the window. However, we only need to call this once, at the start of
display. (We could actually call it just once when the window is
made, but that would involve making another method virtual or adding a
new member -- both which I think are worse than this approach.)
Tested-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sun, 17 Dec 2023 16:28:06 +0000 (09:28 -0700)]
Change tui_register_info::visible to a method
tui_register_info::visible is redundant with the fact that y==0 means
that the register is not visible. This patch changes this member in
favor of having a single indication of the register's visibility -- a
method with the same name. This change makes it clear that
delete_data_content_windows is not needed, so this is removed as well.
Tom Tromey [Sun, 17 Dec 2023 02:42:37 +0000 (19:42 -0700)]
Rename tui_data_item_window -> tui_register_info
tui_data_item_window used to hold a curses window, but we removed that
ages ago. Now it just holds information about a single register.
This patch renames the class to make it more clearly reflect its
meaning.
Tested-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Sun, 17 Dec 2023 02:41:54 +0000 (19:41 -0700)]
Simplify tui_data_window::show_register_group
This simplifies tui_data_window::show_register_group, renaming it as
well. The old method had two loops to iterate over all the registers
for the arch, but in the new scheme, the vector is set up when
switching groups, and then updates simply iterate over the vector.
tui_data_item_window is made self-updating, which also clarifies the
code somewhat.
Tested-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Hannes Domani [Thu, 8 Feb 2024 19:09:25 +0000 (20:09 +0100)]
Allow calling of C++ methods from python
Currently it's not possible to call C++ methods from python.
Using this example:
```
class B
{
static int static_func ();
int arg0_func ();
int arg1_func (int arg1);
int arg2_func (int arg1, int arg2);
};
B *b_obj = new B;
```
Trying to call B::static_func gives this error:
```
(gdb) py b_obj = gdb.parse_and_eval('b_obj')
(gdb) py print(b_obj['static_func']())
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Value is not callable (not TYPE_CODE_FUNC).
Error while executing Python code.
```
TYPE_CODE_METHOD was simply missing as a possible type in
valpy_call, now the same is possible:
```
(gdb) py b_obj = gdb.parse_and_eval('b_obj')
(gdb) py print(b_obj['static_func']())
1111
```
Note that it's necessary to explicitely add the this pointer
as the first argument in a call of non-static methods:
```
(gdb) py print(b_obj['arg0_func']())
Traceback (most recent call last):
File "<string>", line 1, in <module>
gdb.error: Too few arguments in function call.
Error while executing Python code.
(gdb) py print(b_obj['arg0_func'](b_obj))
198
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 Approved-By: Tom Tromey <tom@tromey.com>
Jens Remus [Mon, 5 Feb 2024 16:50:05 +0000 (17:50 +0100)]
gdb: Fix building with clang
This resolves the following clang++ error message:
../../gdb/symtab.c:4892:33: error: logical not is only applied to the left hand side of this comparison [-Werror,-Wlogical-not-parentheses]
if (preg.has_value () && !preg->exec (sym->natural_name (), 0,
^
../../gdb/symtab.c:4892:33: note: add parentheses after the '!' to evaluate the comparison first
if (preg.has_value () && !preg->exec (sym->natural_name (), 0,
^
(
../../gdb/symtab.c:4892:33: note: add parentheses around left hand side expression to silence this warning
if (preg.has_value () && !preg->exec (sym->natural_name (), 0,
^
(
H.J. Lu [Sat, 3 Feb 2024 22:32:17 +0000 (14:32 -0800)]
x86-64: Add R_X86_64_CODE_6_GOTTPOFF
For
add %reg1, name@gottpoff(%rip), %reg2
and
add name@gottpoff(%rip), %reg1, %reg2
add
#define R_X86_64_CODE_6_GOTTPOFF 50
if the instruction starts at 6 bytes before the relocation offset.
They are similar to R_X86_64_GOTTPOFF. Linker can covert GOTTPOFF to
add $name@tpoff, %reg1, %reg2
Rewrite fx_tcbit, fx_tcbit2 and fx_tcbit3 usage to generate
R_X86_64_GOTPCRELX, R_X86_64_REX_GOTPCRELX, R_X86_64_CODE_4_GOTPCRELX,
R_X86_64_CODE_4_GOTTPOFF, R_X86_64_CODE_4_GOTPC32_TLSDESC and
R_X86_64_CODE_6_GOTTPOFF.
NB: There is no need to check BFD_RELOC_X86_64_CODE_4_GOTTPOFF in
md_assemble since there is only BFD_RELOC_X86_64_GOTTPOFF at this
stage, which will be converted to BFD_RELOC_X86_64_CODE_4_GOTTPOFF
or BFD_RELOC_X86_64_CODE_6_GOTTPOFF in i386_validate_fix.
PR 31283 windmc: Parse input correctly on big endian hosts
On big endian hosts (eg. s390x) the windmc tool fails to parse even
trivial files:
$ cat test.mc
;
$ ./binutils/windmc ./test.mc
In test.mc at line 1: parser: syntax error.
In test.mc at line 1: fatal: syntax error.
The tool starts by reading the input as Windows CP1252 and then
converting it internally into an array of UTF-16LE, which it then
processes as an array of unsigned short (typedef unichar).
There are lots of ways this is wrong, but in the specific case of big
endian machines the little endian pairs of bytes are byte-swapped.
For example, the ';' character in the input above is first converted
to UTF16-LE byte sequence { 0x3b, 0x00 }, which is then cast to
unsigned short. On a big endian machine the first unichar appears to
be 0x3b00. The lexer is unable to recognize this as the comment
character ((unichar)';') and so parsing fails.
The simple fix is to convert the input to UTF-16BE on big endian
machines (and do the reverse conversion when writing the output).
Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31283 Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Hannes Domani [Wed, 7 Feb 2024 18:59:29 +0000 (19:59 +0100)]
Raise exception if ambiguous name is used in gdb.parameter
Currently gdb.parameter doesn't raise an exception if an
ambiguous name is used, it instead returns the value of the
last partly matching parameter:
```
(gdb) show print sym
Ambiguous show print command "sym": symbol, symbol-filename, symbol-loading.
(gdb) show print symbol-loading
Printing of symbol loading messages is "full".
(gdb) py print(gdb.parameter("print sym"))
full
```
It's because lookup_cmd_composition_1 tries to detect
ambigous names by checking the return value of find_cmd
for CMD_LIST_AMBIGUOUS, which never happens, since only
lookup_cmd_1 returns CMD_LIST_AMBIGUOUS.
Instead the nfound argument contains the number of found
matches.
By using it instead, and by setting *CMD to the special value
CMD_LIST_AMBIGUOUS in this case, gdbpy_parameter can now show
the appropriate error message:
```
(gdb) py print(gdb.parameter("print sym"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Parameter `print sym' is ambiguous.
Error while executing Python code.
(gdb) py print(gdb.parameter("print symbol"))
True
(gdb) py print(gdb.parameter("print symbol-"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Parameter `print symbol-' is ambiguous.
Error while executing Python code.
(gdb) py print(gdb.parameter("print symbol-load"))
full
```
Since the document command also uses lookup_cmd_composition, it needed
to check for CMD_LIST_AMBIGUOUS as well, so it now also shows an
"Ambiguous command" error message in this case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14639 Approved-By: Tom Tromey <tom@tromey.com>
Hannes Domani [Wed, 7 Feb 2024 18:51:26 +0000 (19:51 +0100)]
Fix raw-frame-arguments in combination with frame-filters
Currently, if frame-filters are active, raw-values is used instead of
raw-frame-arguments to decide if a pretty-printer should be invoked for
frame arguments in a backtrace.
In this example, "super struct" is the output of the pretty-printer:
(gdb) disable frame-filter global BasicFrameFilter
(gdb) bt
#0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
If no frame-filter is active, then the raw-values print option does not
affect the backtrace output:
(gdb) set print raw-values on
(gdb) bt
#0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
(gdb) set print raw-values off
Instead, the raw-frame-arguments option disables the pretty-printer in the
backtrace:
(gdb) bt -raw-frame-arguments on
#0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
But if a frame-filter is active, the same rules don't apply.
The option raw-frame-arguments is ignored, but raw-values decides if the
pretty-printer is used:
(gdb) enable frame-filter global BasicFrameFilter
(gdb) bt
#0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
(gdb) set print raw-values on
(gdb) bt
#0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
(gdb) set print raw-values off
(gdb) bt -raw-frame-arguments on
#0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
So this adds the PRINT_RAW_FRAME_ARGUMENTS flag to frame_filter_flag, which
is then used in the frame-filter to override the raw flag in enumerate_args.
Then the output is the same if a frame-filter is active, the pretty-printer
for backtraces is only disabled with the raw-frame-arguments option:
(gdb) enable frame-filter global BasicFrameFilter
(gdb) bt
#0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
(gdb) set print raw-values on
(gdb) bt
#0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
(gdb) set print raw-values off
(gdb) bt -raw-frame-arguments on
#0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47
#1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Ciaran Woodward [Tue, 6 Feb 2024 17:56:07 +0000 (17:56 +0000)]
Remove use of scoped_restore_tmpl from scoped_restore_warning_hook
The warning_hook_handler function pointer takes va_list as
an argument, which on some platforms (mingw64) includes some
attributes. Attributes get ignored in template arguments.
This led to the compiler warning:
Alan Modra [Wed, 7 Feb 2024 01:59:12 +0000 (12:29 +1030)]
asan: NULL dereference in _bfd_mips_final_write_processing
Fuzzed object files can easily have unexpected section names. We
don't want to segfault on objcopy of any file accepted by the mips
object_p functions. For objcopy, an assertion that "sec" is non-NULL
followed by deferencing "sec" is wrong. So too is asserting that the
section name string starts with a particular prefix, and then blithely
accessing past the assumed prefix.
* elfxx-mips.c (_bfd_mips_final_write_processing): Replace
assertions with conditionals. Don't bother testing for name
non-NULL.
Indu Bhagat [Wed, 7 Feb 2024 00:20:53 +0000 (16:20 -0800)]
gas: x86: ginsn: handle sub-QWORD ALU with imm and MOV ops correctly
PR gas/31326
SCFI must handle non QWORD ALU with imm and MOV ops correctly
As per the x86 ISA manual:
- 32-bit operands generate a 32-bit result, zero-extended to a 64-bit
result in the destination general-purpose register.
- 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The
upper 56 bits or 48 bits (respectively) of the destination
general-purpose register are not modified by the operation.
Unlike previously thought, sub-QWORD ALU/imm and MOV ops do have
implications on SCFI. SCFI/ginsn machinery does not track operation size
in the ginsn representation. But given that these sub-QWORD ops update
only a portion of a 64-bit destination register, for SCFI purposes, this
needs to be deemed as an untraceable update (when the destination is
REG_SP / REG_FP). Although in most cases, sub-QWORD ops are not expected
for stack management, but the SCFI machinery must behave correctly, when
such ops are indeed present.
As mentioned earlier, ginsn representation does not carry operation size
information. To resolve the issue raised in PR gas/31326, an option is
to force the generation of GINSN_TYPE_OTHER for all cases when there is
a 8/16/32 bit op. But this may dilute the utility of ginsn for other
use-cases, when they pop up in future.
The current approach is less disruptive than above in that it generates
GINSN_TYPE_OTHER for all cases only when:
- there is a 8/16/32 bit op, and
- the 64-bit op is otherwise traceable.
In other words this means:
- For add/sub ops where dest is reg and src is reg/mem: these always
make dest reg untraceable; So, the current handling is unchanged. We
simply skip detecting 8/16/32-bit ops.
- An x86 pop instruction is translated to a load ginsn followed by a stack
increment add op. A load op always makes dest reg untraceable.
Hence, if the pop instruction is sub-QWORD, we continue to (skip
detecting 8/16/32-bit op, and) generate the load instruction as usual.
This means that if input asm does have save and restore of unequal sized
registers, gas/SCFI will not detect nor warn.
- For ALU imm or MOV reg,reg, however, a GINSN_TYPE_OTHER is generated
when a 8/16/32-bit op is seen.
gas/
PR gas/31326
* config/tc-i386.c (x86_ginsn_addsub_reg_mem): Add a code
comment.
(x86_ginsn_addsub_mem_reg): Likewise.
(x86_ginsn_alu_imm): Detect sub-QWORD opsize and exit early.
(x86_ginsn_move): Likewise.
(x86_ginsn_new): Add comment for 8-bit add/sub opcodes (in
opcode_space SPACE_BASE) about skipped handling.
gas/testsuite/:
PR gas/31326
* gas/scfi/x86_64/ginsn-add-1.l: Update.
* gas/scfi/x86_64/ginsn-add-1.s: Add some sub-QWORD add ops.
* gas/scfi/x86_64/ginsn-dw2-regnum-1.l: Update.
* gas/scfi/x86_64/ginsn-dw2-regnum-1.s: Use mov ops instead of
add to invoke and test the ginsn_dw2_regnum code path.
Simon Marchi [Mon, 5 Feb 2024 21:13:58 +0000 (16:13 -0500)]
gdb: remove core_bfd macro
The core_bfd macro hides a use of current_program_space. Remove it, so
that we have the opportunity to get the program space from the context,
if possible. I guess that the macro was introduced at some point to
replace a global variable of the same name without changing all the
uses.
Change-Id: I971a65b29b5e5a5941f3cb7ea234547daa787268 Approved-By: Tom Tromey <tom@tromey.com>
H.J. Lu [Mon, 5 Feb 2024 19:58:08 +0000 (11:58 -0800)]
x86: Warn .insn instruction with length > 15 bytes
Change .insn instruction with length > 15 bytes from error to warning.
PR gas/31323
* config/tc-i386.c (output_insn): Issue a warning when .insn
instruction length exceeds the limit of 15 bytes.
* testsuite/gas/i386/oversized64.s: Add a test for .insn
* testsuite/gas/i386/oversized64.l: Updated.
Tiezhu Yang [Wed, 31 Jan 2024 08:10:30 +0000 (16:10 +0800)]
gdb: LoongArch: Implement the get_syscall_number gdbarch method
In the current code, the feature 'catch syscall' is not supported
on LoongArch, implement the "get_syscall_number" gdbarch method to
get the system call number from the register a7.
Without this patch:
(gdb) catch syscall
The feature 'catch syscall' is not supported on this architecture yet.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Feiyang Chen [Thu, 25 Jan 2024 08:32:36 +0000 (16:32 +0800)]
gdb: LoongArch: Add LBT extension support
Loongson Binary Translation (LBT) is used to accelerate binary
translation, which contains 4 scratch registers (scr0 to scr3),
x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This
patch support gdb to fetch/store these registers.
Hui Li [Thu, 25 Jan 2024 08:32:35 +0000 (16:32 +0800)]
gdb: LoongArch: Add vector extensions support
Add LoongArch's vector extensions support, which including
128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX
(i.e., Loongson Advanced SIMD eXtension). This patch support
gdb to fetch/store vector registers.
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Simon Marchi [Mon, 5 Feb 2024 20:18:34 +0000 (15:18 -0500)]
gdb: rename target_so_ops to solib_ops
I don't like the name `target_so_ops`, because:
- The name `target` is so overloaded, and in this case it's not even
related to target_ops or anything else called "target".
- We do have an implementation that actually fetches solibs from the
target (solib_target_so_op in solib-target.c), so it's confusing for
the "base class" to be called target_something as well.
Rename to solib_ops.
Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 5 Feb 2024 20:18:33 +0000 (15:18 -0500)]
gdb: rename struct shobj -> struct solib
`struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f
("gdb: rename struct so_list to shobj")). In hindsight, `solib` would
have been a better name. We have solib.c, the implementations in
solib-*.c, many functions with solib in their name, the solib_loaded /
solib_unloaded observables, etc.
Rename shobj to solib.
Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 2 Feb 2024 01:53:47 +0000 (18:53 -0700)]
Remove remnants of partial DIEs from DWARF reader
When rewriting the DWARF scanner, I forgot to remove
dwarf2_cu::load_all_dies and dwarf2_cu::partial_dies. This patch
corrects the oversight and fixes up a couple other spots that mention
partial DIEs, which no longer exist.
Fix disabling of year 2038 support on 32-bit hosts by default
Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by
default") fixed a mismatch between 64-bit time_t in GDB and system headers
and 32-bit time_t in BFD.
However, since commit 862776f26a59 ("Finalized intl-update patches")
gnulib's year 2038 support has been accidentally re-enabled — causing
problems for 32-bit hosts again. The commit split baseargs into
{h,b}baseargs, but this hasn't been done for the code that handles
--disable-year2038.
This patch restores the intended behaviour. With this change, the number
of unexpected core files goes from 18 to 4.
Tom Tromey [Thu, 21 Dec 2023 15:24:18 +0000 (08:24 -0700)]
Handling of arrays with optimized-out bounds
In Ada, sometimes the compiler must emit array bounds by referencing
an artificial variable that's created for this purpose. However, with
optimization enabled, these variables can be optimized away.
Currently this can result in displays like:
(gdb) print mumble
$1 = (warning: unable to get bounds of array, assuming null array
)
This patch changes this to report that the array is optimized-out,
instead, which is closer to the truth, and more generally useful. For
example, Python pretty-printers can now recognize this situation.
In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT
enumerator and changed one place to use it. Reusing the "unknown"
state wouldn't work properly, because in C it is normal for array
bounds to be unknown.
Tom de Vries [Mon, 5 Feb 2024 10:04:06 +0000 (11:04 +0100)]
[gdb/tdep] Fix use-after-free in arm_exidx_fill_cache
On arm-linux the linaro CI occasionally reports:
...
(gdb) up 10
#4 0x0001b864 in pthread_join ()
(gdb) FAIL: gdb.threads/staticthreads.exp: up 10
...
while this is expected:
...
(gdb) up 10
#3 0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
76 pthread_join (thread, NULL);
(gdb) PASS: gdb.threads/staticthreads.exp: up 10
...
Thiago investigated the problem, and using valgrind found an invalid read in
arm_exidx_fill_cache.
The problem happens as follows:
- an objfile and corresponding per_bfd are allocated
- some memory is allocated in arm_exidx_new_objfile using
objfile->objfile_obstack, for the "exception table entry cache".
- a symbol reread is triggered, and the objfile, including the
objfile_obstack, is destroyed
- a new objfile is allocated, using the same per_bfd
- again arm_exidx_new_objfile is called, but since the same per_bfd is used,
it doesn't allocate any new memory for the "exception table entry cache".
- the "exception table entry cache" is accessed by arm_exidx_fill_cache,
and we have a use-after-free.
This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling
information per-bfd instead of per-objfile"), which changed the "exception
table entry cache" from per-objfile to per-bfd, but failed to update the
obstack_alloc.
Fix this by using objfile->per_bfd->storage_obstack instead of
objfile->objfile_obstack.
I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
fixes it.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31254
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254
Tom Tromey [Sat, 3 Feb 2024 21:32:06 +0000 (14:32 -0700)]
Use reference result of emplace_back
Starting with C++17, emplace_back returns a reference to the new
object. This patch changes code that uses emplace_back followed by a
call to back() to simply use this reference instead.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Xi Ruoyao [Fri, 2 Feb 2024 13:00:58 +0000 (21:00 +0800)]
LoongArch: gas: Fix the types of symbols referred with %le_*_r in the symtab
When a symbol is referred with %le_{hi20,lo12,add}_r, it's definitely a
TLS symbol and we should set its type to TLS in the symtab. Otherwise
when building Perl with gcc-14 -flto, we get:
/usr/bin/ld: PL_current_context: TLS definition in
./miniperl.ltrans0.ltrans.o section .tbss mismatches non-TLS reference
in ./miniperl.ltrans1.ltrans.o
Unfortunately this was undetected before Binutils-2.42 release because
GCC < 14 does not use %le_*_r, and without LTO it's very rare to have a
TLS LE definition and its reference in two different translation units.
So this fix should be backported to Binutils-2.42 branch too.
Andrew Burgess [Tue, 23 Jan 2024 16:00:59 +0000 (16:00 +0000)]
gdb: attach to a process when the executable has been deleted
Bug PR gdb/28313 describes attaching to a process when the executable
has been deleted. The bug is for S390 and describes how a user sees a
message 'PC not saved'.
On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but
instead I see this:
(gdb) attach 901877
Attaching to process 901877
No executable file now.
warning: Could not load vsyscall page because no executable was specified
0x00007fa9d9c121e7 in ?? ()
(gdb) bt
#0 0x00007fa9d9c121e7 in ?? ()
#1 0x00007fa9d9c1211e in ?? ()
#2 0x0000000000000007 in ?? ()
#3 0x000000002dc8b18d in ?? ()
#4 0x0000000000000000 in ?? ()
(gdb)
Notice that the addresses in the backtrace don't seem right, quickly
heading to 0x7 and finally ending at 0x0.
What's going on, in both the s390 case and the x86-64 case is that the
architecture's prologue scanner is going wrong and causing the stack
unwinding to fail.
The prologue scanner goes wrong because GDB has no unwind information.
And GDB has no unwind information because, of course, the executable
has been deleted.
Notice in the example session above we get this line in the output:
No executable file now.
which indicates that GDB failed to find an executable to debug.
For GNU/Linux when GDB tries to find an executable for a given pid we
end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c.
Within this function we call `readlink` on /proc/PID/exe to find the
path of the actual executable.
If the `readlink` call fails then we already fallback on using
/proc/PID/exe as the path to the executable to debug.
However, when the executable has been deleted the `readlink` call
doesn't fail, but the path that is returned points to a non-existent
file.
I propose that we add an `access` call to linux_proc_pid_to_exec_file
to check that the target file exists and can be read. If the target
can't be read then we should fall back to /proc/PID/exe (assuming that
/proc/PID/exe can be read).
Now on x86-64 the output looks like this:
(gdb) attach 901877
Attaching to process 901877
Reading symbols from /proc/901877/exe...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
(gdb) bt
#0 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
#1 0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6
#2 0x000000000040117e in spin_forever () at attach-test.c:17
#3 0x0000000000401198 in main () at attach-test.c:24
(gdb)
which is much better.
I've also tagged the bug PR gdb/29782 which concerns the test
gdb.server/connect-with-no-symbol-file.exp. After making this change,
when running gdb.server/connect-with-no-symbol-file.exp GDB would now
pick up the /proc/PID/exe file as the executable in some cases.
As GDB is not restarted for the multiple iterations of this test
GDB (or rather BFD) would given a warning/error like:
(gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: disconnect
set sysroot target:
BFD: reopening /proc/3283001/exe: No such file or directory
(gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: adjust sysroot
What's happening is that an executable found for an earlier iteration
of the test is still registered for the inferior when we are setting
up for a second iteration of the test. When the sysroot changes, if
there's an executable registered GDB tries to reopen it, but in this
case the file has disappeared (the previous inferior has exited by
this point).
I did think about maybe, when the executable is /proc/PID/exe, we
should auto-delete the file from the inferior. But in the end I
thought this was a bad idea. Not only would this require a lot of
special code in GDB just to support this edge case: we'd need to track
if the exe file name came from /proc and should be auto-deleted, or
we'd need target specific code to check if a path should be
auto-deleted.....
... in addition, we'd still want to warn the user when we auto-deleted
the file from the inferior, otherwise they might be surprised to find
their inferior suddenly has no executable attached, so we wouldn't
actually reduce the number of warnings the user sees.
So in the end I figured that the best solution is to just update the
test to avoid the warning. This is easily done by manually removing
the executable from the inferior once each iteration of the test has
completed.
Now, in bug PR gdb/29782 GDB is clearly managing to pick up an
executable from the NFS cache somehow. I guess what's happening is
that when the original file is deleted /proc/PID/exe is actually
pointing to a file in the NFS cache which is only deleted at some
later point, and so when GDB starts up we do manage to associate a
file with the inferior, this results in the same message being emitted
from BFD as I was seeing. The fix included in this commit should also
fix that bug.
One final note: On x86-64 GNU/Linux, the
gdb.server/connect-with-no-symbol-file.exp test will produce 2 core
files. This is due to a bug in gdbserver that is nothing to do with
this test. These core files are created before and after this
commit. I am working on a fix for the gdbserver issue, but will post
that separately.
Instructions with length > 15 bytes are always invalid. It is quite easy
to generate invalid instructions with AVX now. We should issue an error
when instruction length exceeds the limit of 15 bytes.
PR gas/31323
* config/tc-i386.c (output_insn): Issue an error when instruction
length exceeds the limit of 15 bytes.
* testsuite/gas/i386/oversized16.l: Updated.
* testsuite/gas/i386/oversized64.l: Likewise.
* testsuite/gas/i386/x86-64-apx-inval.l: New file.
* testsuite/gas/i386/x86-64-apx-inval.s: Likewise.
The 'pointer property' in Fortran is implicitly modeled by adding a
DW_AT_associated to the type of the variable (see also the
DW_AT_associated description in DWARF 5). A Fortran pointer is more
than an address and thus different from a C pointer. It is a
self contained type having additional fields such as, e.g., the rank of
its underlying array. This motivates the intended DWARF modeling of
Fortran pointers via the DW_AT_associated attribute.
This patch adds support for the sizeof intrinsic by simply dereferencing
pointer types when encountered during a sizeof evaluation.
The patch also adds a test for the sizeof intrinsic which was not tested
before.
Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Tom Tromey <tom@tromey.com>
Bernhard Heckel [Thu, 13 Oct 2022 13:17:23 +0000 (15:17 +0200)]
gdb, types: Resolve pointer types dynamically
This commit allows pointers to be dynamic types (on the outmost
level). Similar to references, a pointer is considered a dynamic type
if its target type is a dynamic type and it is on the outmost level.
Also this commit removes the redundant code inside function
"value_check_printable" for handling of DW_AT_associated type.
The pointer resolution follows the one of references.
This change generally makes the GDB output more verbose. We are able to
print more details about a pointer's target like the dimension of an array.
In Fortran, if we have a pointer to a dynamic type
type buffer
real, dimension(:), pointer :: ptr
end type buffer
type(buffer), pointer :: buffer_ptr
allocate (buffer_ptr)
allocate (buffer_ptr%ptr (5))
which then gets allocated, we now resolve the dynamic type before
printing the pointer's type:
Before:
(gdb) ptype buffer_ptr
type = PTR TO -> ( Type buffer
real(kind=4) :: alpha(:)
End Type buffer )
After:
(gdb) ptype buffer_ptr
type = PTR TO -> ( Type buffer
real(kind=4) :: alpha(5)
End Type buffer )
Similarly in C++ we can dynamically resolve e.g. pointers to arrays:
int len = 3;
int arr[len];
int (*ptr)[len];
int ptr = &arr;
Once the pointer is assigned one gets:
Before:
(gdb) p ptr
$1 = (int (*)[variable length]) 0x123456
(gdb) ptype ptr
type = int (*)[variable length]
After:
(gdb) p ptr
$1 = (int (*)[3]) 0x123456
(gdb) ptype ptr
type = int (*)[3]
For more examples see the modified/added test cases.
Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Tom Tromey <tom@tromey.com>
Ijaz, Abdul B [Wed, 3 Jan 2024 17:01:57 +0000 (18:01 +0100)]
gdb/testsuite: Fix indentation issues in gdb.dwarf2/dynarr-ptr.exp
Improve indentation in the test file by replacing 10 spaces at second level
with 4 spaces. This helps to update the test using the right indentation
in future.
Jan Beulich [Fri, 2 Feb 2024 07:27:16 +0000 (08:27 +0100)]
x86: move Q-suffix-to-REX.W translation logic
By pulling it ahead of the SHORT_MNEM_SUFFIX case label we can drop a
part of another conditional there. While moving, also drop a pointless
check: With QWORD_MNEM_SUFFIX, register operands of XCHG necessarily
have both been 64-bit ones.
Jan Beulich [Fri, 2 Feb 2024 07:26:22 +0000 (08:26 +0100)]
x86: actually implement .noopt
For quite some time we've had support for -O command line options. With
that ignoring at least .noopt isn't really a good idea.
Re-purpose the optimize-3 test for testing this directive's effect as
well.
As to the doc addition - this uses the same text as is there for the
{nooptimize} pseudo-prefix, despite me not being convinced of the "size"
part being fully accurate there (and hence also here).
Indu Bhagat [Thu, 1 Feb 2024 22:48:18 +0000 (14:48 -0800)]
gas: x86: ginsn: adjust ginsns for certain lea ops
A review comment on the SCFI V4 series was to handle ginsn creation for
certain lea opcodes more precisely.
Specifically, we should preferably handle the following two cases of lea
opcodes similarly:
- #1 lea with "index register and scale factor of 1, but no base
register",
- #2 lea with "no index register, but base register present".
Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the
case of #1 above. For #2, however, the lea insn is translated to either
a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate
for displacement is non-zero or not respectively.
Change the handling in x86_ginsn_lea so that both of the above lea
manifestations are handled similarly.
While at it, remove the code paths creating GINSN_TYPE_OTHER altogether
from the function. It makes sense to piggy back on the
x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the
destination register is interesting. This was also suggested in one of
the previous review rounds; the other functions already follow that
model, so this keeps functions symmetrical looking.
gas/
* gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with
no base register similar to the case of no index register. Remove
creation of GINSN_TYPE_OTHER from the function.
gas/testsuite/
* gas/scfi/x86_64/ginsn-lea-1.l: New test.
* gas/scfi/x86_64/ginsn-lea-1.s: Likewise.
* gas/scfi/x86_64/scfi-x86-64.exp: Add new test.
A recent commit broke AIX build. The thread_local type defined functions
were being considered a weak symbol and hence while creating the binary these
symbols were not visible.
projects / thirdparty / binutils-gdb.git / log
