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.
Commit 736918239b ("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>
Cleaning up the subsym_hash memory is a real pain. Keys and values
entered into the table are quite diverse. In some cases the key is
allocated and thus needs to be freed, in others the key is a const
string. Values are similar, and in some cases not even a string.
Tidy this by inserting a new subsym_ent_t that describes key/value
type. This meant the math_hash table was no longer needed. The patch
also tidies how math functions are called, those that are supposed to
return int now no longer return their value in a float.
* config/tc-tic54x.c (math_hash): Delete.
(subsym_proc_entry): Move earlier, make proc a union, merge with..
(math_proc_entry): ..this. Delete type.
(math_procs): Merge into subsym_procs.
(subsym_ent_t): New. Use this type in subsym_hash..
(stag_add_field_symbols, tic54x_var, tic54x_macro_info): ..here..
(md_begin, subsym_create_or_replace, subsym_lookup): ..and here..
(subsym_substitute): ..and here. Adjust subsym_proc_entry
function calls. Free replacement when not returned.
(subsym_get_arg): Adjust subsym_lookup.
(free_subsym_ent, subsym_htab_create ): New functions, use when
creating subsym_hash.
(free_local_label_ent, local_label_htab_create): Similarly.
(tic54x_remove_local_label): Delete.
(tic54x_clear_local_labels): Simplify.
(tic54x_asg): Use notes obstack to dup strings.
(tic54x_eval): Likewise.
(subsym_ismember): Likewise.
(math_cvi, math_int, math_sgn): Return int.
(tic54x_macro_start): Decrement macro_level before calling as_fatal.
(tic54x_md_end): New function.
* config/tc-tic54h.c (tic54x_md_end): Declare.
(md_end): Define.
Using notes_calloc means all of the string hash table memory should
now be freed before gas exits, even though htab_delete isn't called.
This also means that the hash table free_f and del_f must be NULL,
because freeing notes obstack memory results in all more recently
allocated notes memory being freed too. So hash table resizing won't
free any memory, and will be a little faster. Also, htab_delete won't
do anything (and be quick about it).
Since htab_traverse can also resize hash tables (to make another
traversal faster if the table is largely empty), stop that happening
when only one traversal is done.
* as.h: Reorder hash.h after symbols.h for notes_calloc decl.
* hash.h (str_htab_create): Use notes_calloc. Do not free.
* symbols.c (resolve_local_symbol_values): Don't resize
during hash table traversal.
* config/obj-elf.c (elf_frob_file_after_relocs): Likewise.
* config/tc-ia64.c (ia64_adjust_symtab, ia64_frob_file): Likewise.
* config/tc-nds32.c (nds32_elf_analysis_relax_hint): Likewise.
This allocates entries added to the string hash tables on the notes
obstack, so that at least those do not leak. A followup patch will
switch over the str_hash allocation to notes_calloc, which is why I
haven't implemented deleting all the target string hash tables.
* config/obj-coff-seh.c (get_pxdata_name, alloc_pxdata_item): Use
notes obstack for string hash table entries.
* config/tc-alpha.c (get_alpha_reloc_tag, md_begin): Likewise.
* config/tc-h8300.c (md_begin): Likewise.
* config/tc-ia64.c (dot_rot, dot_pred_rel, dot_alias): Likewise.
* config/tc-nds32.c (nds32_relax_hint): Likewise.
* config/tc-riscv.c (riscv_init_csr_hash): Likewise.
* config/tc-score.c (s3_insert_reg): Likewise.
(s3_build_score_ops_hsh, s3_build_dependency_insn_hsh): Likewise.
* config/tc-score7.c (s7_build_score_ops_hsh): Likewise.
(s7_build_dependency_insn_hsh): Likewise.
* config/tc-tic4x.c (tic4x_asg): Likewise.
The arc opcode hash table has entries that have a realloc'd field.
This doesn't lend itself to obstack allocation, so freeing must be
done with a purpose built hashtab del_f.
* config/tc-arc.c (arc_opcode_free): New function.
(md_begin): Pass the above as del_f to htab_create_alloc.
(arc_md_end): New function.
* config/tc-arc.h (arc_md_end): Declare.
(md_end): Define.
This tidies memory used by the two x86 gas string hash tables before
exiting. I'm using a two-pronged approach, firstly the obvious call
to htab_delete plus telling the libiberty/hashtab.c infrastructure to
free tuples generated by str_hash_insert, and secondly putting the x86
core_optab memory on the notes obstack. It would be possible to free
core_optab memory by using a custom hash table del_f on x86, as I do
for arc, but a later patch will move all the string hash memory to the
notes obstack.
* config/tc-i386.c (md_begin): Use notes_alloc for core_optab.
(386_md_end): New function.
* config/tc-i386.h (386_md_end): Declare.
(md_end): Define.
* hash.h (str_htab_create): Pass free as del_f.
Only inline functions should be defined in hash.h, there's no benefit
in having multiple copies of hash_string_tuple and eq_string_tuple.
Also, use the table alloc_f when allocating tuples to be stored, so
that these functions are usable with different memory allocation
strategies.
* hash.h (struct string_tuple, string_tuple_t): Move earlier.
(string_tuple_alloc): Add table param, allocate using table alloc_f.
(str_hash_insert): Adjust to suit. Call table->free_f when
entry is not used.
(hash_string_tuple, eq_string_tuple): Move to..
* hash.c: ..here.
Currently md_end is typically used for some final actions rather than
freeing memory like other *_end functions. Rename it to md_finish,
and rename target implementation. The renaming of target functions
makes it possible to find them all with "grep md_finish",
eg. md_mips_end is renamed to mips_md_finish, not md_mips_finish.
This patch leaves a number of md_end functions unchanged, those that
either do nothing or deallocate memory, and calls them late.
The idea here is that target maintainers implement md_end functions to
tidy memory, if anyone cares. Freeing persistent memory in gas is
not at all important, except that it can hide more important memory
leaks, those that happen once per some frequent gas operation, amongst
these unimportant memory leaks.
* as.c (main): Rename md_end to md_finish.
* config/tc-alpha.c, * config/tc-alpha.h,
* config/tc-arc.c, * config/tc-arc.h,
* config/tc-arm.c, * config/tc-arm.h,
* config/tc-csky.c, * config/tc-csky.h,
* config/tc-ia64.c, * config/tc-ia64.h,
* config/tc-mcore.c, * config/tc-mcore.h,
* config/tc-mips.c, * config/tc-mips.h,
* config/tc-mmix.c, * config/tc-mmix.h,
* config/tc-msp430.c, * config/tc-msp430.h,
* config/tc-nds32.c, * config/tc-nds32.h,
* config/tc-ppc.c, * config/tc-ppc.h,
* config/tc-pru.c, * config/tc-pru.h,
* config/tc-riscv.c, * config/tc-riscv.h,
* config/tc-s390.c, * config/tc-s390.h,
* config/tc-sparc.c, * config/tc-sparc.h,
* config/tc-tic4x.c, * config/tc-tic4x.h,
* config/tc-tic6x.c, * config/tc-tic6x.h,
* config/tc-v850.c, * config/tc-v850.h,
* config/tc-xtensa.c, * config/tc-xtensa.h,
* config/tc-z80.c, * config/tc-z80.h: Similarly.
* output-file.c (output_file_close): Call md_end.
So that the notes obstack can be used for persistent storage in
parse_args.
* as.c (parse_args): Use notes_alloc and notes_strdup.
(free_notes): New function.
(main): Init notes obstack, and arrange to be freed on exit.
* read.c (read_begin): Don't init notes obstack.
(read_end): Free cond_obstack.
* subsegs.c (subsegs_end): Don't free cond_obstack or notes.
itbl_files seems to be debug code. Get rid of it.
* as.c (struct itbl_file_list): Delete.
(itbl_files): Delete.
(parse_args): Don't keep itbl_files list.
Use notes obstack for dwcfi_hash entries, and free table. Freeing the
table makes memory checkers complain more about "definitely lost"
memory as we've moved some from the "still reachable" category.
That will be fixed with a later patch.
* dw2gencfi.c (get_debugseg_name): Allocate on notes obstack.
(alloc_debugseg_item): Likewise.
(dwcfi_hash_find_or_make): Adjust failure path free.
(cfi_finish): Delete dwfci_hash.
Another case of duplicated hash.h code, the only minor difference
being that macro->format_hash was created with 7 entries vs. str_hash
with 16 entries.
* macro.c (macro_init, define_macro): Use str_htab_create.
(do_formals, define_macro, macro_expand_body): Use str_hash_insert
(macro_expand_body): Use str_hash_find and str_hash_delete.
(delete_macro): Likewise.
(sub_actual, macro_expand, check_macro): Use str_hash_find.
(expand_irp): Use str_htab_create and str_hash_insert.
* macro.h (struct macro_struct): Tidy.
(struct macro_hash_entry, macro_hash_entry_t, hash_macro_entry),
(eq_macro_entry, macro_entry_alloc, macro_entry_find),
(struct formal_hash_entry, formal_hash_entry_t),
(hash_formal_entry, eq_formal_entry, formal_entry_alloc),
(formal_entry_find): Delete.
* config/tc-iq2000.c (iq2000_add_macro): Use str_htab_create
and str_hash_insert.
po_hash code duplicates the str_hash code in hash.h for no good reason.
* read.c (struct po_entry, po_entry_t): Delete.
(hash_po_entry, eq_po_entry, po_entry_alloc, po_entry_find): Delete.
(pop_insert): Use str_hash_insert.
(pobegin): Use str_htab_create.
(read_a_source_file, s_macro): Use str_hash_find.
read_symbol_name mallocs the string it returns. Free it when done.
* read.c (read_symbol_name): Free name on error path.
* config/tc-ppc.c (ppc_GNU_visibility): Free name returned from
read_symbol_name.
(ppc_extern, ppc_globl, ppc_weak): Likewise.
This is mostly a tidy with the aim of being able to free
out_file_name, but it does fix a possible attempt to unlink the output
file twice (not that that matters).
* as.h (keep_it): New global.
* as.c (keep_it): Delete.
(close_output_file): Delete, merged into..
* output-file.c (output_file_close): ..here. Delete parameter.
* output-file.h (output_file_close): Update prototype.
Makes it a little easier to use the notes obstack for persistent
storage.
* as.h (gas_mul_overflow): Define.
* symbols.h (notes_alloc, notes_calloc, notes_memdup),
(notes_strdup, notes_concat, notes_free): Declare.
* symbols.c (notes_alloc, notes_calloc, notes_memdup),
(notes_strdup, notes_concat, notes_free): New functions.
(save_symbol_name): Use notes_strdup.
(symbol_create, local_symbol_make, local_symbol_convert),
(symbol_clone, decode_local_label_name): Use notes_alloc.
arm gas is only supposed to warn once per symbol for -mwarn-syms, but
doesn't because the str_hash_find added with commit 629310abec
always returns NULL. That's so because the str_hash_insert inserts a
NULL value for the key,value pair. Let str_hash_insert do the job
instead.
* config/tc-arm.c (arm_tc_equal_in_insn): Correct already_warned
logic.
* testsuite/gas/arm/pr18347.s: Modify to generate duplicate
warning without this patch.
Until we update the recommended versions of autoconf/automake, files
should be regenerated with automake-1.15.1 and autoconf-2.69. That's
not because we think those versions are golden, and newer versions are
bad. It's simply because maintainers want to be able to update
configury files without trouble, and if someone regenerates files with
automake-1.16.5 then --enable-maintainer-mode builds will hit errors:
checking that generated files are newer than configure... configure.ac:26: error: version mismatch. This is Automake 1.15.1,
configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:26: comes from Automake 1.16.5. You should recreate
configure.ac:26: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.15' is probably too old.
Correcting this requires regenerating the files by hand.
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 2c474c4694 ("[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.
This commit adds disassembler style to the libopcodes s390
disassembler. This conversion was pretty straight forward, I just
converted the fprintf_func calls to fprintf_styled_func calls and
added an appropriate style.
For testing the new styling I just assembled then disassembled the
source files in gas/testsuite/gas/s390 and manually checked that the
styling looked reasonable.
If the user does not request styled output from objdump, then there
should be no change in the disassembler output after this commit.
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
