In microblaze_analyze_prologue in gdb/microblaze-tdep.c I came across:
...
microblaze_debug ("got addi r1,r1,%d; contnuing\n", imm);
...
Fix this by using "continuing".
Reviewed-By: Tom Tromey <tom@tromey.com>
In gdb/python/py-value.c, in the value_object_methods array I noticed:
...
{ "const_value", valpy_const_value, METH_NOARGS,
"Return a 'const' qualied version of the same value." },
...
Fix the qualied -> qualified typo.
Reviewed-By: Tom Tromey <tom@tromey.com>
In gdb/guile/scm-value.c, I noticed in the value_functions array initializer:
...
{ "value-optimized-out?", 1, 0, 0,
as_a_scm_t_subr (gdbscm_value_optimized_out_p),
"\
Return #t if the value has been optimizd out." },
...
There's a typo in the doc string.
Fix this by using "optimized".
Reviewed-By: Tom Tromey <tom@tromey.com>
I noticed:
...
(gdb) help show tui tab-width
Show the tab witdh, in characters, for the TUI.
This variable controls how many spaces are used to display a tab character.
...
a typo: "witdh".
Fix this by using "width" instead.
Reviewed-By: Tom Tromey <tom@tromey.com>
I noticed a typo:
...
(gdb) help maint info target-sections
List GDB's internal section table.
Print the current targets section list. This is a sub-set of all
sections, from all objects currently loaded. Usually the ALLOC
sectoins.
...
Fix this by using "sections".
Reviewed-By: Tom Tromey <tom@tromey.com>
I noticed here:
...
(gdb) help maint set ignore-prologue-end-flag
Set if the PROLOGUE-END flag is ignored.
The PROLOGUE-END flag from the line-table entries is used to place \
breakpoints past the prologue of functions. Disabeling its use use forces \
the use of prologue scanners.
...
a typo in "Disabeling" and accidental word repetition "use use".
Fix by replacing with "Disabling" and "use".
Reviewed-By: Tom Tromey <tom@tromey.com>
In compile_object_load in gdb/compile/compile-object-load.c I came across:
...
"Connectiong ELF symbol \"%s\" to the .toc section (%s)\n",
...
Fix this typo by using "Connecting" instead.
Reviewed-By: Tom Tromey <tom@tromey.com>
I noticed in emit_ops_insns in gdbserver/linux-aarch64-low.cc:
...
threads_debug_printf ("Adding %d instrucions at %s",
...
Fix the typo by using "instructions" instead.
Reviewed-By: Tom Tromey <tom@tromey.com>
Two functions use the argument name bounds_prefered_p.
This misspells "preferred".
Fix this by using bounds_preferred_p instead.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Yet another fuzzer fix.
* ecoff.c (ecoff_slurp_symbolic_header <FIX>): Zero counts when
associated pointer is zero.
(_bfd_ecoff_slurp_symbolic_info): Remove now unnecessary check.
Caught this during emulator testing.
Fix the constants. They should be 0xa and 0xb as opposed to 0x10 and
0x11. There was a thinko while defining them.
Obvious enough.
Tested on aarch64-linux Ubuntu 20.04/22.04.
Another fix for fuzzed object files, exhibiting as a segfault in
nm.c filter_symbols when accessing a symbol name.
* ecoff.c (_bfd_ecoff_slurp_symbol_table): Sanity check
fdr_ptr->issBase, and tighten sym.iss check.
This fixes two buffer overflows found by fuzzers.
* readelf.c (target_specific_reloc_handling): Sanity check
loongarch reloc symbol index. Don't apply reloc after errors.
Reduce translation work of "invalid symbol index" error message.
Define a new constant for the maximum number of stack offsets handled in
libsframe, and use it. Note that the SFrame format does not define such
a constant (limit). This is an implmentation-defined constant in
libsframe.
include/
* sframe-api.h (MAX_NUM_STACK_OFFSETS): New definition.
libsframe/
* sframe.c (sframe_fre_sanity_check_p): Use it.
For TLS GD/IE, add the same condition with the relocate_section in the
allocate_dynrelocs, to make sure we won't reserve redundant spaces
for dynamic relocations since the conservative estimatation.
After applying this patch, ld seems no longer generate the spurious
R_RISCV_NONE for pr22263-1 test, and the test in pr24676.
bfd/
PR ld/22263
PR ld/24676
* elfnn-riscv.c (RISCV_TLS_GD_IE_NEED_DYN_RELOC): New defined.
Set NEED_RELOC to true if TLS GD/IE needs dynamic relocations,
and INDX will be the dynamic index.
(allocate_dynrelocs): Don't reserve extra spaces in the rela.got
if RISCV_TLS_GD_IE_NEED_DYN_RELOC set need_reloc to false. This
condition needs to be same as relocate_section.
(relocate_section): Likewise, use the same condition as
allocate_dynrelocs.
PowerPC64 ELFv1 object files should have at most one .opd section, and
OPD handling in elf64-ppc.c makes use of this fact by caching some
.opd section info in the per-object bfd.tdata. This was done to avoid
another word in the target specific section data. Of course, fuzzers
don't respect the ABI, and even non-malicious users can accidentally
create multiple .opd sections. So it is better to avoid possible
buffer overflows and other confusion when OPD handling for a second
.opd section references data for the first .opd section, by keeping
the data per-section.
The patch also fixes a memory leak, and a corner case where I think we
could hit an assertion in opd_entry_value or read out of bounds in
ppc64_elf_branch_reloc doing a final link producing non-ppc64 output.
(It's a really rare corner case because not only would you need to be
linking ppc64 objects to non-ppc64 output, you'd also need a branch
reloc symbol to be defined in a .opd section of a non-ppc64 input.)
* elf64-ppc.c (is_ppc64_elf): Move earlier in file.
(ppc64_elf_branch_reloc): Check symbol bfd before accessing
ppc64 elf specific data structures.
(struct ppc64_elf_obj_tdata): Move opd union..
(struct _ppc64_elf_section_data): ..to here.
(ppc64_elf_before_check_relocs): Allow for opd sec_type
already set to sec_opd.
(ppc64_elf_check_relocs): Only set sec_type to sec_toc when
unset. Error for unexpected toc relocs.
(opd_entry_value): Return -1 when non-ppc64 rather than
asserting. Check and set sec_type too. Adjust for changed
location of contents and relocs.
(ppc64_elf_relocate_section): Adjust for changed location of
cached .opd relocs.
(ppc64_elf_free_cached_info): New function.
(bfd_elf64_bfd_free_cached_info): Define.
bfd_free_cached_info is used in just one place in archive.c, which
means most times we reach bfd_close the function isn't called. On the
other hand, if bfd_free_cached_info is called we can't do much on the
bfd since it loses all its obj_alloc memory. This restricts what can
be done in a target _close_and_cleanup. In particular you can't look
at sections, which leads to duplication of code in target
close_and_cleanup and free_cached_info, eg. elfnn-aarch64.c.
* opncls.c (_bfd_delete_bfd): Call bfd_free_cached_info.
* elfnn-aarch64.c (elfNN_aarch64_close_and_cleanup): Delete.
(bfd_elfNN_close_and_cleanup): Don't define.
* som.c (som_bfd_free_cached_info): Don't call
_bfd_generic_close_and_cleanup here.
(som_close_and_cleanup): Define as _bfd_generic_close_and_cleanup.
The rs6000 backend can call coff_section_from_bfd_index from its
object_p function via coff_set_alignment_hook. If the object doesn't
match, or another target matches too, then the hash table needs to be
freed via a cleanup.
* coffgen.c (coff_object_cleanup): New function.
(coff_real_object_p): Return coff_object_cleanup, and call on
failure path. Move declaration to..
* libcoff-in.h: ..here.
(coff_object_cleanup): Declare.
* coff-stgo32.c (go32exe_cleanup): Call coff_object_cleanup.
(go32exe_check_format): Adjust assertion.
* libcoff.h: Regenerate.
The assertions in cpu-sh.c can be triggered by passing bogus values
in disassemble_info.mach. This doesn't cause any bfd misbehaviour.
* cpu-sh.c (sh_get_arch_from_bfd_mach): Remove BFD_FAIL.
(sh_get_arch_up_from_bfd_mach): Likewise.
I found the documentation for -dprintf-insert a bit unclear. It
didn't mention the possibility of multiple arguments, and I also
noticed that it implied that the format parameter is optional, which
it is not.
While looking into this I also noticed a few comments in the
implementation that could also be improved.
Then, I noticed a repeated call to strlen in a loop condition, so I
fixed this up as well.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I noticed a couple instance of this warning when rebuilding the gdb
info files:
warning: undefined flag: GDB
The problem is that the wrong argument was passed to @value. This
patch fixes the problem.
When running the test-case gdb.tui/wrap-line.exp with a build configured with
--disable-tui, we run into:
...
(gdb) PASS: gdb.tui/wrap-line.exp: width-hard-coded: set width 50
tui new-layout command-layout cmd 1^M
Undefined command: "tui". Try "help".^M
(gdb) ERROR: Undefined command "tui new-layout command-layout cmd 1".
...
Fix this by guarding the command with allow_tui_tests.
Tested on x86_64-linux.
When running test-case gdb.tui/pr30056.exp with target board
native-extended-gdbserver, I run into:
...
Quit^[[K^M^[[B(gdb) PASS: gdb.tui/pr30056.exp: Control-C
Remote debugging from host ::1, port 38810^M
^M(failed reverse-i-search)`xyz': ^M(gdb) target extended-remote \
localhost:2346^[[7GWARNING: Timed out waiting for EOF in server after \
monitor exit
...
This is due to the fact that ^C doesn't abort the reverse-i-search. This
appears to be due to a readline problem. A PR is open about this: PR
cli/30498.
Add a KFAIL for the PR, and ensure that the isearch is aborted by using ^G,
such that we have a responsive prompt to handle the "monitor exit" command
that native-extended-gdbserver issues.
Tested on x86_64-linux.
PR 30444
* coffcode.h (coff_write_object_contents): Handle base64 encoding on PE. Also check for too large string table.
* coffgen.c (extract_long_section_name): New function extracted from ... (make_a_section_from_file): ... here. Add support for base64 long section names. (decode_base64): New function.
I added a cmd-only layout:
...
(gdb) tui new-layout cmd cmd 1
...
and set it:
...
(gdb) layout cmd
...
which gave me the expect result: only the cmd window in the screen.
However, after going back to layout src:
...
(gdb) layout src
...
I got a source window with only one line in it, and the cmd window taking most
of the screen.
I traced this back to tui_set_layout, where for both the old and the new
layout the fingerprint of the cmd window in the layout is taken. If the
fingerprint is the same, an effort will be done to preserve the command
window size.
The fingerprint is "VC" for both the old (cmd) and new (src) layouts, which
explains the behaviour.
I think this is essentially a bug in the finger print calculation, and it
should be "C" for the cmd layout.
Fix this by not adding a V or H in the fingerprint if the list size is one.
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
This commit adds a new format for the printf and dprintf commands:
'%V'. This new format takes any GDB expression and formats it as a
string, just as GDB would for a 'print' command, e.g.:
(gdb) print a1
$a = {2, 4, 6, 8, 10, 12, 14, 16, 18, 20}
(gdb) printf "%V\n", a1
{2, 4, 6, 8, 10, 12, 14, 16, 18, 20}
(gdb)
It is also possible to pass the same options to %V as you might pass
to the print command, e.g.:
(gdb) print -elements 3 -- a1
$4 = {2, 4, 6...}
(gdb) printf "%V[-elements 3]\n", a1
{2, 4, 6...}
(gdb)
This new feature would effectively replace an existing feature of GDB,
the $_as_string builtin convenience function. However, the
$_as_string function has a few problems which this new feature solves:
1. $_as_string doesn't currently work when the inferior is not
running, e.g:
(gdb) printf "%s", $_as_string(a1)
You can't do that without a process to debug.
(gdb)
The reason for this is that $_as_string returns a value object with
string type. When we try to print this we call value_as_address,
which ends up trying to push the string into the inferior's address
space.
Clearly we could solve this problem, the string data exists in GDB, so
there's no reason why we have to push it into the inferior, but this
is an existing problem that would need solving.
2. $_as_string suffers from the fact that C degrades arrays to
pointers, e.g.:
(gdb) printf "%s\n", $_as_string(a1)
0x404260 <a1>
(gdb)
The implementation of $_as_string is passed a gdb.Value object that is
a pointer, it doesn't understand that it's actually an array. Solving
this would be harder than issue #1 I think. The whole array to
pointer transformation is part of our expression evaluation. And in
most cases this is exactly what we want. It's not clear to me how
we'd (easily) tell GDB that we didn't want this reduction in _some_
cases. But I'm sure this is solvable if we really wanted to.
3. $_as_string is a gdb.Function sub-class, and as such is passed
gdb.Value objects. There's no super convenient way to pass formatting
options to $_as_string. By this I mean that the new %V feature
supports print formatting options. Ideally, we might want to add this
feature to $_as_string, we might imagine it working something like:
(gdb) printf "%s\n", $_as_string(a1,
elements = 3,
array_indexes = True)
where the first item is the value to print, while the remaining
options are the print formatting options. However, this relies on
Python calling syntax, which isn't something that convenience
functions handle. We could possibly rely on strictly positional
arguments, like:
(gdb) printf "%s\n", $_as_string(a1, 3, 1)
But that's clearly terrible as there's far more print formatting
options, and if you needed to set the 9th option you'd need to fill in
all the previous options.
And right now, the only way to pass these options to a gdb.Function is
to have GDB first convert them all into gdb.Value objects, which is
really overkill for what we want.
The new %V format solves all these problems: the string is computed
and printed entirely on the GDB side, we are able to print arrays as
actual arrays rather than pointers, and we can pass named format
arguments.
Finally, the $_as_string is sold in the manual as allowing users to
print the string representation of flag enums, so given:
enum flags
{
FLAG_A = (1 << 0),
FLAG_B = (1 << 1),
FLAG_C = (1 << 1)
};
enum flags ff = FLAG_B;
We can:
(gdb) printf "%s\n", $_as_string(ff)
FLAG_B
This works just fine with %V too:
(gdb) printf "%V\n", ff
FLAG_B
So all functionality of $_as_string is replaced by %V. I'm not
proposing to remove $_as_string, there might be users currently
depending on it, but I am proposing that we don't push $_as_string in
the documentation.
As %V is a feature of printf, GDB's dprintf breakpoints naturally gain
access to this feature too. dprintf breakpoints can be operated in
three different styles 'gdb' (use GDB's printf), 'call' (call a
function in the inferior), or 'agent' (perform the dprintf on the
remote).
The use of '%V' will work just fine when dprintf-style is 'gdb'.
When dprintf-style is 'call' the format string and arguments are
passed to an inferior function (printf by default). In this case GDB
doesn't prevent use of '%V', but the documentation makes it clear that
support for '%V' will depend on the inferior function being called.
I chose this approach because the current implementation doesn't place
any restrictions on the format string when operating in 'call' style.
That is, the user might already be calling a function that supports
custom print format specifiers (maybe including '%V') so, I claim, it
would be wrong to block use of '%V' in this case. The documentation
does make it clear that users shouldn't expect this to "just work"
though.
When dprintf-style is 'agent' then GDB does no support the use of
'%V' (right now). This is handled at the point when GDB tries to
process the format string and send the dprintf command to the remote,
here's an example:
Reading symbols from /tmp/hello.x...
(gdb) dprintf call_me, "%V", a1
Dprintf 1 at 0x401152: file /tmp/hello.c, line 8.
(gdb) set sysroot /
(gdb) target remote | gdbserver --once - /tmp/hello.x
Remote debugging using | gdbserver --once - /tmp/hello.x
stdin/stdout redirected
Process /tmp/hello.x created; pid = 3088822
Remote debugging using stdio
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) set dprintf-style agent
(gdb) c
Continuing.
Unrecognized format specifier 'V' in printf
Command aborted.
(gdb)
This is exactly how GDB would handle any other invalid format
specifier, for example:
Reading symbols from /tmp/hello.x...
(gdb) dprintf call_me, "%Q", a1
Dprintf 1 at 0x401152: file /tmp/hello.c, line 8.
(gdb) set sysroot /
(gdb) target remote | gdbserver --once - /tmp/hello.x
Remote debugging using | gdbserver --once - /tmp/hello.x
stdin/stdout redirected
Process /tmp/hello.x created; pid = 3089193
Remote debugging using stdio
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) set dprintf-style agent
(gdb) c
Continuing.
Unrecognized format specifier 'Q' in printf
Command aborted.
(gdb)
The error message isn't the greatest, but improving that can be put
off for another day I hope.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Same idea as previous patches, but for about_to_proceed. We only need
(and want, as far as the mi_interp implementation is concerned) to
notify the interpreter that caused the proceed.
Change-Id: Id259bca10dbc3d43d46607ff7b95243a9cbe2f89
