| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit adds floating-point support for LoongArch gdb.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
When building gdb with -fsanitize=address we run into:
...
builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 -data-directory \
build/gdb/data-directory^M
==10637==ASan runtime does not come first in initial library list; you \
should either link runtime to your application or manually preload it with \
LD_PRELOAD.^M
ERROR: GDB process no longer exists
...
Prevent the ASan runtime error by using
ASAN_OPTIONS=verify_asan_link_order=0. This makes both test-cases pass.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29358
|
|
Add a new file tsan-suppressions.txt, to suppress the "unlock unlocked mutex"
problem in ncurses, filed in PR29328.
The file is added to the TSAN_OPTIONS in lib/gdb.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29328
|
|
When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a data race between:
...
Read of size 1 at 0x7b200000300d by thread T2:^M
#0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \
(gdb+0x82ec95)^M
...
and:
...
Previous write of size 1 at 0x7b200000300d by main thread:^M
#0 prepare_one_comp_unit gdb/dwarf2/read.c:23588 (gdb+0x86f973)^M
...
In other words, between:
...
if (this_cu->reading_dwo_directly)
...
and:
...
cu->per_cu->lang = pretend_language;
...
Likewise, we run into a data race between:
...
Write of size 1 at 0x7b200000300e by thread T4:
#0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720)
...
and:
...
Previous read of size 1 at 0x7b200000300e by main thread:
#0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \
(gdb+0x82edab)
...
In other words, between:
...
this_cu->unit_type = DW_UT_partial;
...
and:
...
if (this_cu->reading_dwo_directly)
...
Likewise for the write to addresses_seen in cooked_indexer::check_bounds and a
read from is_dwz in dwarf2_find_containing_comp_unit for test-case
gdb.dwarf2/dw2-dir-file-name.exp and target board cc-with-dwz-m.
The problem is that the written fields are part of the same memory location as
the read fields, so executing a read and write in different threads is
undefined behavour.
Making the written fields separate memory locations, using the new
struct packed template fixes this.
The set of fields has been established experimentally to be the
minimal set to get rid of this type of -fsanitize=thread errors, but
more fields might require the same treatment.
Looking at the properties of the lang field, unlike dwarf_version it's
not available in the unit header, so it will be set the first time
during the parallel cooked index reading. The same holds for
unit_type, and likewise for addresses_seen.
dwarf2_per_cu_data::addresses_seen is moved so that the bitfields that
currently follow it can be merged in the same memory location as the
bitfields that currently precede it, for better packing.
Tested on x86_64-linux.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532
|
|
For csky arch, the correspondence between Dwarf registers and GDB
registers are as follows:
dwarf regnos 0~31 ==> gdb regs r0~r31
dwarf regno CSKY_HI_REGNUM(36) ==> gdb reg hi
dwarf regno CSKY_LO_REGNUM(37) ==> gdb reg hi
dwarf regno CSKY_PC_REGNUM(72) ==> gdb reg pc
dwarf regnos FV_PSEUDO_REGNO_FIRST(74)~FV_PSEUDO_REGNO_LAST(201)
==>
gdb regs s0~s127 (pseudo regs for float and vector regs)
other dwarf regnos have no corresponding gdb regs to them.
|
|
[Note: the testcased added by this commit depends on
https://sourceware.org/pipermail/gdb-patches/2022-June/190259.html,
otherwise GDB just crashes when detaching the core]
Currently, in MI, =thread-created are always emitted, like:
=thread-group-started,id="i1",pid="195680"
=thread-created,id="1",group-id="i1"
...
but on teardown, if the target uses exit_inferior_silent, then you'll
only see the inferior exit notification (thread-group-exited), no
notification for threads.
The core target is one of the few targets that use
exit_inferior_silent. Here's an example session:
-target-select core $corefile
=thread-group-started,id="i1",pid="195680"
=thread-created,id="1",group-id="i1"
...
^connected,frame=....
(gdb)
-target-detach
=thread-group-exited,id="i1"
^done
(gdb)
This imbalance of emitting =thread-created but then not =thread-exited
seems off to me. (And, it complicates changes I want to do to
centralize emitting thread exit notifications for the CLI, which is
why I'm looking at this.)
And then, since most other targets use exit_inferior instead of
exit_inferior_silent, MI is already emitting =thread-exited
notifications when tearing down an inferior, for most targets.
This commit makes MI always emit the =thread-exited notifications,
even for exit_inferior_silent.
Afterwards, when debugging a core, MI outputs:
(gdb)
-target-detach
=thread-exited,id="1",group-id="i1" << new line
=thread-group-exited,id="i1"
^done
(gdb)
Surprisingly, there's no MI testcase debugging a core file. This
commit adds the first.
Change-Id: I5100501a46f07b6bbad3e04d120c2562a51c93a4
|
|
After loading a core file, you're supposed to be able to use "detach"
to unload the core file. That unfortunately regressed starting with
GDB 11, with these commits:
1192f124a308 - gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses
408f66864a1a - detach in all-stop with threads running
resulting in a GDB crash:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
2899 if (proc_target->commit_resumed_state)
(top-gdb) bt
#0 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
#1 0x0000555555e848bf in scoped_disable_commit_resumed::reset (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3023
#2 0x0000555555e84a0c in scoped_disable_commit_resumed::reset_and_commit (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3049
#3 0x0000555555e739cd in detach_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:2791
#4 0x0000555555c0ba46 in do_simple_func (args=0x0, from_tty=1, c=0x55555662a600) at ../../src/gdb/cli/cli-decode.c:95
#5 0x0000555555c112b0 in cmd_func (cmd=0x55555662a600, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:2514
#6 0x0000555556173b1f in execute_command (p=0x5555565c5916 "", from_tty=1) at ../../src/gdb/top.c:699
The code that crashes looks like:
static void
maybe_set_commit_resumed_all_targets ()
{
scoped_restore_current_thread restore_thread;
for (inferior *inf : all_non_exited_inferiors ())
{
process_stratum_target *proc_target = inf->process_target ();
if (proc_target->commit_resumed_state)
^^^^^^^^^^^
With 'proc_target' above being null. all_non_exited_inferiors filters
out inferiors that have pid==0. We get here at the end of
detach_command, after core_target::detach has already run, at which
point the inferior _should_ have pid==0 and no process target. It is
clear it no longer has a process target, but, it still has a pid!=0
somehow.
The reason the inferior still has pid!=0, is that core_target::detach
just unpushes, and relies on core_target::close to actually do the
getting rid of the core and exiting the inferior. The problem with
that is that detach_command grabs an extra strong reference to the
process stratum target, so the unpush_target inside
core_target::detach doesn't actually result in a call to
core_target::close.
Fix this my moving the cleaning up the core inferior to a shared
routine called by both core_target::close and core_target::detach. We
still need to cleanup the inferior from within core_file::close
because there are paths to it that want to get rid of the core without
going through detach. E.g., "core-file" -> "run".
This commit includes a new test added to gdb.base/corefile.exp to
cover the "core-file core" -> "detach" scenario.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29275
Change-Id: Ic42bdd03182166b19f598428b0dbc2ce6f67c893
|
|
In the description of stop replies, where the "thread" register is
explained, and where the fork and vfork stop reasons are detailed,
there are references to "@var{thread-id}", but such variable does not
actually exist. This commit fixes it.
Change-Id: If679944aaf15f6f64aabe506339a9e7667864cab
|
|
The -msign-return-address switch has been dropped from GCC, but some
older compiler may still support it. Make sure we try both
-msign-return-address and -mbranch-protection before bailing out when
running gdb.arch/aarch64-pauth.exp.
|
|
This commit extends GDB to make use of libopcodes styling support
where available, currently this is just i386 based architectures, and
RISC-V.
For architectures that don't support styling using libopcodes GDB will
fall back to using the Python Pygments package, when the package is
available.
The new libopcodes based styling has the disassembler identify parts
of the disassembled instruction, e.g. registers, immediates,
mnemonics, etc, and can style these components differently.
Additionally, as the styling is now done in GDB we can add settings to
allow the user to configure which colours are used right from the GDB
CLI.
There's some new maintenance commands:
maintenance set libopcodes-styling enabled on|off
maintenance show libopcodes-styling
These can be used to manually disable use of libopcodes styling. This
is a maintenance command as it's not anticipated that a user should
need to do this. But, this could be useful for testing, or, in some
rare cases, a user might want to override the Python hook used for
disassembler styling, and then disable libopcode styling so that GDB
falls back to using Python. Right now I would consider this second
use case a rare situation, which is why I think a maintenance command
is appropriate.
When libopcodes is being used for styling then the user can make use
of the following new styles:
set/show style disassembler comment
set/show style disassembler immediate
set/show style disassembler mnemonic
set/show style disassembler register
The disassembler also makes use of the 'address' and 'function'
styles to style some parts of the disassembler output. I have also
added the following aliases though:
set/show style disassembler address
set/show style disassembler symbol
these are aliases for:
set/show style address
set/show style function
respectively, and exist to make it easier for users to discover
disassembler related style settings. The 'address' style is used to
style numeric addresses in the disassembler output, while the 'symbol'
or 'function' style is used to style the names of symbols in
disassembler output.
As not every architecture supports libopcodes styling, the maintenance
setting 'libopcodes-styling enabled' has an "auto-off" type behaviour.
Consider this GDB session:
(gdb) show architecture
The target architecture is set to "auto" (currently "i386:x86-64").
(gdb) maintenance show libopcodes-styling enabled
Use of libopcodes styling support is "on".
the setting defaults to "on" for architectures that support libopcodes
based styling.
(gdb) set architecture sparc
The target architecture is set to "sparc".
(gdb) maintenance show libopcodes-styling enabled
Use of libopcodes styling support is "off" (not supported on architecture "sparc")
the setting will show as "off" if the user switches to an architecture
that doesn't support libopcodes styling. The underlying setting is
still "on" at this point though, if the user switches back to
i386:x86-64 then the setting would go back to being "on".
(gdb) maintenance set libopcodes-styling enabled off
(gdb) maintenance show libopcodes-styling enabled
Use of libopcodes styling support is "off".
now the setting is "off" for everyone, even if the user switches back
to i386:x86-64 the setting will still show as "off".
(gdb) maintenance set libopcodes-styling enabled on
Use of libopcodes styling not supported on architecture "sparc".
(gdb) maintenance show libopcodes-styling enabled
Use of libopcodes styling support is "off".
attempting to switch the setting "on" for an unsupported architecture
will give an error, and the setting will remain "off".
(gdb) set architecture auto
The target architecture is set to "auto" (currently "i386:x86-64").
(gdb) maintenance show libopcodes-styling enabled
Use of libopcodes styling support is "off".
(gdb) maintenance set libopcodes-styling enabled on
(gdb) maintenance show libopcodes-styling enabled
Use of libopcodes styling support is "on".
the user will need to switch back to a supported architecture before
they can one again turn this setting "on".
|
|
The gdb_disassemble_info class is a wrapper around the libopcodes
disassemble_info struct. The 'stream' field of disassemble_info is
passed as an argument to the fprintf_func and fprintf_styled_func
callbacks when the disassembler wants to print anything.
Previously, GDB would store a pointer to a ui_file object in the
'stream' field, then, when the disassembler wanted to print anything,
the content would be written to the ui_file object. An example of an
fprintf_func callback, from gdb/disasm.c is:
int
gdb_disassembler::dis_asm_fprintf (void *stream, const char *format, ...)
{
/* Write output to STREAM here. */
}
This is fine, but has one limitation, within the print callbacks we
only have access to STREAM, we can't access any additional state
stored within the gdb_disassemble_info object.
Right now this isn't a problem, but in a future commit this will
become an issue, how we style the output being written to STREAM will
depend on the state of the gdb_disassemble_info object, and this state
might need to be updated, depending on what is being printed.
In this commit I propose changing the 'stream' field of the
disassemble_info to carry a pointer to the gdb_disassemble_info
sub-class, rather than the stream itself.
We then have the two sub-classes of gdb_disassemble_info to consider,
the gdb_non_printing_disassembler class never cared about the stream,
previously, for this class, the stream was nullptr. With the change
to make stream be a gdb_disassemble_info pointer, no further updates
are needed for gdb_non_printing_disassembler.
The other sub-class is gdb_printing_disassembler. In this case the
sub-class now carries around a pointer to the stream object. The
print callbacks are updated to cast the incoming stream object back to
a gdb_printing_disassembler, and then extract the stream.
This is purely a refactoring commit. A later commit will add
additional state to the gdb_printing_disassembler, and update the
print callbacks to access this state.
There should be no user visible changes after this commit.
|
|
With gdb build with -fsanitize=thread and test-case
gdb.dwarf2/dw4-sig-types.exp and target board cc-with-dwz-m we run into a data
race between:
...
Write of size 4 at 0x7b2800002268 by thread T4:^M
#0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6236 \
(gdb+0x82f525)^M
...
and this read:
...
Previous read of size 4 at 0x7b2800002268 by thread T1:^M
#0 dwarf2_find_containing_comp_unit gdb/dwarf2/read.c:23444 \
(gdb+0x86e22e)^M
...
In other words, between this write:
...
this_cu->length = cu->header.get_length ();
...
and this read:
...
&& mid_cu->sect_off + mid_cu->length > sect_off))
...
of per_cu->length.
Fix this similar to the per_cu->dwarf_version case, by only setting it if
needed, and otherwise verifying that the same value is used. [ Note that the
same code is already present in the other cutu_reader constructor. ]
Move this logic into into a member function set_length to make sure it's used
consistenly, and make the field private in order to enforce access through the
member functions, and rename it to m_length.
This exposes (running test-case gdb.dwarf2/fission-reread.exp) that in
fill_in_sig_entry_from_dwo_entry, the m_length field is overwritten.
For now, allow for that exception.
While we're at it, make sure that the length is set before read.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29344
|
|
There's a spot in read_comp_units_from_section where we explictly use
initial_length_size to get the total length:
...
this_cu->length = cu_header.length + cu_header.initial_length_size;
...
Instead, just use cu_header.get_length ().
Tested on x86_64-linux.
|
|
It should be ARCH_AARCH64_MTE_LINUX_H as opposed to ARCH_AARCH64_LINUX_H.
|
|
Commit 736918239b16 ("gdb: LoongArch: add orig_a0 into register set")
introduced orig_a0, similar processing needs to be done in gdbserver.
At the same time, add orig_a0 related comments.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Move "enum loongarch_regnum" to gdb/arch/loongarch.h so that the
macro definitions can be used in gdbserver/linux-loongarch-low.cc
to simplify the code.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
PR python/27000 points out that gdb.block_for_pc will accept a Python
integer, but not a gdb.Value. This patch corrects this oversight.
I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use
get_addr_from_python instead. I also looked at uses of GDB_PY_LL_ARG,
but those seemed relatively unlikely to be useful with a gdb.Value, so
I didn't change them. My thinking here is that a Value will typically
come from inferior memory, and something like a line number is not too
likely to be found this way.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27000
|
|
PR python/29217 points out that gdb.parameter will return bool values,
but gdb.set_parameter will not properly accept them. This patch fixes
the problem by adding a special case to set_parameter.
I looked at a fix involving rewriting set_parameter in C++. However,
this one is simpler.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29217
|
|
When building gdb with guile 3.0.8, we run into:
...
gdb/guile/guile.c: In function \
'void gdbscm_initialize(const extension_language_defn*)':
gdb/guile/guile.c:680:5: error: 'scm_install_gmp_memory_functions' is \
deprecated [-Werror=deprecated-declarations]
680 | scm_install_gmp_memory_functions = 0;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/guile/3.0/libguile.h:128,
from gdb/guile/guile-internal.h:30,
from gdb/guile/guile.c:36:
/usr/include/guile/3.0/libguile/deprecated.h:164:20: note: declared here
164 | SCM_DEPRECATED int scm_install_gmp_memory_functions;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1896: guile/guile.o] Error 1
...
The variable has been deprecated because it no longer has any effect.
Fix this by disabling the specific deprecation warning.
Also handle upcoming guile versions > 3.0, in which the variable will be
removed, by limiting the usage of the variable to guile versions <= 3.0.
This does not break anything. The variable was merely used to address a
problem present in guile versions <= v3.0.5.
Note that we don't limit the usage of the variable to guile versions <= 3.0.5,
because we want to support f.i. building against 3.0.6 and then using a shared
lib with 3.0.5.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28994
|
|
When running test-case gdb.dwarf2/dw2-symtab-includes.exp with target board
cc-with-debug-names, I run into:
...
(gdb) maint expand-symtab dw2-symtab-includes.h^M
src/gdb/dwarf2/read.h:311: internal-error: unit_type: \
Assertion `m_unit_type != 0' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
----- Backtrace -----^M
FAIL: gdb.dwarf2/dw2-symtab-includes.exp: maint expand-symtab \
dw2-symtab-includes.h (GDB internal error)
...
The assert was recently added in commit 2c474c46943 ("[gdb/symtab] Add get/set
functions for per_cu->lang/unit_type").
The assert is triggered here:
...
/* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
into another compilation unit, at root level. Regard this as a hint,
and ignore it. */
if (die->parent && die->parent->parent == NULL
&& per_cu->unit_type () == DW_UT_compile
&& per_cu->lang () == language_cplus)
return;
...
We're trying to access unit_type / lang which hasn't been set yet.
Normally, these are set during cooked index creation, but that's not the case
when using an index (or using -readnow).
In other words, this lto binary reading speed optimization only works in the
normal use case.
IWBN to have this working in all use cases, but for now, allow lang () and
unit_type () to return language_unknown and 0 here.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29321
|
|
When running test-case gdb.cp/cpexprs-debug-types.exp with target board
cc-with-debug-names, I run into:
...
(gdb) print base::operator new^M
^M
^M
Fatal signal: Segmentation fault^M
----- Backtrace -----^M
0x57ea46 gdb_internal_backtrace_1^M
/home/vries/gdb_versions/devel/src/gdb/bt-utils.c:122^M
0x57eae9 _Z22gdb_internal_backtracev^M
/home/vries/gdb_versions/devel/src/gdb/bt-utils.c:168^M
0x75b8ad handle_fatal_signal^M
/home/vries/gdb_versions/devel/src/gdb/event-top.c:946^M
0x75ba19 handle_sigsegv^M
/home/vries/gdb_versions/devel/src/gdb/event-top.c:1019^M
0x7f795f46a8bf ???^M
0x6d3cb1 _ZNK18dwarf2_per_objfile12symtab_set_pEPK18dwarf2_per_cu_data^M
/home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:1515^M
...
The problem is in this piece of code in dw2_debug_names_iterator::next:
...
case DW_IDX_type_unit:
/* Don't crash on bad data. */
if (ull >= per_bfd->tu_stats.nr_tus)
{
complaint (_(".debug_names entry has bad TU index %s"
" [in module %s]"),
pulongest (ull),
objfile_name (objfile));
continue;
}
per_cu = per_bfd->get_cu (ull + per_bfd->tu_stats.nr_tus);
break;
...
The all_comp_units vector (which get_cu accesses) contains both CUs and TUs,
with CUs first.
So to get the nth TU we need the element at "nr_cus + n", but
the code uses "nr_tus + n" instead.
Fix this by using "nr_cus + n".
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29334
|
|
On a machine with gcc 12, I get this warning:
CXX nat/linux-btrace.o
In function ‘btrace_error linux_read_bts(btrace_data_bts*, btrace_target_info*, btrace_read_type)’,
inlined from ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’ at ../gdb/nat/linux-btrace.c:935:29:
../gdb/nat/linux-btrace.c:865:21: warning: ‘data_head’ may be used uninitialized [-Wmaybe-uninitialized]
865 | pevent->last_head = data_head;
| ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
../gdb/nat/linux-btrace.c: In function ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’:
../gdb/nat/linux-btrace.c:792:9: note: ‘data_head’ was declared here
792 | __u64 data_head, data_tail;
| ^~~~~~~~~
Fix this by initializing the 'data_head' variable.
Tested by rebuilding on x86_64 openSUSE Tumbleweed with gcc 12.
|
|
Trying to run a simple program (empty main) on AIX, I get:
(gdb) run
Starting program: /scratch/simark/build/gdb/a.out
Child process unexpectedly missing: There are no child processes..
../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x10ef12a8 gdb_internal_backtrace_1()
../../src/binutils-gdb/gdb/bt-utils.c:122
0x10ef1470 gdb_internal_backtrace()
../../src/binutils-gdb/gdb/bt-utils.c:168
0x1004d368 internal_vproblem(internal_problem*, char const*, int, char const*, char*)
../../src/binutils-gdb/gdb/utils.c:396
0x1004d8a8 internal_verror(char const*, int, char const*, char*)
../../src/binutils-gdb/gdb/utils.c:476
0x1004c424 internal_error(char const*, int, char const*, ...)
../../src/binutils-gdb/gdbsupport/errors.cc:55
0x102ab344 find_inferior_pid(process_stratum_target*, int)
../../src/binutils-gdb/gdb/inferior.c:304
0x102ab4a4 find_inferior_ptid(process_stratum_target*, ptid_t)
../../src/binutils-gdb/gdb/inferior.c:318
0x1061bae8 find_thread_ptid(process_stratum_target*, ptid_t)
../../src/binutils-gdb/gdb/thread.c:519
0x10319e98 handle_inferior_event(execution_control_state*)
../../src/binutils-gdb/gdb/infrun.c:5532
0x10315544 fetch_inferior_event()
../../src/binutils-gdb/gdb/infrun.c:4221
0x10952e34 inferior_event_handler(inferior_event_type)
../../src/binutils-gdb/gdb/inf-loop.c:41
0x1032640c infrun_async_inferior_event_handler(void*)
../../src/binutils-gdb/gdb/infrun.c:9548
0x10673188 check_async_event_handlers()
../../src/binutils-gdb/gdb/async-event.c:335
0x1066fce4 gdb_do_one_event()
../../src/binutils-gdb/gdbsupport/event-loop.cc:214
0x10001a94 start_event_loop()
../../src/binutils-gdb/gdb/main.c:411
0x10001ca0 captured_command_loop()
../../src/binutils-gdb/gdb/main.c:471
0x10003d74 captured_main(void*)
../../src/binutils-gdb/gdb/main.c:1329
0x10003e48 gdb_main(captured_main_args*)
../../src/binutils-gdb/gdb/main.c:1344
0x10000744 main
../../src/binutils-gdb/gdb/gdb.c:32
---------------------
../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This is due to some bit-rot in the AIX port, still relying on the entry
value of inferior_ptid in the wait methods.
Problem #1 is in rs6000_nat_target::wait, here:
/* Ignore terminated detached child processes. */
if (!WIFSTOPPED (status) && pid != inferior_ptid.pid ())
pid = -1;
At this point, waitpid has returned an "exited" status for some pid, so
pid is non-zero. Since inferior_ptid is set to null_ptid on entry, the
pid returned by wait is not equal to `inferior_ptid.pid ()`, so we reset
pid to -1 and go to waiting again. Since there are not more children to
wait for, waitpid then returns -1 so we get here:
if (pid == -1)
{
gdb_printf (gdb_stderr,
_("Child process unexpectedly missing: %s.\n"),
safe_strerror (save_errno));
/* Claim it exited with unknown signal. */
ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN);
return inferior_ptid;
}
We therefore return a "signalled" status with a null_ptid (again,
inferior_ptid is null_ptid). This confuses infrun, because if the
target returns a "signalled" status, it should be coupled with a ptid
for an inferior that exists.
So, the first step is to fix the snippets above to not use
inferior_ptid. In the first snippet, use find_inferior_pid to see if
we know the event process. If there is no inferior with that pid, we
assume it's a detached child process to we ignore the event. That
should be enough to fix the problem, because it should make it so we
won't go into the second snippet. But still, fix the second snippet to
return an "ignore" status. This is copied from inf_ptrace_target::wait,
which is where rs6000_nat_target::wait appears to be copied from in the
first place.
These changes, are not sufficient, as the aix_thread_target, which sits
on top of rs6000_nat_target, also relies on inferior_ptid.
aix_thread_target::wait, by calling pd_update, assumes that
rs6000_nat_target has set inferior_ptid to the appropriate value (the
ptid of the event thread), but that's not the case. pd_update
returns inferior_ptid - null_ptid - and therefore
aix_thread_target::wait returns null_ptid too, and we still hit the
assert shown above.
Fix this by changing pd_activate, pd_update, sync_threadlists and
get_signaled_thread to all avoid using inferior_ptid. Instead, they
accept as a parameter the pid of the process we are working on.
With this patch, I am able to run the program to completion:
(gdb) r
Starting program: /scratch/simark/build/gdb/a.out
[Inferior 1 (process 11010794) exited normally]
As well as break on main:
(gdb) b main
Breakpoint 1 at 0x1000036c
(gdb) r
Starting program: /scratch/simark/build/gdb/a.out
Breakpoint 1, 0x1000036c in main ()
(gdb) c
Continuing.
[Inferior 1 (process 26083688) exited normally]
Change-Id: I7c2613bbefe487d75fa1a0c0994423471d961ee9
|
|
The DWARF spec says:
Any debugging information entry representing the declaration of an object,
module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
DW_AT_decl_column attributes, each of whose value is an unsigned integer
^^^^^^^^
constant.
Grepping around the DWARF-assembler-based testcases, I noticed that
gdb.trace/unavailable-dwarf-piece.exp emits decl_line with
DW_FORM_sdata, a signed integer form. This commit tweaks it to use
DW_FORM_udata instead.
Unsurprisingly, this:
$ make check \
TESTS="gdb.trace/unavailable-dwarf-piece.exp" \
RUNTESTFLAGS="--target_board=native-gdbserver"
... still passes cleanly for me after this change.
I've noticed this because current llvm-dwarfdump crashed on an
ROCm-internal DWARF-assembler-based testcase that incorrectly used
signed forms for DW_AT_decl_file/DW_AT_decl_line.
The older llvm-dwarfdump found on Ubuntu 20.04 (LLVM 10) reads the
line numbers with signed forms as "0" instead of crashing. Here's the
before/after fix for gdb.trace/unavailable-dwarf-piece.exp with that
llvm-dwarfdump version:
$ diff -up before.txt after.txt
--- before.txt 2022-07-07 13:21:28.387690334 +0100
+++ after.txt 2022-07-07 13:21:39.379801092 +0100
@@ -18,7 +18,7 @@
DW_AT_name ("s")
DW_AT_byte_size (3)
DW_AT_decl_file (0)
- DW_AT_decl_line (0)
+ DW_AT_decl_line (1)
0x0000002f: DW_TAG_member
DW_AT_name ("a")
@@ -41,7 +41,7 @@
DW_AT_name ("t")
DW_AT_byte_size (3)
DW_AT_decl_file (0)
- DW_AT_decl_line (0)
+ DW_AT_decl_line (1)
0x00000054: DW_TAG_member
DW_AT_name ("a")
Change-Id: I5c866946356da421ff944019d0eca2607b2b738f
|
|
"it’s" should be "it's".
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
We currently have no coverage for the `print -elements ...' command (or
`p -elements ...' in the shortened form), so add a couple of test cases
mimicking ones using corresponding `set print elements ...' values.
|
|
According to "Procedure Calling Convention" in "LoongArch ELF ABI
specification" [1], implement the push_dummy_call gdbarch method
as clear as possible.
[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_procedure_calling_convention
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
When running the test-case included with this patch, we run into:
...
(gdb) print ptm^M
$1 = gdb/gdbtypes.h:695: internal-error: loc_bitpos: \
Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.^M
...
while printing a c++ pointer-to-member.
Fix this by skipping static fields in cp_find_class_member, such that we have:
...
(gdb) print ptm^M
$1 = &A::i^M
...
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29294
|
|
Sometimes an objfile comes from memory and not from a file. It can be
useful to be able to check this from Python, so this patch adds a new
"is_file" attribute.
|
|
Pierre-Marie noticed that, while gdb.events is a Python module, it
can't be imported. This patch changes how this module is created, so
that it can be imported, while also ensuring that the module is always
visible, just as it was in the past.
This new approach required one non-obvious change -- when running
gdb.base/warning.exp, where --data-directory is intentionally not
found, the event registries can now be nullptr. Consequently, this
patch probably also requires
https://sourceware.org/pipermail/gdb-patches/2022-June/189796.html
Note that this patch obsoletes
https://sourceware.org/pipermail/gdb-patches/2022-June/189797.html
|
|
The basic support for LoongArch has been merged into the upstream Linux
kernel since 5.19-rc1 on June 5, 2022. This commit adds orig_a0 which
is added into struct user_pt_regs [1] to match the upstream kernel, and
then the upstream GDB will work with the upstream kernel.
Note that orig_a0 was added into struct user_pt_regs in the development
cycle for merging LoongArch port into the upstream Linux kernel, so
earlier kernels (notably, the product kernel with version 4.19 used in
distros like UOS and Loongnix) don't have it. Inspect
arch/loongarch/include/uapi/asm/ptrace.h in the kernel tree to make sure.
To build upstream GDB for a kernel lacking orig_a0, it's necessary to
revert this commit locally.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h#n24
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
The dwarf2_per_cu_data fields lang and unit_type both have a dont-know
initial value (respectively language_unknown and (dwarf_unit_type)0), which
allows us to add certain checks, f.i. checking that that a field is not read
before written.
Add get/set member functions for the two fields as a convenient location to
add such checks, make the fields private to enforce using the member
functions, and add the m_ prefix.
Tested on x86_64-linux.
|
|
When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main
thread in the same write:
...
Write of size 1 at 0x7b200000300c:^M
#0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \
(gdb+0x82f3b3)^M
...
which is here:
...
this_cu->dwarf_version = cu->header.version;
...
Both writes are called from the parallel for in dwarf2_build_psymtabs_hard,
this one directly:
...
#1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M
#2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
#3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M
...
and this via the PU import:
...
#1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \
sect_offset, bool, bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M
#2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \
abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M
#3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \
cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M
#4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \
(gdb+0x85e68a)^M
#5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M
#6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
#7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M
...
Fix this by setting the field earlier, in read_comp_units_from_section.
The write in cutu_reader::cutu_reader() is still needed, in case
read_comp_units_from_section is not used (run the test-case with say, target
board cc-with-gdb-index).
Make the write conditional, such that it doesn't trigger if the field is
already set by read_comp_units_from_section. Instead, verify that the
field already has the value that we're trying to set it to.
Move this logic into into a member function set_version (in analogy to the
already present member function version) to make sure it's used consistenly,
and make the field private in order to enforce access through the member
functions, and rename it to m_dwarf_version.
While we're at it, make sure that the version is set before read, to avoid
say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".
Tested on x86_64-linux.
|
|
When building gdb with -fsanitize=thread, I run into:
...
FAIL: gdb.base/early-init-file.exp: check startup version string has style \
version
...
due to this:
...
warning: Found custom handler for signal 7 (Bus error) preinstalled.^M
warning: Found custom handler for signal 8 (Floating point exception) \
preinstalled.^M
warning: Found custom handler for signal 11 (Segmentation fault) \
preinstalled.^M
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M
won't be propagated to spawned programs.^M
...
appearing before the "GNU gdb (GDB) $version" line.
This is similar to the problem fixed by commit f0bbba7886f
("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with
AddressSanitizer").
In that commit, the problem was fixed by starting gdb with -quiet, but using
that would mean the "GNU gdb (GDB) $version" line that we're trying to check
would disappear.
Fix this instead by updating the regexp to allow the message.
Tested on x86_64-linux.
|
|
Remove indentation from the text of the manual after the example here:
" Completion will in some cases guide you with a suggestion of what
kind of argument an option expects. For example:
(gdb) print -elements <TAB><TAB>
NUMBER unlimited
Here, the option expects a number (e.g., '100'), not literal
'NUMBER'. Such metasyntactical arguments are always presented in
uppercase."
as this is a continuation of the same paragraph.
|
|
Completion results are usually different when the operation is applied
to a word that is or is not followed by a space. In some cases they are
equivalent, however a space would not be produced if completion was used
earlier on in the word processed.
However in the manual we have completion examples given using a space
that actually prevents the example from working. E.g.:
(gdb) info bre <TAB>
(nothing) and:
(gdb) info bre <TAB><TAB>
Display all 200 possibilities? (y or n)
as it now goes on to propose the entire symbol table, while:
(gdb) info bre<TAB>
(gdb) info breakpoints
does the right thing, but is not what is shown in the manual.
In other cases an extraneous space is used that does not correspond to
the actual completion pattern shown, which gives an impression of
sloppiness.
Remove extraneous spaces then from completion examples as appropriate.
|
|
Fix a completion consistency issue with `set' commands accepting integer
values and the special `unlimited' keyword:
(gdb) complete print -elements
print -elements NUMBER
print -elements unlimited
(gdb)
vs:
(gdb) complete set print elements
set print elements unlimited
(gdb)
(there is a space entered at the end of both commands, not shown here)
which also means if you strike <Tab> with `set print elements ' input,
it will, annoyingly, complete to `set print elements unlimited' right
away rather than showing a choice between `NUMBER' and `unlimited'.
Add `NUMBER' then as an available completion for such `set' commands:
(gdb) complete set print elements
set print elements NUMBER
set print elements unlimited
(gdb)
Adjust the testsuite accordingly. Also document the feature in the
Completion section of the manual in addition to the Command Options
section already there.
|
|
When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp
only tested objects allocated on the stack. This commit adds a couple of
dynamic allocations and tests if GDB can stop in it as well.
|
|
In passing I noticed that the column headings for the table of MI
compatibility and breaking changes, were overlapping, at least when
the PDF is generated on my machine.
I propose giving slightly more space to the two version number
columns, this prevents the headers overlapping for me.
|
|
Match the whole error message expected to be given rather than omitting
the part about the "unlimited" keyword. There's no point in omitting
the missing part first, and second with an upcoming change the part in
parentheses will no longer be a fixed string, so doing a full match will
ensure the algorithm correctly builds the message expected here. Also
avoid any wildcard matches.
|
|
With errors given for bad commands such as `set annotate' or `set width'
we produce an extraneous full stop within parentheses:
(gdb) set annotate
Argument required (integer to set it to.).
(gdb) set width
Argument required (integer to set it to, or "unlimited".).
(gdb)
This is grammatically incorrect, so remove the full stop and adjust the
testsuite accordingly.
|
|
Extend the description of the MI command --data-disassemble.
Specifically, expand the description of the 'opcodes' field to explain
how the bytes are formatted.
|
|
The FPCCR.TS bit is used to identify if FPU registers are considered
non-secure or secure. If they are secure, then callee saved registers
(S16 to S31) are stacked on exception entry or otherwise skipped.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
|
|
When running the gdb.base/break-idempotent.exp test on ppc, I was
seeing some test failures (or rather errors), that looked like this:
(gdb) watch local
Hardware watchpoint 2: local
has_hw_wp_support: Hardware watchpoint detected
ERROR: no fileid for gcc2-power8
ERROR: Couldn't send delete breakpoints to GDB.
ERROR OCCURED: can't read "gdb_spawn_id": no such variable
while executing
"expect {
-i 1000 -timeout 100
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_erro..."
("uplevel" body line 1)
invoked from within
What happens is that in break-idempotent.exp we basically do this:
if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} {
continue
}
# ....
if {![skip_hw_watchpoint_tests]} {
test_break $always_inserted "watch"
}
The problem with this is that skip_hw_watchpoint_tests, includes this:
if { [istarget "i?86-*-*"]
|| [istarget "x86_64-*-*"]
|| [istarget "ia64-*-*"]
|| [istarget "arm*-*-*"]
|| [istarget "aarch64*-*-*"]
|| ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support])
|| [istarget "s390*-*-*"] } {
return 0
}
For powerpc only we call has_hw_wp_support. This is a caching proc
that runs a test within GDB to detect if we have hardware watchpoint
support or not.
Unfortunately, to run this test we restart GDB, and when the test has
completed, we exit GDB. This means that in break-idempotent.exp, when
we call skip_hw_watchpoint_tests for the first time on powerpc, GDB
will unexpectedly be exited. When we later call delete_breakpoints we
see the errors I reported above.
The fix is to call skip_hw_watchpoint_tests early, before we start GDB
as part of the break-idempotent.exp script, and store the result in a
variable, we can then check this variable in the script as needed.
After this change break-idempotent.exp runs fine on powerpc.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
|
|
For every stop, Linux GDB and GDBserver save the stopped thread's PC,
in lwp->stop_pc. This is done in save_stop_reason, in both
gdb/linux-nat.c and gdbserver/linux-low.cc. However, while we're
going through the shell after "run", in startup_inferior, we shouldn't
be reading registers, as we haven't yet determined the target's
architecture -- the shell's architecture may not even be the same as
the final inferior's.
In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has
stopped for a breakpoint, and since when going through the shell, no
breakpoint is going to hit, we could simply teach save_stop_reason to
only record the stop pc when the thread stopped for a breakpoint.
However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases
than breakpoint hits (e.g., it's used in tracepoints & the
"while-stepping" feature).
So to avoid GDB vs GDBserver divergence, we apply the same approach to
both implementations.
We set a flag in the inferior (process in GDBserver) whenever it is
being nursed through the shell, and when that flag is set,
save_stop_reason bails out early. While going through the shell,
we'll only ever get process exits (normal or signalled), random
signals, and exec events, so nothing is lost.
Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad
|
|
When building gdb with system gcc 7.5.0, I run into:
...
gdb/ia64-tdep.c: In function ‘int is_float_or_hfa_type_recurse(type*, type**)’:
gdb/ia64-tdep.c:3362:1: error: control reaches end of non-void function \
[-Werror=return-type]
...
This is due to PR gcc/81275 - "-fsanitize=thread produce incorrect
-Wreturn-type warning", which has been fixed in gcc-8.
Work around this by moving the default return outside the switch.
Tested on x86_64-linux.
|
|
In the existing CSKY architecture, there are at most 32 floating
and 16 vector registers. Float registers's count can be configured
as 16 or 32. In the future, the vector registers's count may be
extended to 32.
The bit width of floating-point register is 64bits, and the bit
width of vector register is 128bit.
Special points: in fr0~fr15 and vr0~vr15, each FRx is the lower
64 bits of the corresponding VRx.
Here, we will split each floating-point and vector register to
32bits wide, add the corresponding pseudo registers, and finally
use them for the dwarf registers.
There are 128 pseudo registers in total, s0~s127, including:
1. s0 and s1 correspond to fr0, s4 and s5 correspond to fr1, and so on.
Every two separated pseudo registers correspond to a float register.
2. s0, s1, s2 and s3 correspond to vr0; s4, s5, s6 and s7 correspond to vr1,
and so on. Every four pseudo registers corresponds to a vector register.
Therefore, in s64~s127, there are general registers that are not actually
used. This part is to prepare for the expansion of vector registers to 32
Therefore, in s64~s127, half of the registers are actually unused. This
part is to prepare for the expansion of the vector register to 32.
|
|
Some tests link to outdated bug numbers when an XFAIL or a KFAIL happen.
gdb.base/macscp.exp was referencing bug number 555, and the bug 7660
mentions that it used to be 555 on the Gnats system and seems to relate
to the issue at hand.
gdb.base/annota1.exp was referencing bug number 1270, and bug 8375
mentions being number 1270 on Gnats, and mentions annota1 specifically,
so it seemed pretty obvious.
|
|
Without this changeset, the unwinding doesn't take into account
Non-Secure to Secure stack unwinding enablement status and
doesn't choose the proper SP to do the unwinding.
This patch only unwinds the stack when Non-Secure to Secure
unwinding is enabled, previous SP is set w/r to the current mode
(Handler -> msp_s, Thread -> psp_s) and then the Secure stack is
unwound. Ensure thumb bit is set in PSR when needed. Also, drop
thumb bit from PC if set.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan ROUX <yvan.roux@foss.st.com>
|
|
With python 3.4, I run into:
...
Traceback (most recent call last):^M
File "<string>", line 1, in <module>^M
File
"outputs/gdb.python/py-send-packet/py-send-packet.py", line 128, in \
run_set_global_var_test^M
res = conn.send_packet(b"X%x,4:\x02\x02\x02\x02" % addr)^M
TypeError: Could not convert Python object: b'X%x,4:\x02\x02\x02\x02'.^M
Error while executing Python code.^M
...
while with python 3.6 this works fine.
The type of addr is <class 'gdb.Value'>, so the first thing to try is whether
changing it into a string works:
...
addr_str = "%x" % addr
res = conn.send_packet(b"X%s,4:\x02\x02\x02\x02" % addr_str)
...
which gets us the more detailed:
...
TypeError: unsupported operand type(s) for %: 'bytes' and 'str'
...
Fix this by avoiding the '%' operator in the byte literal, and use instead:
...
def xpacket_header (addr):
return ("X%x,4:" % addr).encode('ascii')
...
res = conn.send_packet(xpacket_header(addr) + b"\x02\x02\x02\x02")
...
Tested on x86_64-linux, with python 3.4 and 3.6, and a backported version was
tested on the gdb-12-branch in combination with python 2.7.
|
