| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The md_pre_output_hook creating fixup is asynchronous, causing relocs
may be out of order in .eh_frame. Define GAS_SORT_RELOCS so that reorder
relocs when write_relocs.
Reported-by: Rui Ueyama <rui314@gmail.com>
|
|
Now that CpuLM is used solely in cpu_arch_flags and cpu_arch[] while
Cpu64 is solely used in insn templates, they no longer need to be
treated different from other "ordinary" flags; the only "unusual" one
left if CpuNo64. Fold both, leaving just Cpu64.
|
|
A total four places exists where we set the two bits from flag_code, but
these values are never used. The two bits are evaluated only when coming
from insn templates.
Drop these assignments. Also make obvious that cpu_flags_check_cpu64()
is only ever used against insn templates.
|
|
While update_code_flag() checks for LM / i386, set_cpu_arch() so far
didn't, allowing e.g. 64-bit code to be emitted after ".arch generic32".
Oddly enough a few of our testcases actually exhibit bad behavior (and
hence need minor adjustments).
|
|
Do checks before updating state, and bail upon failure of either of the
checks. While moving the code, eliminate some redundancy.
|
|
As mentioned in commit 3f5bbc3e2075ef5061a815c73fdc277218489f22, some
compilers such as clang don't add debug information about stderr by
default, leaving it to external debug packages.
This commit adds a way to check if GDB has access to stderr information
when in MI mode, and uses this new mechanism to skip the related section
of the test gdb.mi/mi-dprintf.exp. It also fixes an incorrect name for a
test in that file.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
|
|
The header in a .gdb_index section uses 32-bit unsigned offsets to
refer to other areas of the section. Thus, there is a size limit of
2^32-1 which is currently unaccounted for by GDB's code for outputting
these sections.
At the moment, when GDB creates an overly large section, it will exit
abnormally due to an internal error, which is caused by a failed
assert in assert_file_size, which in turn is called from
write_gdbindex_1, both of which are in gdb/dwarf2/index-write.c.
This is what happens when that assert fails:
$ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
Reading symbols from ./libgraph_tool_inference.so...
No executable file now.
Discard symbol table from `libgraph_tool_inference.so'? (y or n) n
Not confirmed.
../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x55fddb4d78b0 gdb_internal_backtrace_1
../../gdb/bt-utils.c:122
0x55fddb4d78b0 _Z22gdb_internal_backtracev
../../gdb/bt-utils.c:168
0x55fddb98b5d4 internal_vproblem
../../gdb/utils.c:396
0x55fddb98b8de _Z15internal_verrorPKciS0_P13__va_list_tag
../../gdb/utils.c:476
0x55fddbb71654 _Z18internal_error_locPKciS0_z
../../gdbsupport/errors.cc:58
0x55fddb5a0f23 assert_file_size
../../gdb/dwarf2/index-write.c:1069
0x55fddb5a1ee0 assert_file_size
/usr/include/c++/13/bits/stl_iterator.h:1158
0x55fddb5a1ee0 write_gdbindex_1
../../gdb/dwarf2/index-write.c:1119
0x55fddb5a51be write_gdbindex
../../gdb/dwarf2/index-write.c:1273
[...]
---------------------
../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.
This problem was encountered while building the python-graph-tool
package on Fedora. The Fedora bugzilla bug can be found here:
https://bugzilla.redhat.com/show_bug.cgi?id=1773651
This commit prevents the internal error from occurring by calling error()
when the file size exceeds 2^32-1.
Using a gdb built with this commit, I now see this behavior instead:
$ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
Reading symbols from ./libgraph_tool_inference.so...
No executable file now.
Discard symbol table from `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so'? (y or n) n
Not confirmed.
Error while writing index for `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so': gdb-index maximum file size of 4294967295 exceeded
(gdb)
I wish I could provide a test case, but due to the sizes of both the
input and output files, I think that testing resources would be
strained or exceeded in many environments.
My testing on Fedora 38 shows no regressions.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
In this commit:
commit 48ac197b0c209ccf1f2de9704eb6cdf7c5c73a8e
Date: Fri Nov 19 10:12:44 2021 -0700
Handle multiple addresses in call_site_target
a buffer overflow bug was introduced when the following code was
added:
CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR,
addresses.size ());
std::copy (addresses.begin (), addresses.end (), saved);
The definition of XOBNEWVAR is (from libiberty.h):
#define XOBNEWVAR(O, T, S) ((T *) obstack_alloc ((O), (S)))
So 'saved' is going to point to addresses.size () bytes of memory,
however, the std::copy will write addresses.size () number of
CORE_ADDR sized entries to the address pointed to by 'saved', this is
going to result in memory corruption.
The mistake is that we should have used XOBNEWVEC, which allocates a
vector of entries, the definition of XOBNEWVEC is:
#define XOBNEWVEC(O, T, N) \
((T *) obstack_alloc ((O), sizeof (T) * (N)))
Which means we will have set aside enough space to create a copy of
the contents of the addresses vector.
I'm not sure how to create a test for this problem, this issue cropped
up when debugging a particular i686 built binary, which just happened
to trigger a glibc assertion (likely due to random memory corruption),
debugging the same binary built for x86-64 appeared to work just fine.
Using valgrind on the failing GDB binary pointed straight to the cause
of the problem, and with this patch in place there are no longer
valgrind errors in this area.
If anyone has ideas for a test I'm happy to work on something.
Co-Authored-By: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I've been running the test-suite on an i686-linux laptop with 1GB of memory,
and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb
not being able to spawn for a large number of test-cases afterwards.
So I investigated the memory usage, on my usual x86_64-linux development
platform.
The test-case is compiled with -DCRASH_GDB=2097152, so this:
...
static int a[CRASH_GDB], b[CRASH_GDB];
...
with sizeof (int) == 4 represents two arrays of 8MB each.
Say we add a loop around the "print a" command and print space usage
statistics:
...
gdb_test "maint set per-command space on"
for {set i 0} {$i < 100} {incr i} {
gdb_test "print a"
}
...
This gets us:
...
(gdb) print a^M
$1 = {0 <repeats 2097152 times>}^M
Space used: 478248960 (+469356544 for this command)^M
(gdb) print a^M
$2 = {0 <repeats 2097152 times>}^M
Space used: 486629376 (+8380416 for this command)^M
(gdb) print a^M
$3 = {0 <repeats 2097152 times>}^M
Space used: 495009792 (+8380416 for this command)^M
...
(gdb) print a^M
$100 = {0 <repeats 2097152 times>}^M
Space used: 1308721152 (+8380416 for this command)^M
...
In other words, we start out at 8MB, and the first print costs us about 469MB,
and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the
i686-linux laptop, the first print costs us 335MB. ]
The subsequent 8MBs are consistent with the values being saved into the value
history, but the usage for the initial print seems somewhat excessive.
There is a PR open about needing sparse representation of large arrays
(PR8819), but this memory usage points to an independent problem.
The function value_print_array_elements contains a scoped_value_mark to free
allocated values in the outer loop, but it doesn't prevent the inner loop from
allocating a lot of values.
Fix this by adding a scoped_value_mark in the inner loop, after which we have:
...
(gdb) print a^M
$1 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
(gdb) print a^M
$2 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
(gdb) print a^M
$3 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
...
(gdb) print a^M
$100 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
...
Note that the +0 here just means that the mallocs did not trigger an sbrk.
This is dependent on malloc (which can use either mmap or sbrk or some
pre-allocated memory) and will likely vary between different tunings, versions
and implementations, so this does not give us a reliable way detect the
problem in a minimal way.
A more reliable way of detecting the problem is:
...
void
value_free_to_mark (const struct value *mark)
{
+ size_t before = all_values.size ();
auto iter = std::find (all_values.begin (), all_values.end (), mark);
if (iter == all_values.end ())
all_values.clear ();
else
all_values.erase (iter + 1, all_values.end ());
+ size_t after = all_values.size ();
+ if (before - after >= 1024)
+ fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after);
...
which without the fix tells us:
...
+print a
value_free_to_mark freed 2097152 items
$1 = {0 <repeats 2097152 times>}
...
Fix a similar problem for Fortran:
...
+print array1
value_free_to_mark freed 4194303 items
$1 = (0, <repeats 2097152 times>)
...
in fortran_array_printer_impl::process_element.
The problem also exists for Ada:
...
+print Arr
value_free_to_mark freed 2097152 items
$1 = (0 <repeats 2097152 times>)
...
but is fixed by the fix for C.
Add Fortran and Ada variants of the test-case. The *.exp files are similar
enough to the original to keep the copyright years range.
While writing the Fortran test-case, I ran into needing an additional print
setting to print the entire array in repeat form, filed as PR exp/30817.
I managed to apply the compilation loop for the Ada variant as well, but with
a cumbersome repetition style. I noticed no other test-case uses gnateD, so
perhaps there's a better way of implementing this.
The regression test included in the patch is formulated in its weakest
form, to avoid false positive FAILs, which also means that smaller regressions
may not get detected.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Rewrite test-case gdb.base/huge.exp:
- use build_executable rather than gdb_compile,
- use save_vars,
- factor out hardcoded loop limits min and max,
- handle compilation failure using require, and
- avoid using . in regexp to match $, {} and <>.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Looking at the VEX and EVEX forms of vcvtneps2bf16 I noticed that
operand purpose isn't properly reflected in Vxy's definition. Rename
"dst" to "src", thus bringing things in line with Exy.
|
|
Recognize "/<number>" suffixes on both -march=+avx10.1 and the
corresponding .arch directive, setting an upper bound on the vector size
that insns may use. Such a restriction can be reset by setting a new base
architecture, by using a suffix-less form, by disabling AVX10, or by
enabling any other VEX/EVEX-based vector extension.
While for most insns we can suppress their use with too wide operands
via registers becoming unavailable (or in Intel syntax memory operand
size specifiers not being recognized), mask register insns have to have
their minimum required vector size specified in a new attribute. (Of
course this new attribute could also be used on other insns.)
Note that .insn continues to be permitted to emit EVEX{512,256} (and
VEX256 ones) encodings regardless of vector size restrictions in place.
Of course these can't be expressed using zmm (or ymm) operands then,
but need using the EVEX.512.* forms (broadcast forms may be usable right
now, but this may go away so shouldn't be relied upon). This is why no
assertions should be added to build_{e,}vex_prefix().
|
|
Since this is merely a re-branding of certain AVX512* features, there's
little code to be added.
The main aspect here are new testcases. In order to be able to re-use
some of the existing testcases, several of them need their start symbols
adjusted. Note that 256- and 128-bit tests want adding here, as these
need to work right away. Subsequently they'll gain vector length
constraints.
Since it was missing and is wanted here, also add an AVX512VL+VPOPCNTDQ
test.
|
|
These probably should have been put in place already anyway, but they're
very much wanted in order to then put AVX10.1 support on top. Note that
to avoid reverse dependencies towards SSE (just like we already do for
AVX and XOP), add_isa_dependencies() needs some further tweaking.
While there also address a related anomaly: Disabling AES but neither
AVX nor VAES (similarly for {,V}PCLMULQDQ) would better keep the 128-bit
VEX-encoded forms available. Note that for this the VAES insns are moved
past the AVX+AES ones, to avoid the property-11 test suddenly failing.
The test really is wrong, but let's not also make things inconsistent:
Without the movement, YMM use would be correctly recorded for the
128-bit forms simply because the first template already matches, as long
as VAES wasn't disabled. Yet it still wouldn't be if only AVX+AES were
enabled. Nor would behavior here then be the same as for VPCLMUL* insns.
|
|
|
|
* elf.c (_bfd_elf_init_reloc_shdr): Don't segfault on alloc fail.
|
|
* elf-strtab.c (_bfd_elf_strtab_init): In the event of memory allocation failure, make sure that the hash table is freed.
|
|
|
|
Remove a warning about mi1. mi1 was removed in 975249ff4e26 ("Remove MI
version 1"). It is no longer possible to reach this warning, since
trying to use interpreter mi1 bails out before:
$ ./gdb -nx -q --data-directory=data-directory -i mi1
Interpreter `mi1' unrecognized
Change-Id: Ie43b21e01bca1407995150c729531a70ee662003
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A user pointed out that if a DAP setBreakpoints request has a 'source'
field in a SourceBreakpoint object, then the gdb DAP implementation
will throw an exception.
While SourceBreakpoint does not allow 'source' in the spec, it seems
better to me to accept it. I don't think we should fully go down the
"Postel's Law" path -- after all, we have the type-checker -- but at
the same time, if we do send errors, they should be intentional and
not artifacts of the implementation.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30820
|
|
I see the following warning when building GDB on FreeBSD/amd64 with
Clang 14,
======================================================================
CXX mdebugread.o
mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized]
f->set_loc_enumval (tsym.value);
^
mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning
struct field *f;
^
= nullptr
======================================================================
after digging a little, I realized that we can not simply do what
Clang 14 says.
The root cause of this issue is that we lost the initialization of
the variable 'f' in this commit,
commit 2774f2dad5f05e68771c07df6ab0fb23baa2118e
Date: Thu Aug 31 09:37:44 2023 +0200
[gdb/symtab] Factor out type::{alloc_fields,copy_fields}
we have made these modifications,
---------------------------------------------------------------------
--- a/gdb/mdebugread.c
+++ b/gdb/mdebugread.c
@@ -1034,9 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend,
t->set_code (type_code);
t->set_length (sh->value);
- t->set_num_fields (nfields);
- f = ((struct field *) TYPE_ALLOC (t, nfields * sizeof (struct field)));
- t->set_fields (f);
+ t->alloc_fields (nfields, false);
---------------------------------------------------------------------
The problem is that the variable 'f' is used in the second half of
parse_symbol, that's why Clang complained.
To fix this issue we need to ensure that the varibale 'f' is
initialized. Calling the fields method is an obvious way to fix this
issue.
Tested on FreeBSD/amd64 by rebuilding.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
The gdb/testsuite/gdb.rocm/multi-inferior-gpu.cpp testcase contains a
call to execl which does not have NULL as a last argument. This is
an invalid use of execl. This patch fixes this oversight.
Change-Id: I03b60abe30468d71ba5089b240c6d00f9b8883b2
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
This changes hash_ptid to instead be a specialization of std::hash.
This makes it a little easier to use with standard containers.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed a typo in the "Basic Python" node, and when fixing it
realized that the paragraph could use a link to the block_signals
function. This patch is the result.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
Simplify things a bit using foreach_with_prefix. The only expected
change is in the naming of tests.
Change-Id: Icb5e55207e0209e0d44d9e7c16a2f5e11aa29017
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Got a regression email due to merge of commit in CI config
tcwg_gdb_check/master-aarch64 :
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=41439185cd0075bbb1aedf9665685dba0827cfec
Begining of test "gdb.fortran/array-slices-bad.exp" was updated in above
commit to start the test from running to line with tag "First Breakpoint"
instead of "fortran_runto_main". Reason of the regression is shared
libraries are still loaded after hitting the breakpoint as "nosharedlibrary"
is already called before hitting the breakpoint.
So now after this change test is updated accordingly to disable and unload
shared libraries symbols after hitting the first breakpoint.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Following the example of private_thread_info and private_inferior, turn
struct btrace_target_info into a small class hierarchy.
Also merge btrace_tinfo_bts with btrace_tinfo_pt and inline into
linux_btrace_target_info.
Fixes PR gdb/30751.
|
|
The code is only used in remote.c and all functions can be declared static.
|
|
I see the following failure when running this test on an AMD machine:
p/x $fioff^M
$24 = 0x0^M
(gdb) FAIL: gdb.arch/amd64-init-x87-values.exp: check_x87_regs_around_init: check post FLD1 value of $fioff
The register that GDB calls fioff normally contains the address of the
last instruction executed by the x87 unit. It is available through the
FSAVE/FXSAVE/XSAVE instructions, at offset 0x8 of the FSAVE/FXSAVE/XSAVE
area. You can read about it in the Intel manual [1] at section "10.5.1
FXSAVE Area" (and equivalent sections for FSAVE and XSAVE) or in the AMD
manual [2] at section "11.4.4 Saving Media and x87 Execution Unit
State".
The test therefore expects that after executing the FLD1 instruction,
the fioff register contains the address of the FLD1 instruction.
However, the FXSAVE and XSAVE instructions (which the kernel uses to
dump x87 register state which it provides GDB through ptrace) behave
differently on AMD CPUs. In section "11.4.4.3 FXSAVE and FXRSTOR
Instructions" of the AMD manual, we read:
The FXSAVE and FXRSTOR instructions save and restore the entire
128-bit media, 64-bit media, and x87 state. These instructions
usually execute faster than FSAVE/FNSAVE and FRSTOR because they do
not normally save and restore the x87 exception pointers
(last-instruction pointer, last data-operand pointer, and last
opcode). The only case in which they do save the exception pointers
is the relatively rare case in which the exception-summary bit in
the x87 status word (FSW.ES) is set to 1, indicating that an
unmasked exception has occurred.
So, unless a floating point exception happened and that exception is
unmasked in the x87 FPU control register (which isn't by default on
Linux, from what I saw), the "last instruction address" register (or
fioff as GDB calls it) will always be 0 on an AMD CPU.
For this reason, I think it's fine to change the test to accept the
value 0 - that's just how the processor works.
I toyed with the idea of changing the test program to make it so the CPU
would generate a non-zero fioff. That is by unmasking an FPU exception
and executing an instruction to raise that kind exception. It worked,
but then I would have to change the test more extensively, and it didn't
seem to be worth it.
[1] https://cdrdv2.intel.com/v1/dl/getContent/671200
[2] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf
Change-Id: If2e1d932f600ca01b15f30b14b8d38bf08a3e00b
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
|
|
|
|
|
|
Do the same as commit b9d8f5601bcf in another place generating
DW_CFA_advance_loc4. The idea behind commit b9d8f5601bcf was that
when a DW_CFA_advance_loc4 of zero is seen in eh_frame_relax_frag and
eh_frame_convert_frag we want to remove the opcode entirely, not just
convert to a nop. If the opcode was split over two frags then a size
adjustment would need to be done to the first frag, not just the
second as is correct for other cases with split frags. This would
complicate the eh relaxation. It's easier to ensure the frag is not
split.
* ehopt.c (check_eh_frame): Don't allow DW_CFA_advance_loc4
to be placed in a different frag to the rs_cfa.
|
|
The auto-builders pointed out that I neglected to run 'black' after a
rest testcase change. This patch fixes the oversight.
|
|
gprofng uses insn_type in print_address_func().
But insn_type is always zero on aarch64.
opcodes/ChangeLog:
2023-09-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* opcodes/aarch64-dis.c (print_insn_aarch64_word): Set insn_type for
branch instructions.
|
|
While investigating this [1], I initially had no idea what register
"fioff" stood for, making it difficult to map it to something in the
Intel or AMD manuals. Similarly, I can imaging someone familiar with
x87 to want to print the "x87 last instruction address", and have no
clue that GDB makes it available as register "fioff". The names of the
x87 state fields don't seem to be standardized, they even change between
sections of the Intel manual (between the FSAVE, FXSAVE and XSAVE area
descriptions).
Add some details to the doc to help one map GDB register names to x87
state fields.
[1] https://inbox.sourceware.org/gdb-patches/20230908022722.430741-1-simon.marchi@efficios.com/T/#u
Change-Id: I0ea1eb648358e62da4aa87eea3515ee8a09f2762
Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
I'm looking to add some x86-specific information to the doc, but I find
the naming of this section odd. It doesn't really talk about issues, it
just gives generally useful information. Also, the sections about other
architectures don't mention "issues", just the architecture name.
Also, at least in the HTML version of the doc, the name is inconsistent
between the main table of content, where it appears as "x86
Architecture-specific Issues", and the sub-table of contents of the
"Architectures" section, where it appears as "i386".
Rename the section to just "x86".
Change-Id: I0a119ff1ab5e7b83c9afa3c3977eb085e88f52ca
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
set_expected_error is no longer used. It has been replaced by
more specific error messages.
|
|
I ran test-case gdb.dwarf2/dwzbuildid.exp with target board cc-with-gdb-index,
and noticed that compilation failure for one exec prohibited testing of all
execs.
Fix this by restructuring the test-case, such that we have:
...
PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: set debug-file-directory
PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: print the_int
UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=mismatch: compilation failed
UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=fallback: compilation failed
...
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/dwzbuildid.exp using target board readnow, I
get:
...
(gdb) file dwzbuildid-mismatch^M
Reading symbols from dwzbuildid-mismatch...^M
warning: File "dwzbuildid5.o" has a different build-id, file skipped^M
could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch^M
(gdb) delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break -qualified main^M
No symbol table is loaded. Use the "file" command.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: gdb_breakpoint: set breakpoint at main
...
This is PR symtab/26797: when using readnow, a failure in reading the dwarf
results in the minimal symbols not being available.
Add a corresponding KFAIL.
Tested on x86_64-linux.
|
|
While investigating the execs of gdb.dwarf2/dwzbuildid.exp using readelf I ran
into a warning:
...
$ readelf -w dwzbuildid-ok > READELF
readelf: Warning: .debug_info offset of 0x2e in .debug_aranges section does not
point to a CU header.
...
AFAICT, the warning is incorrect, I've filed PR binutils/30835 about that.
While looking at the .debug_aranges section, I noticed that the entries for
the CUs generated by the dwarf assembler are missing.
Fix this by adding the missing .debug_aranges entries.
Tested on x86_64-linux.
|
|
When looking at the execs from test-case gdb.dwarf2/dwzbuildid.exp using
readelf, I run into:
...
$ readelf -w dwzbuildid-ok > READELF
readelf: Warning: Corrupt debuglink section: .gnu_debugaltlink
readelf: Warning: Build-ID is too short (0x6 bytes)
...
Fix this by ensuring the Build-IDs are the required 20 bytes.
Tested on x86_64-linux.
|
|
In commit:
commit 3ce8f906be7a55d8c0375e6d360cc53b456d86ae
Date: Tue Aug 8 10:45:20 2023 +0100
gdb: MI stopped events when unwindonsignal is on
a new test, gdb.mi/mi-condbreak-throw.exp, was added. Unfortunately,
this test would fail when using the native-gdbserver board (and other
similar boards).
The problem was that one of the expected output patterns included some
output from the inferior. When using the native-gdbserver board, this
output is not printed to GDB's tty, but is instead printed to
gdbserver's tty, the result is that the expected output no longer
matches, and the test fails.
Additionally, as the output is actually from the C++ runtime, rather
than the test's source file, changes to the C++ runtime could cause
the output to change.
To solve both of these issues, in this commit, I'm removing the
reference to the inferior's output, and replacing it with '.*', which
will skip the output if it is present, but is equally happy if the
output is not present.
After this commit gdb.mi/mi-condbreak-throw.exp now passes on all
boards, including native-gdbserver.
|
|
Avoid triggering the respective abort() in output_insn().
|
|
It is a trivial wrapper around the supports_command_editing method,
remove it.
Change-Id: I0fe3d7dc69601b3b89f82e055f7fe3d4af1becf7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It is a trivial wrapper around the pre_command_loop method, remove it.
Change-Id: Idb2c61f9b68988528006a9a9b2b528f43781eef4
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
The modified test in function-calls.exp actually passes with ifort and
ifx. The particular fail seems to be specific to gfortran. When the
test was introduced it was only tested with gfortran (actually the
whole patch was written with gfortran and the GNU Fortran argument
passing convention in mind).
Approved-by: Tom Tromey <tom@tromey.com>
|
