| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This distinction is important for architecures like Xtensa,
where 2B and 3B instructions are common, but the correct
value for instruction iteration is 1B, not 2B.
Signed-off-by: Richard Allen <rsaxvc@gmail.com>
|
|
Signed-off-by: Richard Allen <rsaxvc@gmail.com>
|
|
|
|
I noticed we quite often use:
bfd_get_filename (per_bfd->obfd)
Add a shortcut for that.
Change-Id: I4e33925a481fd44088386510b01936d38e1d7d38
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This matches the exclusion added to the GCC .gitignore file in 2022.
|
|
GCC permits not only unnamed structs and unions, but cv-qualified ones.
Our earlier fix in 6c3a38777b38a2ad87e2b2bcec4567578d1c83ec supported
unnamed structs and unions, but only unqualified ones.
Resolving away cvr-quals of nameless fields (and, irrelevantly, typedefs)
is easy and fixes this problem.
Tests adjusted accordingly.
libctf/
PR libctf/32746
* ctf-types.c (ctf_member_next): Resolve away cv-quals.
(ctf_member_info): Likewise.
* testsuite/libctf-lookup/struct-iteration-ctf.c: Add a cv-qualified
type or two: make sure to keep a non-qualified one.
* testsuite/libctf-lookup/struct-iteration.c: Verify consistency
of ctf_member_next and ctf_member_info.
* testsuite/libctf-lookup/struct-iteration.lk: Adjust.
Tested-by: Stephen Brennan <stephen.s.brennan@oracle.com>
|
|
Slices had a bunch of horrible usability problems. In particular, while
towers of cv-quals are resolved away by functions that need to do it, towers
of cv-quals with slices in the middle are not resolved away by functions
like ctf_enum_value that can see through slices: resolving volatile -> slice
-> const -> enum will leave it with a 'const', which will error pointlessly,
annoying callers, who reasonably expect slices to be more invisible than
this. (The user-callable ctf_type_resolve still does not resolve away
slices, because this is the only way users can see that the slices are there
at all.)
This is induced by a fix for another wart: ctf_add_enumerator does not
resolve anything away at all, so you can't even add enumerators to const or
volatile enums -- and more problematically, you can't add enumerators to
enums with an explicit encoding without resolving away the types by hand,
since ctf_add_enum_encoded works by returning a slice! ctf_add_enumerator
now resolves away all of those, so any cvr-or-typedef-or-slice-qual
terminating in an enum can be added to, exactly as callers likely expect.
(New tests added.)
libctf/
* ctf-create.c (ctf_add_enumerator): Resolve away cvr-qualness.
* ctf-types.c (ctf_type_resolve_unsliced): Don't terminate at
the first slice.
* testsuite/libctf-writable/slice-of-slice.*: New test.
|
|
ctf_archive_next returns an opened dict, which must be closed by the caller.
Thanks to Alan Modra for spotting this.
binutils/
* objdump.c (dump_ctf): Close dict.
* readelf.c (dump_section_as_ctf): Likewise.
|
|
<memory.h> is not needed and not standardized and is just an alias for
<string.h>.
<sys/param.h> is not needed and not standardized and contains a kitchen
sink of various unportable definitions not agreed upon and best done
manually or through other headers.
These fixes are needed to compile binutils on Sortix and other operating
systems with a strict POSIX.1-2024 libc without obsolete features.
Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org>
|
|
On aarch64-linux, in test-case gdb.base/nostdlib.exp I run into:
...
(gdb) continue^M
Continuing.^M
warning: Temporarily disabling breakpoints for unloaded shared library \
"/lib/ld-linux-aarch64.so.1"^M
^M
Breakpoint 2, _start () at nostdlib.c:20^M
20 {^M
(gdb) FAIL: $exp: pie=pie: continue to marker
...
This happens as follows:
- the test-case sets a breakpoint on *_start,
- the breakpoint resolves to *_start in the executable,
- the executable is started, and the breakpoint resolves to *_start in the
dynamic linker,
- execution stops at *_start in the dynamic linker,
- the test-case issues a continue, expecting to continue to the breakpoint on
marker,
- while continuing, the dynamic linker is reported as unloaded,
- the breakpoint again resolves to *_start in the executable,
- execution stops at *_start in the executable, and
- the test-case concludes that it failed to "continue to marker".
This doesn't happen on x86_64-linux. There, after the executable is started,
the breakpoint again resolves to *_start in the exec.
This is similar to what happens when printing _start.
On aarch64-linux, we print the _start in the dynamic linker:
...
$ gdb -q -batch outputs/gdb.base/nostdlib/nostdlib-pie \
-ex "b _start" \
-ex run \
-ex "print _start" \
-ex "info break"
Breakpoint 1 at 0x2bc: file nostdlib.c, line 23.
Breakpoint 1.2, _start () at ../sysdeps/aarch64/dl-start.S:22
22 ENTRY (_start)
$1 = {void (void)} 0xfffff7fd6ac0 <_start>
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
breakpoint already hit 1 time
1.1 y 0x0000aaaaaaaa02bc in _start at nostdlib.c:23
1.2 y 0x0000fffff7fd6ac0 in _start at dl-start.S:22
...
On x86_64-linux, we print the _start in the exec:
...
Breakpoint 1 at 0x2c5: file nostdlib.c, line 23.
Breakpoint 1.2, 0x00007ffff7fe4f00 in _start () from \
/lib64/ld-linux-x86-64.so.2
$1 = {void (void)} 0x5555555542c1 <_start>
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
breakpoint already hit 1 time
1.1 y 0x00005555555542c5 in _start at nostdlib.c:23
1.2 y 0x00007ffff7fe4f00 <_start>
...
The difference may be down to the availability of debug info for the _start in
the dynamic linker.
Finally, the described scenario on aarch64-linux is not deterministic. The
behavior depends on the dynamic linker being reported as unloaded, which has
been classified as a GLIBC bug, so that might get fixed.
Ideally this test-case would stop at both *_start in the executable and the
dynamic linker, but in absense of a way to specify this reliably (see PR32748),
fix this by making this a temporary breakpoint, ensuring that the breakpoint
will only trigger once.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR testsuite/32743
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32743
|
|
I noticed a
// namespace selftests
comment, which doesn't follow our comment formatting convention. I did
a find & replace to fix all the offenders.
Change-Id: Idf8fe9833caf1c3d99e15330db000e4bab4ec66c
|
|
|
|
Commit 2f0521c0d6f6 ("gdb/dwarf: fix signature_type created with nullptr
section") added some asserts in the dwarf2_per_cu_data constructor to
verify that the passed dwarf2_per_bfd and dwarf2_section_info are not
nullptr. However, the dummy dwarf2_per_cu_data objects created in the
dwarf2_find_containing_comp_unit selftests are passed nullptr for those
parameters.
I prefer to keep the asserts in place, as protection for the non-test
code and as self documentation, so fix this by passing some dummy
pointers in the test.
Change-Id: Ic7cdc1b976f7506041b651222234eefc998e473a
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
Most of the time, the length of a unit is known when constructing a
dwarf2_per_cu_data or signatured_type. Add a construtor parameter for
it. In the few cases where it isn't, pass 0, which leaves it unset.
Change-Id: I0c8b9683164d3e3f3823ed995f71689a4d17fd96
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
|
|
Pass -z separate-code to ld for -z mark-plt tests to fix:
FAIL: ld-x86-64/mark-plt-1a
FAIL: ld-x86-64/mark-plt-1b
FAIL: ld-x86-64/mark-plt-1c
FAIL: ld-x86-64/mark-plt-1d
FAIL: ld-x86-64/mark-plt-1a-x32
FAIL: ld-x86-64/mark-plt-1b-x32
FAIL: ld-x86-64/mark-plt-1c-x32
FAIL: ld-x86-64/mark-plt-1d-x32
when binutils is configured with --disable-separate-code.
* ld-x86-64/mark-plt-1a-x32.d: Pass -z separate-code to ld.
* ld-x86-64/mark-plt-1a.d: Likewise.
* ld-x86-64/mark-plt-1b-x32.d: Likewise.
* ld-x86-64/mark-plt-1b.d: Likewise.
* ld-x86-64/mark-plt-1c-x32.d: Likewise.
* ld-x86-64/mark-plt-1c.d: Likewise.
* ld-x86-64/mark-plt-1d-x32.d: Likewise.
* ld-x86-64/mark-plt-1d.d: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
CFI_escape is most commonly used to include DWARF expressions in the
unwind information. One may also use CFI_escape to add OS-specific CFI
opcodes. Up until now, SFrame generation process would skip generating
SFrame FDE at the mere sight of a CFI_escape opcode.
Fine tune the handling of CFI_escape for SFrame generation by explicitly
checking for few "harmless" (in context of SFrame generation)
CFI_escape DWARF info:
- DW_CFA_expression affecting registers of no significance to SFrame
stack trace info
- DW_CFA_value_offset affecting registers of no significance to SFrame
stack trace info
Expose the current cfi_escape_data structure in dw2gencfi.c to the
relevant header file to allow SFrame generation APIs to use it too.
Valid unwind info may be split across multiple .cfi_escape directives.
Conversely, it is also allowed to simply put multiple DWARF expressions
and/or operations in a single .cfi_escape directive. Handling all of
these cases correctly will need parsing/processing that is not deemed
worth the effort in context of SFrame generation; We continue to skip
generating SFrame FDE for these cases and warn the user.
In future, SFrame stack trace format may support non-SP/FP as base
register (albeit in limited form). Add an explicit check in
sframe_xlate_do_escape_expr (to test against the current CFA register)
to ensure the functionality continues to work.
Use differentiated warning text in sframe_xlate_do_val_offset to avoid
confusion to the user as the same function is used for handling
.cfi_val_offset and .cfi_escape DW_CFA_val_offset,...
Also, add a common test with DWARF reg 12 which is non SP / FP on x86_64
and aarch64 (and s390x too).
gas/
* gas/dw2gencfi.c (struct cfi_escape_data): Move from ...
* gas/dw2gencfi.h (struct cfi_escape_data): ... to.
* gas/gen-sframe.c (sframe_xlate_do_val_offset): Include string
for .cfi_escape conditionally.
(sframe_xlate_do_escape_expr): New definition.
(sframe_xlate_do_escape_val_offset): Likewise.
(sframe_xlate_do_cfi_escape): Likewise.
(sframe_do_cfi_insn): Handle CFI_escape explicitly.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
* gas/cfi-sframe/cfi-sframe-common-9.d: New test.
* gas/cfi-sframe/cfi-sframe-common-9.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.s: New test.
|
|
If data is encountered that is not a power of two, dump all of the data with
a .<N>byte directive. The current largest support risc-v instruction length
is 22, so the data over 22 bytes will be displayed by,
.insn, 22, ... + .<N-22>byte.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
|
|
Those tests were generated by a linker having "-z separate-code" on by
default. However, being controlled by a configure option, it can be off
by default. Forcing the option as part of the tests ensures clean
results in both cases.
|
|
On x86_64-linux, with gcc 7.5.0 I ran into a build breaker:
...
gdb/dwarf2/read.c: In function ‘void read_comp_units_from_section()’:
gdb/dwarf2/read.c:4297:31: error: unused variable ‘sig_type_it’ \
[-Werror=unused-variable]
auto [sig_type_it, inserted] = sig_types.emplace (sig_ptr);
^
...
Fix this by dropping the unused variable.
Tested on x86_64-linux, by completing a build.
|
|
Commit c44ab627b02 ("gdb/dwarf: pass section to dwarf2_per_cu_data
constructor") introduced a regression when using dwp. It can be
reproduced with:
$ make check TESTS="gdb.base/ptype-offsets.exp" RUNTESTFLAGS="--target_board=fission-dwp"
Then, to investigate:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets -ex 'ptype int'
Reading symbols from testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3195:38: runtime error: member call on null pointer of type 'struct dwarf2_section_info'
Commit c44ab627b02 removed the assignment of signatured_type::section
(dwarf2_per_cu_data::section, really) in
fill_in_sig_entry_from_dwo_entry with the justification that the section
was already set when constructing the signatured_type. Well, that was
true except for one spot in lookup_dwp_signatured_type which passes a
nullptr section to add_type_unit.
Fix that by passing the section to add_type_unit in that one spot. This
is the same section that would have been set by
fill_in_sig_entry_from_dwo_entry before.
Add some asserts in the dwarf2_per_cu_data constructor to verity that
the passed dwarf2_per_bfd and dwarf2_section_info are non-nullptr.
Change-Id: If27dae6b4727957c96defc058c7e4be31472005b
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32739
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I'd like to add these asserts in dwarf2_per_cu_data's constructor:
gdb_assert (per_bfd != nullptr);
gdb_assert (section != nullptr);
However, these dummy instances of signatured_type, used as hash table
lookup keys, are in the way:
signatured_type find_sig_entry (nullptr, nullptr, sect_offset {}, sig);
This motivated me to convert the dwarf2_per_bfd::signatured_types hash
table to a gdb::unordered_set. This allows finding an entry by simply
passing the signature (an integer) and removes the need to create dummy
signatured_type objects.
There is one small unfortunate pessimization:
lookup_dwo_signatured_type, for instance, does a lookup by signature to
find an existing signatured_type. If not found, it adds a new one by
calling add_type_unit. The current code passes down the slot where to
put the new element, avoiding an extra hash when inserting the new
signatured_type. With the new code, I don't see a way to do that. This
is probably negligible, but it bugs me. If we used a map of signature
-> signatured_type, I would see a way, but then it would waste space.
I see one change in behavior, that is not really important IMO. In
read_comp_units_from_section, if duplicate signature type entries are
detected, the code prior to this patch overwrites the existing
signatured_type in the hash table with the new one. With this patch,
the existing signatured_type is kept: the call to emplace does not
insert the value if an existing equal value exists.
Other than that, no behavior change expected.
Change-Id: I0bef1b49cc63dbdf4e32fa9d4ea37f83025efc3e
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I identified the following functions that currently take a
dwarf2_per_objfile, but could take a less specific dwarf2_per_bfd.
- try_open_dwop_file
- open_dwo_file
- open_dwp_file
The uses of the per-objfile object in try_open_dwop_file can be replaced
with equivalent per-bfd ones.
Change-Id: Ia31fa0b988375e86a715ee863d4ec3c572ce89c0
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I found a few spots where the existing dwz_file::filename method could
be used.
Change-Id: I0522b1e3abbfac2f392f9ec777c37b242ee236d8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
All users of these typedefs use them inside a gdb::function_view. Move
the gdb::function_view in the typedefs themselves. This shortens the
types in function signatures and helps with readability, IMO.
Rename them to remove the `_ftype` suffix: this suffix is not as
relevant in C++ as it was in C. With function_view, the caller can pass
more than just a simple "function". Anyway, I think it's clearer to
name them after the role the callback has (listener, matcher, etc).
Adjust some related comments.
Change-Id: Iaf9f8ede68b51ea9e4d954792e8eb90def8659a6
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Initialize fields of tu_stats to 0, remove the explicit default
initialization of dwarf2_per_bfd::tu_stats.
Change-Id: I98b2d5c4171291a3df2569466559174fb7cf32b6
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
struct print_one_inferior_data is not used, so remove it.
|
|
This include is reported as unused by clangd.
Change-Id: I95b73f85607537551ef54e46551197d1371d621b
|
|
Implement the target_ops displaced stepping methods to add displaced
stepping support when debugging AMD GPU programs. The knowledge of how
to prepare and finish displaced steps is provided by the amd-dbgapi
library, so the code here is relatively straightforward. No need to
parse instructions or handle fixups, that is done by the lib We just
need to remember, for each thread doing a displaced step, the displaced
stepping id given by the library.
Add a test to exercise the new functionality. The compiler generates
DWARF that GDB doesn't understand yet [1], so trying to step over a
breakpoint with DWARF present gives:
(gdb) si
Unhandled dwarf expression opcode 0xe9
The test purposefully builds the binary without DWARF info to circumvent
this.
[1] https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
Change-Id: I53f459221a42d4b02a6041eadb8cf554500e2162
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
|
|
The amd-dbgapi library, used in the AMD GPU port, has the capability to
prepare and cleanup displaced step operations. In order to use it, add
the following target_ops methods:
- supports_displaced_step
- displaced_step_prepare
- displaced_step_finish
- displaced_step_restore_all_in_ptid
Prior to this patch, displaced stepping preparation and cleanup is done
solely by gdbarches. Update infrun to use these new target methods
instead of gdbarch hooks. To keep the behavior for other architectures
unchanged, make the default implementations of the new target_ops method
forward to the thread's gdbarch.
displaced_step_restore_all_in_ptid won't be needed for the AMD GPU port,
but was added for completeness. It would be weird for infrun displaced
stepping code to call target methods except for that one thing where it
calls a gdbarch method.
Since this patch only adds infrastructure, no behavior change is
expected.
Change-Id: I07c68dddb5759a55cd137a711d2679eedc0d9285
|
|
Since we have gdb::unordered_map, swap std::unordered_map for that.
Change-Id: If2ef652fe18c1a440a25cff6131d29e37091bdbe
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
|
|
On windows, when creating a directory with an absolute path,
mkdir_recursive would start by trying to make 'C:'.
On windows, this has a special meaning, which is "the current
directory on the C drive". So the first thing it tries to do
is create the current directory.
Most of the time, this fails with EEXIST, so the function
continues as expected. However if the current directory is
C:/, trying to create that causes EPERM, which causes the
function to prematurely terminate.
(The same applies for any drive letter.)
This patch resolves this issue, by skipping the drive letter
so that it is never sent to the mkdir call.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The SFrame FDE for the PLT0 entry is of type PCINC, which does does not
make use of the type PCMASK repetition block size. Therefore generate
the FDE with a repetition block size of zero.
bfd/
* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use FDE
repetition block size of zero for PLT0.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
GDB allows remotes to implement extension commands which can
be accessed using the 'monitor' command.
This allows remotes to implement functionality which does not
exist in GDB for whatever reason (doesn't make sense, too
specific to one target, etc.)
However, before this change, the remote would not necessarily know
which thread/inferior was currently selected on the GDB client.
This prevents the implementation of any 'monitor' commands which are
specific to a single inferior/thread on the remote.
This is because GDB informs the remote of the current thread
lazily - only when it is relevant to the RSP command next being
sent.
qRcmd is the underlying RSP command used for monitor commands, so
this change ensures that GDB will update the remote with the
'current' thread if it has changed since the remote was last
informed.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that the disable_breakpoints_in_shlibs function disables
breakpoints without calling notify_breakpoint_modified. This commit
is one step towards fixing this issue.
There are currently only two uses of disable_breakpoints_in_shlibs,
one in clear_solib (in solib.c), and the other in
windows_nat_target::do_initial_windows_stuff (in windows-nat.c).
I believe that the call in windows-nat.c can be shown to be redundant,
and therefore can be removed.
windows_nat_target::do_initial_windows_stuff is called from two
places: windows_nat_target::attach and
windows_nat_target::create_inferior, these are the target_ops
functions used to attach to a running process, or for creating a new
process, and are only called from attach_command or run_command_1,
both in infcmd.c.
Both attach_command and run_command_1 call target_pre_inferior before
calling the relevant target_ops function.
In target_pre_inferior, so long as the target doesn't have a global
solist (and windows doesn't), we always call no_shared_libraries (from
solib.c), which calls clear_solib (also in solib.c), which in turn
calls disable_breakpoints_in_shlibs.
My claim then, is that, any time we reach the
disable_breakpoints_in_shlibs call in
windows_nat_target::do_initial_windows_stuff, we will have always have
called disable_breakpoints_in_shlibs already via clear_solib.
I think it should be safe to remove the disable_breakpoints_in_shlibs
call from windows_nat_target::do_initial_windows_stuff. There should
be no user visible changes.
My ultimate goal, which I'll address in follow on commits, is to
delete disable_breakpoints_in_shlibs completely. Removing this call
means that we only have one disable_breakpoints_in_shlibs call
remaining in GDB.
Testing for this change has been minimal. My only Windows build
machine is not great, and I've never managed to get DejaGNU running in
that environment. This commit builds, and a few basic, manual tests
seem fine, but beyond that, this change is untested.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Consider the test-case sources main.c and foo.c:
$ cat main.c
extern int foo (void);
int
main (void)
{
return foo ();
}
$ cat foo.c
extern int foo (void);
int
foo (void)
{
return 0;
}
and main.c compiled with debug info, and foo.c without:
$ gcc -g main.c -c
$ gcc foo.c -c
$ gcc -g main.o foo.o
In TUI mode, if we run to foo:
$ gdb -q a.out -tui -ex "b foo" -ex run
it gets us "[ No Source Available ]":
┌─main.c─────────────────────────────────────────┐
│ │
│ │
│ │
│ [ No Source Available ] │
│ │
│ │
└────────────────────────────────────────────────┘
(src) In: foo L?? PC: 0x400566
...
Breakpoint 1, 0x0000000000400566 in foo ()
(gdb)
But after resizing (pressing ctrl-<minus> in the gnome-terminal), we
get instead the source for main.c:
┌─main.c─────────────────────────────────────────┐
│ 3 int │
│ 4 main (void) │
│ 5 { │
│ 6 return foo (); │
│ 7 } │
│ │
│ │
└────────────────────────────────────────────────┘
(src) In: foo L?? PC: 0x400566
...
Breakpoint 1, 0x0000000000400566 in foo ()
(gdb)
which is inappropriate because we're stopped in function foo, which is
not in main.c.
The problem is that, when the window is resized, GDB ends up calling
tui_source_window_base::rerender. The rerender function has three
cases, one for when the window already has some source code
content (which is not the case here), a case for when the inferior is
active, and we have a selected frame (which is the case that applies
here), and a final case for when the inferior is not running.
For the case which we end up in, the source code window has no
content, but the inferior is running, so we have a selected frame, GDB
calls the get_current_source_symtab_and_line() function to get the
symtab_and_line for the current location.
The get_current_source_symtab_and_line() will actually return the last
recorded symtab and line location, not the current symtab and line
location.
What this means, is that, if the current location has no debug
information, get_current_source_symtab_and_line() will return any
previously recorded location, or failing that, the default (main)
location.
This behaviour of get_current_source_symtab_and_line() also causes
problems for the 'list' command. Consider this pure CLI session:
(gdb) break foo
Breakpoint 1 at 0x40110a
(gdb) run
Starting program: /tmp/a.out
Breakpoint 1, 0x000000000040110a in foo ()
(gdb) list
1 extern int foo (void);
2
3 int
4 main (void)
5 {
6 return foo ();
7 }
(gdb) list .
Insufficient debug info for showing source lines at current PC (0x40110a).
(gdb)
However, if we look at how GDB's TUI updates the source window during
a normal stop, we see that GDB does a better job of displaying the
expected contents. Going back to our original example, when we start
GDB with:
$ gdb -q a.out -tui -ex "b foo" -ex run
we do get the "[ No Source Available ]" message as expected. Why is
that?
The answer is that, in this case GDB uses tui_show_frame_info to
update the source window, tui_show_frame_info is called each time a
prompt is displayed, like this:
#0 tui_show_frame_info (fi=...) at ../../src/gdb/tui/tui-status.c:269
#1 0x0000000000f55975 in tui_refresh_frame_and_register_information () at ../../src/gdb/tui/tui-hooks.c:118
#2 0x0000000000f55ae8 in tui_before_prompt (current_gdb_prompt=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/tui/tui-hooks.c:165
#3 0x000000000090ea45 in std::_Function_handler<void(char const*), void (*)(char const*)>::_M_invoke (__functor=..., __args#0=@0x7ffc955106b0: 0x31ef930 <top_prompt+16> "(gdb) ") at /usr/include/c++/9/bits/std_function.h:300
#4 0x00000000009020df in std::function<void(char const*)>::operator() (this=0x5281260, __args#0=0x31ef930 <top_prompt+16> "(gdb) ") at /usr/include/c++/9/bits/std_function.h:688
#5 0x0000000000901c35 in gdb::observers::observable<char const*>::notify (this=0x31dda00 <gdb::observers::before_prompt>, args#0=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/../gdbsupport/observable.h:166
#6 0x00000000008ffed8 in notify_before_prompt (prompt=0x31ef930 <top_prompt+16> "(gdb) ") at ../../src/gdb/event-top.c:518
#7 0x00000000008fff08 in top_level_prompt () at ../../src/gdb/event-top.c:534
#8 0x00000000008ffdeb in display_gdb_prompt (new_prompt=0x0) at ../../src/gdb/event-top.c:487
If we look at how tui_show_frame_info figures out what source to
display, it doesn't use get_current_source_symtab_and_line(), instead,
it finds a symtab_and_line directly from a frame_info_pt. This means
we are not dependent on get_current_source_symtab_and_line() returning
the current location (which it does not).
I propose that we change tui_source_window_base::rerender() so that,
for the case we are discussing here (the inferior has a selected
frame, but the source window has no contents), we move away from using
get_current_source_symtab_and_line(), and instead use find_frame_sal
instead, like tui_show_frame_info does.
This means that we will always use the inferior's current location.
Tested on x86_64-linux.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reported-By: Andrew Burgess <aburgess@redhat.com>
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32614
|
|
When building gdb, I run into:
...
ctf-spec.texi:809: warning: @xref should not appear on @multitable line
...
The line in question is:
...
@multitable {Kind} {@code{CTF_K_VOLATILE}} {Indicates a type that cannot be represented in CTF, or that} {@xref{Pointers typedefs and cvr-quals}}
...
which defines a prototype row with 4 columns.
However, the table only has 3 colums:
...
@headitem Kind @tab Macro @tab Purpose
...
Fix the warning by removing the item in the prototype row representing a fourth column.
Tested on aarch64-linux.
PR libctf/32044
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32044
|
|
|
|
After test-case gdb.mi/mi-break.exp, a gdb instance is left running.
The test-case starts two instances using mi_clean_restart, one using
separate-mi-tty.
For each instance, gdb_exit is called once, from two different locations:
- mi_clean_restart, and
- gdb_finish.
But this doesn't seem to be effective for the separate-mi-tty case.
Fix this by calling gdb_mi_exit at the end of proc test_break.
Likewise in a few more more test-case.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32709
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32709
|
|
In his review of my recent checkpoint work (commit e5501dd4321),
Andrew Burgess suggested that I use GDB's structured table generation
mechanism for the "info checkpoints" command. This patch does
that.
Andrew also recommended using print_stack_frame() for the "Frame"
column. I tried this, but ran into some problems, which are described
in a comment in the code. I got it to mostly work, except for the
case when the current/active fork is running. Switching context away
from and then back to a running fork doesn't work. It could, perhaps,
be made to work, but I'm not convinced that the checkpoint facility is
important enough to expend the effort for this case. So, instead,
I simply adapted the existing checkpoint frame printing code to
use the ui_out machinery instead of gdb_printf.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
We currently check the TERM environment variable any time we call one
of the ui_file::can_emit_style_escape() functions. This seems
excessive.
During GDB's startup we also check for the NO_COLOR environment
variable and disable styling if this is set.
I propose that we combine these two checks, and perform them just once
during startup (as the current NO_COLOR check is currently done). As
with the NO_COLOR check, if the TERM variable is set to "dumb"
indicating that styling is not supported then we should just set
cli_styling to false.
This does mean that the user can then 'set style enabled on', even for
a dumb terminal, which was not possible previously. Before this
commit the "dumb" terminal check was separate and would prevent
styling even if 'set style enabled on' was in effect.
Of course, trying to turn on styling in a dumb terminal might not give
the results that a user hope for. And so, I have implemented a check
in `set_style_enabled`, so in a dumb terminal a user will see this:
(gdb) set style enabled on
warning: The current terminal doesn't support styling. Styled output might not appear as expected.
After which GDB will try to emit styling. We could, potentially,
prevent styling being enabled instead of emitting a warning, but I'm
inclined to let the user turn on styling if they really want to.
Approved-By: Kevin Buettner <kevinb@redhat.com>
Acked-By: Tom Tromey <tom@tromey.com>
|
|
Currently the TUI's asm window uses `source_styling` to control
styling. This setting is supposed to be for styling of source files
though, and the asm window displays disassembler output.
We have a different setting for this `disassemble_styling`, which is
controlled with 'set style disassembler enabled on|off'.
Switch to use the correct control variable.
I've written a new test for this, but this required some additions to
the tuiterm library in order to grab character attributes for a screen
region.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The help text for 'set/show style disassembler enable' was output of
date. It talks about GDB requiring the Python Pygments library, but
for many common architectures this is no longer the case, libopcode is
used for styling.
The Python Pygments library is still used as a fallback for those
architectures that libopcode doesn't currently style.
I've updated the help text to try and explain all this. The manual
was already updated.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
Here ( https://sourceware.org/gdb/current/onlinedocs/gdb.html/Signals.html ) I
read:
...
GDB has the ability to detect any occurrence of a signal in your program. You
can tell GDB in advance what to do for each kind of signal.
...
However, here ( https://man7.org/linux/man-pages/man2/ptrace.2.html ) I read:
...
While being traced, the tracee will stop each time a signal is
delivered, even if the signal is being ignored. (An exception is
SIGKILL, which has its usual effect.)
...
So, it seems to be that for SIGKILL we can't tell GDB in advance what to do.
Fix the documentation to reflect this.
Approved-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/32714
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32714
|
|
For the Rust language, to avoid segmentation fault in case of an empty
array, do not try to copy any elements, but allocate and return
the empty array immediately.
With the command before the change, gdb crashes with message:
(gdb) set lang rust
(gdb) p [1;0]
Fatal signal: Segmentation fault
After the fix in this commit, gdb shows following message:
(gdb) set lang rust
(gdb) p [1;0]
$1 = []
Update the existing test case gdb.rust/expr.exp to verify the change.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
or -R options and no regular relocs are present.
PR 32459
|
|
"Check we have ..." --> "Check if we have ..."
This is for consistency with the previous comment and
the code downstream.
|
|
For background reading, please see the previous patch, and the patch
before that!
After the last two patches, internal breakpoints can now be marked as
shlib_disabled if the library in which they are placed is unloaded.
The patch before last discusses a situation related to the
gdb.base/nostdlib.exp test, when run on a GNU/Linux glibc based system
where executables are compiled as PIE by default.
In this case it is observed that the dynamic linker will actually
report itself as unloaded (i.e. remove itself from the list of
currently loaded shared libraries). This behaviour is likely a bug in
the dynamic linker, but this behaviour exists in released versions of
the dynamic linker, so GDB should (if the cost is not too great) be
changed to handle this situation.
This commit handles a problem with the 'maint info breakpoints'
command.
When the dynamic linker is unloaded the 'shlib event' breakpoint is
marked as shlib_disabled (i.e. placed into the pending state). When
displaying the breakpoint in the 'maint info breakpoints' output, GDB
will try to print the locspec (location_spec *) as a string
Unfortunately, the locspec will be nullptr as the internal breakpoints
are not created via a location_spec, this means that GDB ends up
trying to call location_sepc::to_string() on a nullptr, resulting in
undefined behaviour (and a crash).
For most internal breakpoint types this is not a problem. If we
consider bp_longjmp_master for example, if the shared library
containing a breakpoint of this type is unloaded then first GDB marks
the breakpoint as shlib_disabled, then after unloading the shared
library breakpoint_re_set is called, which will delete the internal
breakpoint, and then try to re-create it (if needed). As a result,
the user never gets a change to run 'maint info breakpoints' on a
bp_longjmp_master breakpoint in the shlib_disabled state.
But bp_shlib_event and bp_thread_event breakpoints are not deleted and
recreated like this (see internal_breakpoint::re_set), so it is
possible, in rare cases, that we could end up trying to view one of
these breakpoint in a shlib_disabled state, and it would be nice if
GDB didn't crash as a result.
I've updated the printing code to check for and handle this case, and
I've updated the docs to mention this (rare) case.
For testing, I've extended gdb.base/nostdlib.exp to compile as
pie and nopie, and then run 'maint info breakpoints'. If we're
running on a buggy glibc then this will trigger the crash. I don't
know how I can trigger this problem without a buggy glibc as this
would require forcing the dynamic linker to be unloaded.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
