bfd/ChangeLog:
* coff-rs6000.c (xcoff_reloc_type_noop): Add info argument.
(xcoff_reloc_type_fail): Likewise.
(xcoff_reloc_type_pos): Likewise.
(xcoff_reloc_type_neg): Likewise.
(xcoff_reloc_type_rel): Likewise.
(xcoff_reloc_type_toc): Likewise.
(xcoff_reloc_type_ba): Likewise.
(xcoff_reloc_type_crel): Likewise.
(xcoff_reloc_type_tls): Likewise.
(xcoff_reloc_type_br): Add stub handler.
(xcoff_ppc_relocate_section): Add info to
xcoff_calculate_relocation.
(xcoff_stub_indirect_call_code): New constant.
(xcoff_stub_shared_call_code): Likewise.
(bfd_xcoff_backend_data): Add stub code fields.
(bfd_pmac_xcoff_backend_data): Likewise.
* coff64-rs6000.c (xcoff64_reloc_type_br): Add stub handler.
(xcoff64_ppc_relocate_section): Add info to
xcoff64_calculate_relocation.
(xcoff64_stub_indirect_call_code): New constant.
(xcoff64_stub_shared_call_code): Likewise.
(bfd_xcoff_backend_data): Add stub code fields.
(bfd_xcoff_aix5_backend_data): Likewise.
* libxcoff.h (struct xcoff_backend_data_rec): Add stub fields.
(bfd_xcoff_stub_indirect_call_code): New define.
(bfd_xcoff_stub_indirect_call_size): New define.
(bfd_xcoff_stub_shared_call_code): New define.
(bfd_xcoff_stub_shared_call_size): New define.
(xcoff_reloc_function): Add info argument.
(enum xcoff_stub_type): New enum.
(struct xcoff_stub_hash_entry): New structure.
* xcofflink.c (struct xcoff_link_hash_table): Add stub hash
table and params fields.
(xcoff_stub_hash_entry): New define.
(xcoff_stub_hash_lookup): New define.
(stub_hash_newfunc): New function.
(_bfd_xcoff_bfd_link_hash_table_free): Free the new stub hash
table.
(_bfd_xcoff_bfd_link_hash_table_create): Create the new stub
hash table.
(xcoff_link_add_symbols): Save rawsize for XTY_SD.
(bfd_xcoff_link_init): New function.
(xcoff_stub_csect_name): New function.
(xcoff_stub_get_csect_in_range): New function.
(xcoff_stub_name): New function.
(bfd_xcoff_get_stub_entry): New function.
(bfd_xcoff_type_of_stub): New function.
(xcoff_add_stub): New function.
(xcoff_build_one_stub): New function.
(bfd_xcoff_size_stubs): New function.
(bfd_xcoff_build_stubs): New function.
(xcoff_stub_create_relocations): New function.
(xcoff_link_input_bfd): Adapt relocations to stub.
(xcoff_write_global_symbol): Adapt to new TOC entries generated
for stubs.
(_bfd_xcoff_bfd_final_link): Handle stub file.
* xcofflink.h (struct bfd_xcoff_link_params): New structure.
ld/ChangeLog:
* emultempl/aix.em (params): New variable.
(stub_file): New variable.
(xcoff_add_stub_section): New function.
(xcoff_layout_sections_again): New function
(hook_in_stub): New function.
(_after_allocation): Add stub creation.
(_create_output_section_statements): Allocate stub file and
pass params to backend.
bfd/ChangeLog:
* coff-rs6000.c (_bfd_xcoff_put_ldsymbol_name): Write len in
ldinfo->strings instead of directly in the output_bfd.
* coff64-rs6000.c (_bfd_xcoff64_put_ldsymbol_name): Likewise.
* xcofflink.c (struct xcoff_link_hash_table): Remove ldrel_count
field. Add ldinfo field.
(xcoff_mark_symbol): Adjust to new ldinfo field.
(xcoff_mark): Likewise.
(bfd_xcoff_link_count_reloc): Likewise.
(xcoff_build_loader_section): Split into two functions: one that
build the loader section (this function) and one that only size
it...
(xcoff_size_loader_section): ... (this function).
(bfd_xcoff_size_dynamic_sections): Adapt to new ldinfo field.
Move the part where the dynamic sections are build to ...
(bfd_xcoff_build_dynamic_sections): ... this function.
* xcofflink.h: Add bfd_xcoff_build_dynamic_sections prototype.
include/ChangeLog:
* coff/xcoff.h (struct xcoff_loader_info): Add ldrel_count and
libpath fields.
ld/ChangeLog:
* emultempl/aix.em (_after_allocation): New function.
I noticed that compile-object-load.c directly references owner.symtab
of a symbol. However, I think it's better for all users to call
symbol_symtab. This patch makes this change.
If can't determine prologue from the symbol table, need to examine
instructions. Implement loongarch_scan_prologue() to analyze the
function prologue from START_PC to LIMIT_PC, return the address of
the first instruction past the prologue.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
The register_test_foreach_arch is used to instantiate a given selftest
for all architectures supported by GDB. It is used in many _initialize_*
functions (under initialize_all_files, called by gdb_init).
Because the call is done during GDB's initialization, and because there
is no guaranty about the order in which all the _initialize_* functions
are executed, when register_test_foreach_arch is called, GDB is not
fully initialized. Specifically, when a particular initialize function
is executed, only the architectures registered at that point are listed
by gdbarch_printable_names.
As a consequence, the list of selftest effectively executed depends on
the order the _initialize_* functions are called. This can be observed
with the following:
$ ./gdb/gdb \
-data-directory ./gdb/data-directory \
-quiet -batch -ex "maint selftest" 2>&1 \
| grep -E "Ran [0-9]+ unit tests"
Ran 145 unit tests, 0 failed
$ GDB_REVERSE_INIT_FUNCTIONS=1 ./gdb/gdb \
-data-directory ./gdb/data-directory \
-quiet -batch -ex "maint selftest" 2>&1 \
| grep -E "Ran [0-9]+ unit tests"
Ran 82 unit tests, 0 failed
To fix this, make register_test_foreach_arch register a lazy selftest
generator. This way when the test generator is eventually executed, all
architectures are registered and we do not have a dependency on the
order the initialize functions are executed in.
Tested on x86_64-linux
Change-Id: I88eefebf7d372ad672f42d3a103e89354bc8a925
This patch adds a way to delay the registration of tests until the
latest possible moment. This is intended for situations where GDB needs
to be fully initialized in order to decide if a particular selftest can
be executed or not.
This mechanism will be used in the next patch.
Change-Id: I7f6b061f4c0a6832226c7080ab4e3a2523e1b0b0
Remove the callback-based selftests::for_each_selftest function and use
an iterator_range instead.
Also use this iterator range in run_tests so all iterations over the
selftests are done in a consistent way. This will become useful in a
later commit.
Change-Id: I0b3a5349a7987fbcb0071f11c394e353df986583
The way SAE templates are constructed was always puzzling me (including
the need for separate templates in the first place), and expressing the
extzra attribute via Imm8 actually has a bad effect: Ordinary immediates
would also be accepted, leading to an extra byte being added after the
instruction (i.e. generating bad code). Before re-working this (in
particular to accept proper Intel syntax there), fix the immediate issue
by adding the so far missing check.
For an unclear reason corresponding AVX512F tests were apparently not
cloned or used as reference here, and instead the bogus legacy forms of
the insns (with the embedded rounding specifier not last) were used.
It's not just REX.W which is ignored with opcode 0x90. The same goes for
REX.R and REX.X as well as empty REX. None of these are forms of
"xchg %eax,%eax" (which would mean zero-extending %eax to %rax), so they
also shouldn't be disassembled this way.
While there simplify things: A single hook function suffices, thus
making it unnecessary to keep two expressions in sync. And checking
ins->address_mode for mode_64bit also is unnecessary, as "rex" can be
non-zero only in that case anyway.
To support DWARF 5 in the DWARF assembler line tables, we currently copy
the first user-provided directory and the first user-provided files and
make them elements at indices 0 in the directory and file name tables.
That was a sufficient behavior at the time (see commit 44fda08939
("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in
the following patches, I would need to have finer grained control on
what is generated exactly. For example, I'd like to generate a DWARF 5 line
table with just a single file and a single directory.
Get rid of this behavior, and implement what is suggested in
44fda08939: make include_dir return the directory index that can be
used to refer to that directory entry (based on the DWARF version), and
use it afterwards.
Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly. Their produced
DWARF5 binaries will change a bit, in that they will now have a single
directory and file, where they had two before. But it doesn't change
the expected GDB behavior.
Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b
I'm trying to switch these functions to use std::string instead of char
arrays, as much as possible. Some callers benefit from it (can avoid
doing a copy of the result), while others suffer (have to make one more
copy).
Change-Id: I793aab17baaef8345488f4c40b9094e2695425bc
I'm trying to switch these functions to use std::string instead of char
arrays, as much as possible. Some callers benefit from it (can avoid
doing a copy of the result), while others suffer (have to make one more
copy).
Change-Id: Iced49b8ee2f189744c5072a3b217aab5af17a993
This updates gnulib to a relatively recent commit. Most of this was
done by the gnulib import script; the only change I made was to
update-gnulib.sh.
Tested on x86-64 Fedora 34. I also did a mingw cross build.
PR c++/28907 points out that casting from a derived class to a base
class fails in some situations. The problem turned out to be a
missing use of value_embedded_offset. One peculiarity here is that,
if you managed to construct a pointer-to-derived with an embedded
offset of 0, the cast would work -- for example, one of the two new
tests here passes without the patch.
This embedded offset stuff is an endless source of bugs. I wonder if
it's possible to get rid of it somehow.
Regression tested on x86-64 Fedora 34.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28907
This test attempts to run until the line marked "STOP", which is at
prot.adb:34. It first runs until the "main" symbol, then tries to place
a breakpoint by line at line 34, without specifying the source file. When looking at the logs:
-break-insert -t 34^M
^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x0000555555558a6c",func="adafinal",file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_pro t/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",thread-groups=["i1"],times="0",original-location="/home/simark/b uild/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb:34"}^M
... continues ...
*stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={addr="0x0000555555558a6c",func="adafinal",args=[],file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/ mi_prot/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",arch="i386:x86-64"},thread-id="1",stopped-threads="all",co re="8"^M
... we see that the breakpoint is placed in some generated file, not in
the test source file as we expect. The problem is that "b main" in Ada
does not place a breakpoint on the "Ada main", but on some symbol in a
generated source file. So when stopped at the "main" symbol, we are not
stopped in the file that contains the STOP marker at line 34.
The test passes anyway today, so it doesn't seem to matter that we are
stopped at an unexpected location. But it starts failing with this
patch [1], because b~prot.adb:34 happens to be between two functions, so
the breakpoint doesn't resolve.
Fix this by placing the breakpoint at "$srcfile:$line", which works
regardless of what is the current source file.
However, this ends up introducing a path in the test name. Modify
mi_tbreak and mi_continue_to_line to avoid that.
[1] https://sourceware.org/pipermail/gdb-patches/2022-April/187686.html
Change-Id: I742e2a9993046dcb5e30c64fe2ad920a363baf75
LLVM's lld linker doesn't have the "-Ttext-segment" option, but
"--image-base" can be used instead.
To centralize the logic of checking which option is supported, add the
text_segment option to gdb_compile. Change tests that are currently
using -Ttext-segment to use that new option instead.
This patch fixes only compilation error, for example:
Before:
$ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
gdb compile failed, clang-13: warning: -Xlinker -Ttext-segment=0x7000000: 'linker' input unused [-Wunused-command-line-argument]
After:
$ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ...
FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 2
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: info function ^jit_function
FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 2
FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 1
FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2
=== gdb Summary ===
# of expected passes 26
# of unexpected failures 9
Change-Id: I3678c5c9bbfc2f80671698e28a038e6b3d14e635
The clear command shouldn't delete momentary and internal breakpoints,
nor internal breakpoints created via Python's gdb.Breakpoint.
This patch fixes this issue and adds a testcase.
Regression tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7161
This patch started when I noticed that the unordered_set include
wasn't needed in abbrev-cache.h. (That was probably leftover from
some earlier implementation of the class.) Then, I noticed that the
class itself was under-commented. This patch fixes both issues.
PR cli/17151 points out that "set height 1" has pathological behavior
in gdb. What I see is that gdb will endlessly print the pagination
prompt. This patch takes a simple and expedient approach to a fix:
pretend that the height is really 2.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17151
PR cli/20741 points out that when pagination is disabled, this also
disabled word wrapping. However, the manual documents that these
settings are separate -- if you intend to disable the wrapping, you
must use "set width unlimited".
This patch fixes the bug by letting the pagination-disabled case fall
through to the code that also handles word-wrapping.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20741
This adds an implementation of the value_print method to Rust. As
described in PR rust/22254, this removes a bit of weird-looking output
from some "print"s -- because c_value_print is bypassed. I don't have
a test for the bug that inspired this patch, because I only know how
to reproduce it when using a relatively old Rust compiler. However,
the new "cast-printing" code in value_print is required, because
omitting this causes some existing tests to fail.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22254
The current nightly Rust compiler (aka 1.61) added better DWARF
representation for unsized types. Fixing this is PR rust/21466; but
the code is actually the same as what is required to make slice
printing more useful, which is PR rust/23871. This patch implements
this. I tested this against various Rust compilers: 1.48, current
stable, current beta, and current nightly.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21466
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23871
This removes a bit of dead code from the Rust value printer. This
code wasn't always dead -- it fixed a real bug, and a test case was
added for it. However, once val_print was removed, it became
unnecessary.
The rust_compiler_version proc extracts the Rust compiler version from
the "rustc --version" output. For a beta compiler, the output looks
like:
rustc 1.60.0-beta.6 (7bccde197 2022-03-22)
This patch slightly relaxes the regexp -- removing a space -- so that
this can be understood by this proc.
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
Since score-tdep.c was removed, the WITH_SIM define is not used in
gdb. This patch removes it.
Note that re-running autoheader shows a separate change that was
missed. I've kept it in this patch to avoid extra work.
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
Given:
- The prepare_to_access_memory machinery was added for non-stop mode.
- Only Linux supports non-stop.
- Linux no longer needs the prepare_to_access_memory machinery. In
fact, after the previous patch,
linux_process_target::prepare_to_access_memory became a nop.
Thus, prepare_to_access_memory can go away, simplifying core GDBserver
code.
Change-Id: I93ac8bfe66bd61c3d1c4a0e7d419335163120ecf
Similarly to how the native Linux target was changed
and subsequently reworked in these commits:
05c06f318f Linux: Access memory even if threads are running
8a89ddbda2 Avoid /proc/pid/mem races (PR 28065)
... teach GDBserver to access memory even when the current thread is
running, by always accessing memory via /proc/PID/mem.
The existing comment:
/* Neither ptrace nor /proc/PID/mem allow accessing memory through a
running LWP. */
... is incorrect for /proc/PID/mem does allow that.
Actually, from GDB's perspective, GDBserver could already access
memory while threads were running, but at the expense of pausing all
threads for the duration of the memory access, via
prepare_to_access_memory. This new implementation does not require
pausing any thread, thus
linux_process_target::prepare_to_access_memory /
linux_process_target::done_accessing_memory become nops. A subsequent
patch will remove the whole prepare_to_access_memory infrastructure
completely.
The GDBserver linux-low.cc implementation is simpler than GDB's
linux-nat.c's, because GDBserver always adds the unfollowed vfork/fork
children to the process list immediately when the fork/vfork event is
seen out of ptrace. I.e., there's no need to keep the file descriptor
stored on a side map, we can store it directly in the process
structure.
Change-Id: I0abfd782ceaa4ddce8d3e5f3e2dfc5928862ef61
The next patch in this series adds a common helper routine for both
memory reads and writes, like this:
static int
proc_xfer_memory (CORE_ADDR memaddr, unsigned char *readbuf,
const gdb_byte *writebuf, int len)
{
gdb_assert ((readbuf == nullptr) != (writebuf == nullptr));
...
}
int
linux_process_target::read_memory (CORE_ADDR memaddr,
unsigned char *myaddr, int len)
{
return proc_xfer_memory (memaddr, myaddr, nullptr, len);
}
linux_process_target::write_memory (CORE_ADDR memaddr,
const unsigned char *myaddr, int len)
{
return proc_xfer_memory (memaddr, nullptr, myaddr, len);
}
Surprisingly, the assertion fails. That happens because it can happen
that target_write_memory is called with LEN==0, due to this in
gdb/remote.c:
/* Determine whether the remote target supports binary downloading.
This is accomplished by sending a no-op memory write of zero length
to the target at the specified address. (...) */
void
remote_target::check_binary_download (CORE_ADDR addr)
{
...
p = rs->buf.data ();
*p++ = 'X';
p += hexnumstr (p, (ULONGEST) addr);
*p++ = ',';
p += hexnumstr (p, (ULONGEST) 0);
*p++ = ':';
*p = '\0';
In this scenario, in gdbserver's target_write_memory, the "myaddr"
argument of the_target->write_memory is passed the data() of a local
gdb::byte_vector (which is a specialized std::vector). It's valid for
std::vector::data() to return NULL when the vector is empty.
This commit adds an early return to target_write_memory to avoid
target backends having to care about this. For good measure, do the
same on the read side, in read_inferior_memory.
Change-Id: Iac8f04fcf99014c624ef4036bd318ca1771ad491
handle_qxfer_threads_proper needs to pause all threads even if the
target can read memory when threads are running, so use
target_pause_all instead, which is what the Linux implementation of
prepare_to_access_memory uses. (Only Linux implements this hook.)
A following patch will make the Linux backend be able to access memory
when threads are running, and thus will also make
prepare_to_access_memory do nothing, which would cause testsuite
regressions without this change.
Change-Id: I127fec7246b7c45b60dfa7341e781606bf54b5da
When running the internal AdaCore test suite against the new DWARF
indexer, I found one regression on RISC-V. The test in question uses
--gc-sections, and winds up with an entry in the middle of a
.debug_aranges that has both address and length of 0. In this
scenario, gdb assumes the entries are terminated and then proceeds to
reject the section because it reads a subsequent entry as if it were a
header.
It seems to me that, because each header describes the size of each
.debug_aranges CU, it's better to simply ignore 0,0 entries and simply
read to the end. That is what this patch does.
I've patched an existing test to provide a regression test for this.
Windows 10 introduced SetThreadDescription and GetThreadDescription, a
simpler way to set a thread's name. This changes gdb and gdbserver to
use this convention when it is available.
This is part of PR win32/29050.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050
This patch is a bit different from the rest of the series, in that it
is a change to gdb's behavior on the host. It changes gdb's thread
pool to try to set the thread name on Windows, if SetThreadDescription
is available.
This is part of PR win32/29050.
This patch isn't likely to be useful to many people in the short term,
because the Windows port of the libstdc++ thread code is not upstream.
(AdaCore uses it, and sent it upstream, but it did not land, I don't
know why.) However, if that patch does ever go in, or presumably if
you build using some other C++ runtime library, then this will be
useful.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050
