When running test-case gdb.tui/tui-layout.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
FAIL: gdb.tui/tui-layout.exp: terminal=dumb: execution=false: layout=asm: \
layout asm (timeout)
...
The problem is that the test-case expects that the default "setenv TERM dumb"
has effect, which is not the case for remote host.
Fix this by skipping the test for remote host.
Tested on x86_64-linux.
When running test-case gdb.tui/tui-nl-filtered-output.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
FAIL: gdb.tui/tui-nl-filtered-output.exp: check printf output
...
The problem is that Term::enter_tui is returning 0, but the test-case doesn't
check for this, and consequently runs unsupported tests.
Fix this by adding the missing check.
Tested on x86_64-linux.
When running test-case gdb.tui/corefile-run.exp with both host and target board
local-remote-host-native.exp, we run into:
...
FAIL: gdb.tui/corefile-run.exp: load corefile
...
while this passes with USE_TUI=0.
The problem is that the TUI setup code uses "setenv TERM ansi", which has no
effect on remote host.
I can confirm this analysis by working around this problem in
local-remote-host-native.exp like this:
...
- spawn $RSH -t -l $username $remote $cmd
+ spawn $RSH -t -l $username $remote "export TERM=ansi; $cmd"
...
For now, simply make TUI unsupported for remote host, by returning 0 in
prepare_for_tui.
Tested on x86_64-linux.
Once in a while I find myself rewriting a TUI test-case into a non-TUI
test-case, to better understand whether the problem I'm looking at is
related to the TUI or not.
I've got the impression that I've done this sufficiently often that it's worth
committing the non-TUI version, so having just written a non-TUI version of
gdb.tui/corefile-run.exp, let's commit it.
The non-TUI version can be enabled by doing:
...
$ make check "RUNTESTFLAGS=gdb.tui/corefile-run.exp USE_TUI=0"
...
Also remove hard-coding of a source line number.
Tested on x86_64-linux.
In test-case gdb.tui/corefile-run.exp, we have this bit:
...
require !use_gdb_stub
if { [target_info gdb_protocol] == "extended-remote" } {
untested "not supported"
return
}
...
So with target board native-gdbserver we get:
...
UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: !use_gdb_stub
...
and with target board native-extended-gdbserver instead:
...
UNTESTED: gdb.tui/corefile-run.exp: not supported
...
Fix this by:
- adding an optional argument target_description to proc
target_can_use_run_cmd
- handling the target_description == core &&
[target_info gdb_protocol] == "extended-remote" case in the proc
- using require {target_can_use_run_cmd core}
such that now in both cases we have:
...
UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: \
target_can_use_run_cmd core
...
Tested on x86_64-linux.
With test-case gdb.threads/step-bg-decr-pc-switch-thread.exp and target board
native-gdbserver, I run into:
...
(gdb) UNSUPPORTED: gdb.threads/step-bg-decr-pc-switch-thread.exp: \
switch to main thread
Remote debugging from host ::1, port 43914^M
monitor exit^M
Cannot execute this command while the target is running.^M
Use the "interrupt" command to stop the target^M
and then try again.^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...
Fix this by following the advice and issuing an interrupt command, allowing
the following monitor exit command to succeed.
Tested on x86_64-linux.
PR python/17136 reported an unhandled exception when using typeprinters
only valid on some objfiles, rather than being a global typeprinter. The
fix was accepted without a regression test, and we've been carrying one
out-of-tree for a while but I think it's worth upstreaming. The code
itself was developed by Jan Kratochvil.
Co-Authored-By: Jan Kratochvil <jkratochvil@azul.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17136
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
scalar_binop has code for "&&" and "||", but I think this code can't
currently be run -- and, furthermore, it doesn't make sense to have
this code here, as the point of these operators is to short-circuit
evaluation.
This patch removes the dead code.
Regression tested on x86-64 Fedora 36.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Similar to the arm target documentation situation, the documentation of the
XML features for AArch64 targets is rather brief. I have received the same
feedback that what gdb carries in the documentation is quite unclear from the
perspective of what debugging servers should define in the XML features, how and
what the outcome is in gdb.
This patch attempts to clarify a bit more what all the possible features are.
The documentation of the XML features for Arm targets is very brief. I have
received feedback saying it is quite unclear from the perspective of the
debugging servers what should be defined in the XML features, how and
what the outcome is in gdb.
This patch attempts to clarify a bit more what all the possible features are.
gprofng/ChangeLog
2023-03-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
gprofng/src/DwarfLib.cc (DwrLineRegs::getPath): Add a DW_AT_comp_dir
string if the directoty table has relative names.
objfile_relocate1 introduces new scopes that aren't necessary. I
noticed this while working on an earlier patch in this series. This
patch removes these.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Linetables no longer change after they are created. This patch
applies const to them.
Note there is one hack to cast away const in mdebugread.c. This code
allocates a linetable using 'malloc', then later copies it to the
obstack. While this could be cleaned up, I chose not to do so because
I have no way of testing it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes linetables to not add the text offset to the addresses
they contain. I did this in a few steps, necessarily combined
together in one patch: I renamed the 'pc' member to 'm_pc', added the
appropriate accessors, and then recompiled. Then I fixed all the
errors. Where possible I generally chose to use the raw_pc accessor,
as it is less expensive.
Note that this patch discounts the possibility that the text section
offset might cause wraparound in the addresses in the line table.
However, this was already discounted -- in particular,
objfile_relocate1 did not re-sort the table in this scenario. (There
was a bug open about this, but as far as I can tell this has never
happened, it's not even clear what inspired that bug.)
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This adds a couple of comparison operators to linetable_entry, and
simplifies both the calls to sort and one other spot that checks for
equality.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Some systems may install binutils headers into a system location
(e.g. /usr/local/include on FreeBSD) which may also include headers
for other external packages used by GDB such as zlib or zstd. If a
system include path such as /usr/local/include is added before local
include paths to directories within a clone or release tarball, then
headers from the external binutils package are used which can result
in build failures if the external binutils package is out of sync with
the version of GDB being built.
To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
for "local" componenets before external components.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214
Reviewed-By: Tom Tromey <tom@tromey.com>
Similar to d58854b6dd for x86_64.
_Thread_local int a;
int main() { return a; }
% gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `a' at 0x15 in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
This commit fixes the issue.
There is an argument that the -fno-plt TLS sequence was added after
R_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 was
intended to be unsupported.
Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today). Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_386_TLS_GD ...`
error which is hard to reason about.
It seems easier to apply this simple change to prevent the footgun.
PR ld/24784
* bfd/elf32-i386.c (elf_i386_check_tls_transition): Allow R_386_GOT32.
_Thread_local int a;
int main() { return a; }
% gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
This commit fixes the issue.
There is an argument that the -fno-plt TLS sequence was added after
R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
intended to be unsupported.
Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today). Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
error which is hard to reason about.
There is another argument which may be weaker but relevant to the
necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
likely need some assembler support to disable relaxation. Without the
support and if the compiler needs to support many gas version, the
simplest solution would be to use -Wa,-mrelax-relocations=no.
PR ld/24784
* bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
R_X86_64_GOTPCREL.
With test-case gdb.python/py-completion.exp and target board
native-extended-gdbserver I get this warning:
...
(gdb) PASS: gdb.python/py-completion.exp: discard #2
completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
PASS: gdb.python/py-completion.exp: completefilecommandcond completion
Remote debugging from host ::1, port 53346^M
monitor exit^M
not implemented^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...
Fix this by adding the missing "discard #3", such that we have instead:
...
(gdb) PASS: gdb.python/py-completion.exp: discard #2
completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
PASS: gdb.python/py-completion.exp: completefilecommandcond completion
^M
not implemented^M
(gdb) PASS: gdb.python/py-completion.exp: discard #3
Remote debugging from host ::1, port 36278^M
monitor exit^M
(gdb)
...
Tested on x86_64-linux.
[ Using $pp as shorthand for the pagination prompt
"--Type <RET> for more, q to quit, c to continue without paging--". ]
The test-case gdb.python/py-cmd.exp passes, but the handling of the
test_multiline command output looks a bit odd:
...
(gdb) test_multiline
test_multiline output
...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
q
test_multiline
Quit
(gdb) test_multiline
test_multiline output
...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
...
What happens is:
- a test_multiline command is issued
- some output is printed, followed by a pagination prompt
- the test-case concludes that pagination occurred, and produces a PASS
- "q\n" is replied to the pagination prompt
- without waiting for response to the "q\n", another test_multiline command is
issued
- in response to the "q\n" we get "Quit\n(gdb) "
- some output is printed, followed by a pagination prompt
- the test-case concludes that there's a valid response to the "q\n", and
produces a PASS, consuming the second pagination prompt, but without a reply.
My conclusion is that the second test_multiline command is unintentional, so fix
this by removing it.
Without it, we have the more straightforward:
...
(gdb) test_multiline
test_multiline output
...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
q
Quit
(gdb) PASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
...
This also fixes the following warning with target board native-gdbserver:
...
WARNING: Timed out waiting for EOF in server after monitor exit
...
Tested on x86_64-linux.
With test-case gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp
and target board remote-gdbserver-on-localhost, I run into:
...
FAIL: $exp: runto: run to main
...
I can easily fix this using "gdb_load_shlib $binfile_lib", but then run into:
...
(gdb) print all_good^M
$1 = false^M
(gdb) FAIL: $exp: print all_good
info pretty-printer^M
...
Sysroot is set to "target:", so gdb downloads the shared library from the target
(Using $so as shorthand for
libpy-autoloaded-pretty-printers-in-newobjfile-event.so):
...
Reading /home/remote-target/$so from remote target...^M
...
and internally refers to it as "target:/home/remote-target/$so".
In load_auto_scripts_for_objfile, gdb gives up trying to auto-load scripts
for $so once it checks for is_target_filename.
Fix this by declaring auto-load unsupported if sysroot starts with "target:".
Tested on x86_64-linux.
This changes many tests to use 'require' when checking target_info.
In a few spots, the require is hoisted to the top of the file, to
avoid doing any extra work when the test is going to be skipped
anyway.
allocate_stub_method is only called from stabsread.c, and I don't
think it will be needed anywhere else. So, move it and make it
static. Tested by rebuilding.
Revert "Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant."
This reverts commit adbe951fc9.
Revert "ld test asciz and ascii fails"
This reverts the ascii.d part of commit 5f497256be.
Revert "Add support for the ASCII directive inside linker scripts."
This mostly reverts commit 9fe129a410
leaving the asciz.d and asciz.t changes in place.
This is a hopefully temporary reversion of new ld features for
embedded processors by Ulf Samuelsson, plus some followup patches.
Squashed together from the following:
Revert "lddigest 32-bit support and gcc-4 compile errors"
This reverts commit d7ee19be87110a8f5342cec6e323d83d01c641d1.
Revert "ld: Use correct types for crc64 calculations"
This reverts commit 9a534b9f8e.
Revert "Re: DIGEST: testsuite"
This reverts commit c8e85484d8.
Revert "Regen potfiles"
This reverts commit 4d98c966f8.
Revert "DIGEST: Makefile.*"
This reverts commit 78ef6ab03f.
Revert "DIGEST: calculation"
This reverts commit 5243990191.
Revert "DIGEST: ldlang.*: add timestamp"
This reverts commit bd9466d4aa.
Revert "DIGEST: ldmain.c"
This reverts commit c8f8653fa7.
Revert "DIGEST: ldgram.y"
This reverts commit d73c01be26.
Revert "DIGEST: ldlex.l"
This reverts commit 48b5163a9d.
Revert "DIGEST: testsuite"
This reverts commit a4135d1a48.
Revert "DIGEST: Documentation"
This reverts commit 3ec28966c3.
Revert "DIGEST: NEWS"
This reverts commit 099bf2927d.
Revert "DIGEST: LICENSING"
This reverts commit 5c8a0c6654.
Logic exists to deal with prereqs or prereqs, and in many cases
transitive prereqs are already not spelled out explicitly. Drop further
ones:
- FP is already a prereq to F16,
- SIMD and F16 are already prereqs to COMPNUM, and
- SVE2 and BFLOAT16 are already prereqs to SME.
Before altering how build_modrm_byte() works, arrange for this part of
the testcase to actually use distinguishable source and destination
register numbers, such that incorrect propagation of, in particular, the
high bit encodings (from REX to VEX) can be noticed (in turn
specifically assertions [not] triggering in the respective code).
Put it in optimize_disp() such that it can then be re-used by .insn
handling. The movement makes it necessary (or at least very desirable,
to avoid introducing a fragile cast) to convert to local variable to
"unsigned", which in turn requires an adjustment to the pre-existing
loop header.
Having the caller pass in the specific template under consideration has
another benefit then: We can replace the two uses of current_templates
in the function as well, thus no longer looking at some merely "related"
template. (This may allow further tightening, but if so that's to be the
subject of another change.)
This is benign for all existing insns, but is going to be needed for
handling of .insn operands. The earlier use requires moving up the
function, to avoid the need for a forward declaration.
Fix another case of oss-fuzz tripping over gas static state,
ie. starting over testing another input file with rubbish left
uncleared in bss. size_end_sym pointed at garbage.
* ehopt.c (get_cie_info): Delete forward declaration.
(struct frame_data): Move to file scope.
(frame): New static, packaged..
(check_eh_frame): ..eh_frame_data and debug_frame_data.
(eh_begin): New function.
* as.c (gas_init): Call eh_begin.
* as.h (eh_begin): Declare.
Fix test-case gdb.threads/pending-fork-event-detach.exp for target board
remote-gdbserver-on-localhost using gdb_remote_download for $touch_file_bin.
Then, fix the test-case for target board remote-stdio-gdbserver with
REMOTE_TMPDIR=~/tmp.remote-stdio-gdbserver by creating $touch_file_path
on target using remote_download, and using the resulting path.
Tested on x86_64-linux.
objdump's read_section is never used for bss-style sections, so to
plug a hole that fuzzers have found, exclude sections without
SEC_HAS_CONTENTS.
* objdump.c (read_section): Report and return an error on
a no contents section.
This:
.struct -1
x:
.fill 1
y:
results in an internal error in frag_new due to abs_section_offset
wrapping from -1 to 0. Frags in the absolute section don't do much so
I think we can allow the address wrap.
* frags.c (frag_new): Allow address wrap in absolute section.
With test-case gdb.threads/multiple-successive-infcall.exp and target board
native-gdbserver I run into:
...
(gdb) continue^M
Continuing.^M
[New Thread 758.759]^M
^M
Thread 1 "multiple-succes" hit Breakpoint 2, main () at \
multiple-successive-infcall.c:97^M
97 thread_ids[tid] = tid + 2; /* prethreadcreationmarker */^M
(gdb) FAIL: gdb.threads/multiple-successive-infcall.exp: thread=5: \
created new thread
...
The problem is that the new thread message doesn't match the regexp, which
expects something like this instead:
...
[New Thread 0x7ffff746e700 (LWP 570)]^M
...
Fix this by accepting this form of new thread message.
Tested on x86_64-linux.
With test-case gdb.threads/thread-specific-bp.exp and target board
native-gdbserver I run into:
...
(gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=off: thread 1 selected
continue^M
Continuing.^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
^M
Thread 1 "thread-specific" hit Breakpoint 4, end () at \
thread-specific-bp.c:29^M
29 }^M
(gdb) FAIL: gdb.threads/thread-specific-bp.exp: non_stop=off: \
continue to end (timeout)
...
The problem is that the test-case tries to match the "[Thread ... exited]"
message which we do see with native testing:
...
Continuing.^M
[Thread 0x7ffff746e700 (LWP 7047) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
...
The fact that the message is missing was reported as PR remote/30129.
We could add a KFAIL for this, but the functionality the test-case is trying
to test has nothing to do with the message, so it should pass. I only added
matching of the message in commit 2e5843d87c ("[gdb/testsuite] Fix
gdb.threads/thread-specific-bp.exp") to handle a race, not realizing doing so
broke testing on native-gdbserver.
Fix this by matching the "Thread-specific breakpoint $decimal deleted" message
instead.
Tested on x86_64-linux.
