| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit changes gdb/version.in to 12.1.90.DATE-git.
This commit also makes the following changes in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_minor to 2.
|
|
This commit changes gdb/version.in to 12.1.
|
|
This imports the gnulib patches that were mentioned by Eli. I created
the patches from gnulib git, ran them through filterdiff, and then
applied them using update-gnulib.sh's patch-applying facility.
I think the patches are either obviously Windows-specific or harmless,
but I encourage you to look for yourself.
I tested by rebuilding on x86-64 Fedora 34, and also using the Fedora
mingw cross toolchain.
|
|
After this commit:
commit d08cbc5d3203118da5583296e49273cf82378042
Date: Wed Dec 22 12:57:44 2021 +0000
gdb: unbuffer all input streams when not using readline
Issues were reported with some MS-Windows hosts, see the thread
starting here:
https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html
Filed in bugzilla as: PR mi/29002
The problem seems to be that calling setbuf on terminal file handles
is not always acceptable, see this mail for more details:
https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html
This commit does two things, first moving the setbuf calls out of
gdb_readline_no_editing_callback so that we don't end up calling
setbuf so often.
Then, for MS-Windows hosts, we don't call setbuf for terminals, this
appears to resolve the issues that have been reported.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002
|
|
The following behaviour was observed in GDB:
(gdb) show remote X-packet
Support for the `p' packet is auto-detected, currently unknown.
Note the message mentions the 'p' packet. This is a regression since
this commit:
commit 8579fd136a614985bd27f20539c7bb7c5a51287d
Date: Mon Nov 8 14:58:46 2021 +0000
gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr
Before this commit the behaviour was:
(gdb) show remote X-packet
Support for the `X' packet is auto-detected, currently unknown.
The problem was caused by a failed attempt to ensure that some
allocated strings were deleted when GDB exits. The code in the above
commit attempted to make use of 'static' to solve this problem,
however, the solution was just wrong.
In this new commit I instead allocate a static vector into which all
the allocated strings are stored, this ensures the strings are
released when GDB exits (which makes output from tools like valgrind
cleaner), but each string within the vector can be unique, which fixes
the regression.
|
|
With test-case gdb.ada/float-bits.exp and native we get:
...
(gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
$9 = 5.0e+25^M
(gdb) PASS: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
...
but with target board unix/-m32 we have instead:
...
(gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
Cannot export value 2596145952482202326224873165792712 as 96-bits \
unsigned integer (must be between 0 and 79228162514264337593543950335)^M
(gdb) FAIL: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
...
Fix this by testing whether 16llf is supported by doing ptype long_long_float
which gets us either:
...
type = <16-byte float>^M
...
or:
...
type = <12-byte float>^M
...
Tested on x86_64-linux with native and unix/-m32.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29041
|
|
When running test-case gdb.go/methods.exp with make check we have:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) XFAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...
but with make check-readmore the XFAIL fails to trigger:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...
This happens because this gdb_test_multiple "maintenance print symbols"
regexp:
...
-re "\r\n$gdb_prompt $" {
...
matches the entire command output.
Fix this by adding the missing ^ at the regexp start.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29064
|
|
Pedro Alves warned me that there is a race in
gdb.dwarf2/calling-convention.exp making the test sometimes fail on his
setup. This can be reliably reproduced using :
make check-read1 TESTS="gdb.dwarf2/calling-convention.exp"
The relevant part of the gdb.log file is:
return 35
Function 'foo' does not follow the target calling convention.
If you continue, setting the return value will probably lead to unpredictable behaviors.
Make foo return now? (y or n) PASS: gdb.dwarf2/calling-convention.exp: return 35
n
Not confirmed
(gdb) FAIL: gdb.dwarf2/calling-convention.exp: finish
The issue is that when doing the test for "return 35", the DejaGnu test
sends "n" (to tell GDB not to perform the return action) but never
consumes the "Not confirmed" acknowledgment sent by GDB. Later, when
trying to do the next test, DejaGnu tries to match the leftover output
from the "return" test. As this output is not expected, the test fails.
Fix by using gdb_test to send the "n" answer and match the confirmation
and consume all output to the prompt.
Also do minor adjustments to the main regex:
- Remove the leading ".*" which is not required.
- Ensure that the "?" from the question is properly escaped.
Tested on x86_64-gnu-linux, using
- make check TESTS="gdb.dwarf2/calling-convention.exp"
- make check-read1 TESTS="gdb.dwarf2/calling-convention.exp"
- make check-readmore TESTS="gdb.dwarf2/calling-convention.exp"
Co-authored-by: Pedro Alves <pedro@palves.net>
Change-Id: I42858b13db2cbd623c5c1739de65ad423e0c0938
|
|
Currently, one use of target_waitstatus yields a warning:
target/waitstatus.h: In function 'void stop_all_threads()':
target/waitstatus.h:175:13: warning: 'ws.target_waitstatus::m_value' may be used uninitialized in this function [-Wmaybe-uninitialized]
175 | m_value = other.m_value;
| ~~~~~~~~^~~~~~~~~~~~~~~
This patch silences the warning. I tried the "volatile member"
approach that was used for gdb::optional, but that didn't work, so
this patch simply initializes the member.
|
|
Internally at AdaCore, we recently started testing a 64-bit gdb
debugging 32-bit processes. This failed with gdb head, but not with
gdb 11.
The tests fail like this:
Starting program: [...].exe
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
After some debugging and bisecting, to my surprise the bug was
introduced by commit 183be222 ("gdb, gdbserver: make target_waitstatus
safe").
The problem occurs in handle_exception. Previously the code did:
- ourstatus->kind = TARGET_WAITKIND_STOPPED;
[...]
case EXCEPTION_BREAKPOINT:
[...]
- ourstatus->kind = TARGET_WAITKIND_SPURIOUS;
[...]
/* FALLTHROUGH */
case STATUS_WX86_BREAKPOINT:
DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
- ourstatus->value.sig = GDB_SIGNAL_TRAP;
[...]
- last_sig = ourstatus->value.sig;
However, in the new code, the fallthrough case does:
+ ourstatus->set_stopped (GDB_SIGNAL_TRAP);
... which changes the 'kind' in 'ourstatus' after falling through.
This patch rearranges the 'last_sig' setting to more closely match
what was done before (this is probably not strictly needed but also
seemed harmless), and removes the fall-through in the
'ignore_first_breakpoint' case when __x86_64__ is defined.
|
|
Since commit 359efc2d894 ("[gdb/testsuite] Make gdb.base/annota1.exp more
robust") we see this fail with target board unix/-fPIE/-pie:
...
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
...
The problem is that the commit makes the number and order of matched
annotations fixed, while between target boards unix and unix/-fPIE/-pie there
is a difference:
...
\032\032post-prompt
Starting program: outputs/gdb.base/annota1/annota1
+\032\032breakpoints-invalid
+
\032\032starting
\032\032frames-invalid
...
Fix this by optionally matching the additional annotation.
Tested on x86_64-linux.
|
|
On openSUSE Tumbleweed I run into:
...
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
...
The problem is that the libthread_db message occurs at a location where it's
not expected:
...
Starting program: outputs/gdb.base/annota1/annota1 ^M
^M
^Z^Zstarting^M
^M
^Z^Zframes-invalid^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
^Z^Zbreakpoints-invalid^M
^M
...
Fix this by making the matching more robust:
- rewrite the regexp such that each annotation is on a single line,
starting with \r\n\032\032 and ending with \r\n
- add a regexp variable optional_re, that matches all possible optional
output, and use it as a separator in the first part of the regexp
Tested on x86_64-linux.
|
|
When running test-case gdb.base/stap-probe.exp with make target check-read1, I
run into this and similar:
...
FAIL: gdb.base/stap-probe.exp: without semaphore, not optimized: \
info probes stap (timeout)
...
Fix this by using gdb_test_lines instead of gdb_test.
Tested on x86_64-linux.
|
|
On openSUSE Leap 15.3, mpx support has been disabled for m32, so I run into:
...
(gdb) run ^M
Starting program: outputs/gdb.arch/i386-mpx/i386-mpx ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
No MPX support^M
...
and eventually into all sort of fails in this and other mpx test-cases.
Fix this by detecting the "No MPX support" message in have_mpx.
Tested on x86_64-linux with target boards unix and unix/-m32.
|
|
As reported in PR29043, when running test-case gdb.dwarf2/dw2-lines.exp with
target board unix/-m32/-fPIE/-pie, we run into:
...
Breakpoint 2, 0x56555540 in bar ()^M
(gdb) PASS: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
continue to breakpoint: foo \(1\)
next^M
Single stepping until exit from function bar,^M
which has no line number information.^M
0x56555587 in main ()^M
(gdb) FAIL: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
next to foo (2)
...
The problem is that the bar breakpoint ends up at an unexpected location
because:
- the synthetic debug info is incomplete and doesn't provide line info
for the prologue part of the function, so consequently gdb uses the i386
port prologue skipper to get past the prologue
- the i386 port prologue skipper doesn't get past a get_pc_thunk call.
Work around this in the test-case by breaking on bar_label instead.
Tested on x86_64-linux with target boards unix, unix/-m32, unix/-fPIE/-pie and
unix/-m32/-fPIE/-pie.
|
|
I see this failure:
(gdb) run ^M
Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-inline-param/dw2-inline-param ^M
Warning:^M
Cannot insert breakpoint 1.^M
Cannot access memory at address 0x113b^M
^M
(gdb) FAIL: gdb.dwarf2/dw2-inline-param.exp: runto: run to *0x113b
The test loads the binary in GDB, grabs the address of a symbol, strips
the binary, reloads it in GDB, runs the program, and then tries to place
a breakpoint at that address. The problem is that the binary is built
as position independent, so the address GDB grabs in the first place
isn't where the code ends up after running.
Fix this by linking the binary as non-position-independent. The
alternative would be to compute the relocated address where to place the
breakpoint, but that's not very straightforward, unfortunately.
I was confused for a while, I was trying to load the binary in GDB
manually to get the symbol address, but GDB was telling me the symbol
could not be found. Meanwhile, it clearly worked in gdb.log. The thing
is that GDB strips the binary in-place, so we don't have access to the
intermediary binary with symbols. Change the test to output the
stripped binary to a separate file instead.
Change-Id: I66c56293df71b1ff49cf748d6784bd0e935211ba
|
|
On irc, Pedro pointed out that Ada couldn't properly handle
0xffffffffffffffff. This used to work, but is a regression due to
some patches I wrote in the Ada lexer. This patch fixes the bug.
|
|
A while back, I sent a patch to unify the Ada varsize-limit setting
with the more generic max-value-size:
https://sourceware.org/pipermail/gdb-patches/2021-September/182004.html
However, it turns out I somehow neglected to send part of the patch.
Internally, I also removed the "Ada Settings" node from the manual, as
it only documents the obsolete setting.
This patch removes this text.
|
|
Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that
a separate debug file was passed as the objfile for a shared library
to svr4_fetch_objfile_link_map. However, a separate debug file can
also be passed for TLS variables in the main executable. In addition,
frv_fetch_objfile_link_map also expects to be passed the original
objfile rather than a separate debug file, so pull the code to resolve
a separate debug file to the main objfile up into
target_translate_tls_address.
|
|
Bug 28980 shows that trying to value_copy an entirely optimized out
value causes an internal error. The original bug report involves MI and
some Python pretty printer, and is quite difficult to reproduce, but
another easy way to reproduce (that is believed to be equivalent) was
proposed:
$ ./gdb -q -nx --data-directory=data-directory -ex "py print(gdb.Value(gdb.Value(5).type.optimized_out()))"
/home/smarchi/src/binutils-gdb/gdb/value.c:1731: internal-error: value_copy: Assertion `arg->contents != nullptr' failed.
This is caused by 5f8ab46bc691 ("gdb: constify parameter of
value_copy"). It added an assertion that the contents buffer is
allocated if the value is not lazy:
if (!value_lazy (val))
{
gdb_assert (arg->contents != nullptr);
This was based on the comment on value::contents, which suggest that
this is the case:
/* Actual contents of the value. Target byte-order. NULL or not
valid if lazy is nonzero. */
gdb::unique_xmalloc_ptr<gdb_byte> contents;
However, it turns out that it can also be nullptr also if the value is
entirely optimized out, for example on exit of
allocate_optimized_out_value. That function creates a lazy value, marks
the entire value as optimized out, and then clears the lazy flag. But
contents remains nullptr.
This wasn't a problem for value_copy before, because it was calling
value_contents_all_raw on the input value, which caused contents to be
allocated before doing the copy. This means that the input value to
value_copy did not have its contents allocated on entry, but had it
allocated on exit. The result value had it allocated on exit. And that
we copied bytes for an entirely optimized out value (i.e. meaningless
bytes).
From here I see two choices:
1. respect the documented invariant that contents is nullptr only and
only if the value is lazy, which means making
allocate_optimized_out_value allocate contents
2. extend the cases where contents can be nullptr to also include
values that are entirely optimized out (note that you could still
have some entirely optimized out values that do have contents
allocated, it depends on how they were created) and adjust
value_copy accordingly
Choice #1 is safe, but less efficient: it's not very useful to allocate
a buffer for an entirely optimized out value. It's even a bit less
efficient than what we had initially, because values coming out of
allocate_optimized_out_value would now always get their contents
allocated.
Choice #2 would be more efficient than what we had before: giving an
optimized out value without allocated contents to value_copy would
result in an optimized out value without allocated contents (and the
input value would still be without allocated contents on exit). But
it's more risky, since it's difficult to ensure that all users of the
contents (through the various_contents* accessors) are all fine with
that new invariant.
In this patch, I opt for choice #2, since I think it is a better
direction than choice #1. #1 would be a pessimization, and if we go
this way, I doubt that it will ever be revisited, it will just stay that
way forever.
Add a selftest to test this. I initially started to write it as a
Python test (since the reproducer is in Python), but a selftest is more
straightforward.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28980
Change-Id: I6e2f5c0ea804fafa041fcc4345d47064b5900ed7
|
