Complement commit 6999161a2a ("Move readline to the readline/readline
subdirectory") and update the path to readline config.{sub,guess} files
documented in MAINTAINERS.
* MAINTAINERS: Update path to readline config.{sub,guess} files.
Complement commit ae52f48306 ("Add MIPS r3 and r5 support.") and get
changes for config.sub to recognize MIPS CPU patterns for the R3 and R5
ISA levels, used by GAS to set defaults in gas/configure.ac. Oddly, R6
ISA support has been correctly added already.
/
* config.guess: Import from upstream.
* config.sub: Likewise.
readline/
* readline/support/config.guess: Import from upstream.
* readline/support/config.sub: Likewise.
tui_win_info::refresh_window first redraws the background window, then
tui_wrefresh draws the python text on top of it, which flickers.
By using wnoutrefresh for the background window, the actual drawing on
the screen is only done once, without flickering.
gdb/ChangeLog:
2021-05-24 Hannes Domani <ssbssa@yahoo.de>
* python/py-tui.c (tui_py_window::refresh_window):
Avoid flickering.
Add '@:' after 'e.g.' to let texinfo know that this is not the end of
a sentence. This is only needed when there's a space immediately
after the last '.'.
gdb/doc/ChangeLog:
* gdb.texi (Initialization Files): Add '@:' after 'e.g.'.
(Source Path): Likewise.
(GDB/MI Development and Front Ends): Likewise.
(ARM Features): Likewise.
(gdb man): Likewise.
This patch clarify the following invalid combinations of march and mabi,
* ilp32f/lp64f abi without f extension.
* ilp32d/lp64d abi without d extension.
* ilp32q/lp64q abi without q extension.
* e extension with any abi except ilp32e
GNU assembler reports errors when finding the above invalid combinations.
But LLVM-MC reports warnings and ignores these invalid cases. It help to
set the correct ilp32/lp64/ilp32e abi according to rv32/rv64/rve. This
looks good and convenient, so perhaps we can do the same things. However,
if you don't set the mabi, GNU assembler also try to set the suitable
ABI according to march/elf-attribute. Compared to LLVM-MC, we will choose
double/quad abi if d/f extension is set.
gas/
PR 25212
* config/tc-riscv.c (riscv_set_abi_by_arch): If -mabi isn't set, we
will choose ilp32e abi for rv32e. Besides, report errors for the
invalid march and mabi combinations.
* testsuite/gas/riscv/mabi-attr-rv32e.s: New testcase. Only accept
ilp32e abi for rve extension.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64f.d: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64f.l: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.d: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.l: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.q: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.q: Likewise.
Renamed all mabi testcases to their march-mabi settings.
The cleanup to use BFD_VMA_FMT also adjusted this line, but used the
incorrect format: while BFD_VMA_FMT needs an explicit "x", PRIx32 does
not, so the spurious "x" here confused the parser and broke execution.
I misread the code and thought data0/... were bu64 when they were
actually bu32. Fix the call to assemble the 2 64-bit values instead
of passing the 2 halves of the first 64-bit value.
The bfin_otp_write_page_val func wants a pointer to an bu64[2] array,
but this code passes it a pointer to a single bu64. It's in a struct
with a known compatible layout:
bu64 data0, data1, data2, data3;
But gcc doesn't allow these kinds of tricks anymore. Use the more
verbose form to make the compiler happy since this is not performance
sensitive code.
In a linux kernel mailing list discussion, it was mentioned that "gdb has
this odd thing where it takes the 64-bit vs 32-bit data for the whole process
from one thread, and picks the worst possible thread to do it (ie explicitly
not even the main thread, ...)" [1].
The picking of the thread is done here in
x86_linux_nat_target::read_description:
...
/* GNU/Linux LWP ID's are process ID's. */
tid = inferior_ptid.lwp ();
if (tid == 0)
tid = inferior_ptid.pid (); /* Not a threaded program. */
...
To understand what this code does, let's investigate a scenario in which
inferior_ptid.lwp () != inferior_ptid.pid ().
Say we start exec jit-attach-pie, identified with pid x. The main thread
starts another thread that sleeps, and then the main thread waits for the
sleeping thread. So we have two threads, identified with LWP IDs x and x+1:
...
PID LWP CMD
x x ./jit-attach-pie
x x+1 ./jit-attach-pie
...
[ The thread with LWP x is known as the thread group leader. ]
When attaching to this exec using the pid, gdb does a stop_all_threads which
iterates over all the threads, first LWP x, and then LWP x+1.
So the state we arrive with at x86_linux_nat_target::read_description is:
...
(gdb) p inferior_ptid
$1 = {m_pid = x, m_lwp = x+1, m_tid = 0}
...
and consequently we probe 64/32-bitness from thread LWP x+1.
[ Note that this is different from when gdb doesn't attach but instead
launches the exec itself, in which case there's just one thread to begin with,
and consequently the probed thread is LWP x. ]
According to aforementioned remark, a better choice would have been the main
thread, that is, LWP x.
This patch implement that choice, by simply doing:
...
tid = inferior_ptid.pid ();
...
The fact that gdb makes a per-process permanent choice for 64/32-bitness is a
problem in itself: each thread can be in either 64 or 32 bit mode, and change
forth and back. That is a problem that this patch doesn't fix.
Now finally: why does this matter in the context of the linux kernel
discussion? The discussion was related to a patch that exposed io_uring
threads to user-space. This made it possible that one of those threads would
be picked out to select 64/32-bitness. Given that such threads are atypical
user-space threads in the sense that they don't return to user-space and don't
have a userspace register state, reading their registers returns garbage, and
so it could f.i. occur that in a 64-bit process with all normal user-space
threads in 64-bit mode, the probing would return 32-bit.
It may be that this is worked-around on the kernel side by providing userspace
register state in those threads such that current gdb is happy. Nevertheless,
it seems prudent to fix this on the gdb size as well.
Tested on x86_64-linux.
[1] https://lore.kernel.org/io-uring/CAHk-=wh0KoEZXPYMGkfkeVEerSCEF1AiCZSvz9TRrx=Kj74D+Q@mail.gmail.com/
gdb/ChangeLog:
2021-05-23 Tom de Vries <tdevries@suse.de>
PR tdep/27822
* target.h (struct target_ops): Mention target_thread_architecture in
read_description comment.
* x86-linux-nat.c (x86_linux_nat_target::read_description): Use
pid to determine if process is 64-bit or 32-bit.
* aarch64-linux-nat.c (aarch64_linux_nat_target::read_description):
Same.
* ppc-linux-nat.c (ppc_linux_nat_target::read_description): Same.
* riscv-linux-nat.c (riscv_linux_nat_target::read_description): Same.
* s390-linux-nat.c (s390_linux_nat_target::read_description): Same.
* arm-linux-nat.c (arm_linux_nat_target::read_description): Same.
Likewise, use pid to determine if kernel supports reading VFP
registers.
The official name for Loongson Architecture is LoongArch, it is better
to use LoongArch instead of Loongson Loongarch for EM_LOONGARCH to avoid
confusion and keep consistent with the various of software in the future.
The official documentation in Chinese:
http://www.loongson.cn/uploadfile/cpu/LoongArch.pdf
The translated version in English:
https://loongson.github.io/LoongArch-Documentation/
binutils/
* readelf.c (get_machine_name): Change Loongson Loongarch to
LoongArch.
include/
* elf/common.h (EM_LOONGARCH): Change Loongson Loongarch to
LoongArch.
The comments in the enum cmdarg_kind were using -sx and -sex instead
of -eix and -eiex.
(Note that gdb --help does not speak about these options).
(pushed as obvious)
This patch is aimed at the many places in dwarf2.c that blindly
increment a data pointer after calling functions that are meant to
read a fixed number of bytes. The problem with that is with damaged
dwarf we might increment a data pointer past the end of data, which is
UB and complicates (ie. bugs likely) any further use of that data
pointer. To fix those problems, I've moved incrementing of the data
pointer into the functions that do the reads. _bfd_safe_read_leb128
gets the same treatment for consistency.
* libbfd.c (_bfd_safe_read_leb128): Remove length_return parameter.
Replace data pointer with pointer to pointer. Increment pointer
over bytes read.
* libbfd-in.h (_bfd_safe_read_leb128): Update prototype.
* elf-attrs.c (_bfd_elf_parse_attributes): Adjust to suit. Be
careful not to increment data pointer past end. Remove now
redundant pr17512 check.
* wasm-module.c (READ_LEB128): Adjust to suit changes to
_bfd_safe_read_leb128.
* dwarf2.c (read_n_bytes): New inline function, old one renamed to..
(read_blk): ..this. Allocate and return block. Increment bfd_byte**
arg.
(read_3_bytes): New function.
(read_1_byte, read_1_signed_byte, read_2_bytes, read_4_bytes),
(read_8_bytes, read_string, read_indirect_string),
(read_indirect_line_string, read_alt_indirect_string): Take a
byte_byte** arg which is incremented over bytes read. Remove any
bytes_read return. Rewrite limit checks to compare lengths
rather than pointers.
(read_abbrevs, read_attribute_value, read_formatted_entries),
(decode_line_info, find_abstract_instance, read_ranges),
(read_rnglists, scan_unit_for_symbols, parse_comp_unit),
(stash_comp_unit): Adjust to suit. Rewrite limit checks to
compare lengths rather than pointers.
* libbfd.h: Regenerate.
...gold/gc.h:250:37: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: [-Werror]
250 | (*secvec).push_back(Section_id(NULL, 0));
| ^~~~~~~~~~~~~~~~~~~
PR gold/27815
* gc.h (gc_process_relocs): Use nullptr in Section_id constructor.
32-bit MIPS programs run on the 64-bit simulator model in 64-bit
sign-extended space. The mapping from 64-bit sign-extended addresses to
32-bit addresses was removed by commit
26f8bf63bf, breaking the 64-bit simulator
model. Add shadow mappings from 64-bit sign extended address space to
32-bit address spaces, in lieu of the AddressTranslation function.
2021-05-04 Faraz Shahbazker <fshahbazker@wavecomp.com>
sim/mips/ChangeLog:
* interp.c (sim_open): Add shadow mappings from 32-bit
address space to 64-bit sign-extended address space.
64-bit BFD for MIPS applies a standard sign extension on all addresses
assuming 64-bit target. These bits are required for 64-bit and can only
be safely truncated for 32-bit target models. This partially reverts commit
b36d953bce
The sign-extension logic modeled by BFD is an integral part of the
MIPS64 architecture spec. It appears in the virtual address map, where
sign extension allows for 32-bit compatibility segments [1] with 64-bit
addressing. Truncating these addresses prematurely (commit
models (-DWITH_TARGET_WORD_BITSIZE=64).
In the ISA itself, direct addressing (Load-Upper-Immediate) and indirect
addressing (Load-Word) both automatically sign-extend their results. These
instructions regenerate the sign-extended addresses even if we don't start
with one (see pr gdb/19447).
Moreover, some instructions like ADD*/SUB* have unpredictable behaviour when
an operand is not correctly sign extended [3]. This affects PC-relative
addressing in particular, so arithmetic on the link-address generated in the
return address register by a jump-and-link is no longer possible, neither is
the use of the PC-relative addressing instructions provided by MIPSR6.
[1] "MIPS64 Architecture for Programmers Volume III: The MIPS64
Privileged Resource Architecture", Document Number: MD00091,
Revision 6.02, December 10, 2015, Section 4.3 "Virtual Address
Spaces", pp. 29-31
https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00091-2B-MIPS64PRA-AFP-06.03.pdf
[2] "MIPS64 Architecture for Programmers Volume II-A: The MIPS64
Instruction Set Reference Manual", Document Number: MD00087,
Revision 6.06, December 15, 2016, Section 3.2 "Alphabetical
List of Instructions", pp. 321
https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00087-2B-MIPS64BIS-AFP-6.06.pdf
[3] "MIPS64 Architecture for Programmers Volume II-A: The MIPS64
Instruction Set Reference Manual", Document Number: MD00087,
Revision 6.06, December 15, 2016, Section 3.2 "Alphabetical
List of Instructions", pp. 56
https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00087-2B-MIPS64BIS-AFP-6.06.pdf
2021-04-23 Faraz Shahbazker <fshahbazker@wavecomp.com>
sim/mips/ChangeLog:
* interp.c (sim_create_inferior): Only truncate sign extension
bits for 32-bit target models
.
clang 11 fails to compile the static assertion as it cannot compute
the pointer value at a compile time:
gdb/sim/d10v/interp.c:1149:37: error: static_assert expression is not an integral constant expression
static_assert ((uintptr_t) &State == (uintptr_t) &State.regs,
~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Instead, assert that the offset of State.regs is 0.
sim/d10v/ChangeLog:
* interp.c (sim_create_inferior): Use offsetof in static
assertion.
Add target board cc-with-gnu-debuglink.exp that splits off debuginfo into a
seperate .debug file and links to it using .gnu_debuglink.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-21 Tom de Vries <tdevries@suse.de>
PR testsuite/25047
* contrib/cc-with-tweaks.sh: Handle -l.
gdb/testsuite/ChangeLog:
2021-05-21 Tom de Vries <tdevries@suse.de>
PR testsuite/25047
* boards/cc-with-gnu-debuglink.exp: New file.
The test in gdb.dwarf2/dw2-inline-with-lexical-scope.c fails with icc.
The reason is, icc did not emit code for a dead statement, which in
turn caused some labels to be collapsed. Fix this by replacing the
dead code with assignment to a global value. The statement itself
does not change the test scenario.
Also fix a whitespacing problem around an assignment operator.
gdb/testsuite/ChangeLog:
2021-05-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.dwarf2/dw2-inline-with-lexical-scope.c (func): Replace
a dead code with an assignment to a global var. Fix a
whitespacing problem around an assignment operator.
Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
which we can compile into llvm byte code using clang:
...
$ clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf test.c
...
and then run using lli, which uses the llvm jit:
...
$ lli test.ll
...
If we run this under gdb, we run into an assert:
...
$ gdb -q -batch -ex run --args /usr/bin/lli test.ll
Dwarf Error: Cannot not find DIE at 0x18a936e7 \
[from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
src/gdb/jit.c:1178: internal-error: \
void jit_event_handler(gdbarch*, objfile*): \
Assertion `jiter->jiter_data != nullptr' failed.
...
This is caused by the following.
When running jit_breakpoint_re_set_internal, we first handle
libLLVM.so.10.debug, and set a jit breakpoint.
Next we handle libLLVM.so.10:
...
(gdb) p the_objfile.original_name
$42 = 0x2494170 "libLLVM.so.10"
...
but the minimal symbols we find are from libLLVM.so.10.debug:
...
(gdb) p reg_symbol.objfile.original_name
$43 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug"
(gdb) p desc_symbol.objfile.original_name
$44 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug"
...
and consequently, the objf_data is the one from libLLVM.so.10.debug:
...
jiter_objfile_data *objf_data
= get_jiter_objfile_data (reg_symbol.objfile);
...
and so we hit this:
...
if (objf_data->cached_code_address == addr)
continue;
...
and no second jit breakpoint is inserted.
Subsequently, the jit breakpoint is triggered and handled, but when finding
the symbol for the breakpoint address we get:
...
(gdb) p jit_bp_sym.objfile.original_name
$52 = 0x2494170 "libLLVM.so.10"
...
The assert 'jiter->jiter_data != nullptr' triggers because it checks
libLLVM.so.10 while the one with jiter_data setup is libLLVM.so.10.debug.
This fixes the assert:
...
jiter_objfile_data *objf_data
- = get_jiter_objfile_data (reg_symbol.objfile);
- = get_jiter_objfile_data (the_objfile);
...
but consequently we'll have two jit breakpoints, so we also make sure we don't
set a jit breakpoint on separate debug objects like libLLVM.so.10.debug.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-21 Tom de Vries <tdevries@suse.de>
PR breakpoint/27889
* jit.c (jit_breakpoint_re_set_internal): Skip separate debug
objects. Call get_jiter_objfile_data with the_objfile.
I guess this was used with the old VEC implementation, but there is no
reason to have this typedef anymore.
gdb/ChangeLog:
* linespec.c (linespec_p): Remove. Replace all uses with
"linespec *".
Change-Id: I4cea59ae1cd46985da9c08d3a69686846b1ad028
In cli/cli-script.c, process_next_line() allocates memory
which will eventually end up being assigned to the 'next'
field in struct command_line. However, in a case
recurse_read_control_structure returns 'invalid_control'
this memory is leaked. This commit uses std::unique_ptr
as appropriate to prevent this leakage.
This issue was found by coverity scanning.
gdb/ChangeLog:
* cli/cli-script.h (command_line_up): New unique_ptr typedef.
* cli/cli-script.c (multi_line_command_p): Use unique_ptr
command_line_up instead of struct command_line.
(build_command_line): Likewise.
(get_command_line): Update the cmd function call parameter.
(process_next_line): Use unique_ptr command_line_up instead
of struct command_line.
(recurse_read_control_structure): Change the the type of
next to command_line_up.
(read_command_lines_1): Change type of `next' to be
command_line_up and update all references of `next'
accordingly.
* config/tc-z80.c (emit_data_val): Warn on constant overflow.
(signed_overflow): New function.
(unsigned_overflow): New function.
(is_overflow): Use new functions.
(md_apply_fix): Use signed_overflow.
* testsuite/gas/z80/ez80_adl_suf.d: Fix test.
* testsuite/gas/z80/ez80_isuf.s: Likewise.
* testsuite/gas/z80/ez80_z80_suf.d: Likewise.
I built GDB with `--enable-targets=all`, then started GDB passing it
an x86-64 executable, finally I ran 'maint selftest', and observed GDB
crash like this:
BFD: BFD (GNU Binutils) 2.36.50.20210519 assertion fail ../../src/bfd/hash.c:438
Aborted (core dumped)
The problem originates from two locations, for example in csky-dis.c
(csky_get_disassembler) where we do this:
const char *sec_name = NULL;
...
sec_name = get_elf_backend_data (abfd)->obj_attrs_section;
if (bfd_get_section_by_name (abfd, sec_name) != NULL)
...
We end up in here because during the selftests GDB forces the
architecture to be csky, but the BFD being accessed is still of type
x86-64. As a result obj_attrs_section returns NULL, which means we
end up passing NULL to bfd_get_section_by_name. If we follow the
function calls from bfd_get_section_by_name we eventually end up in
bfd_hash_hash, which asserts that the string (i.e. the name) is not
NULL.
The same crash can be reproduced in GDB without using the selftests,
for example:
(gdb) file x86_64.elf
(gdb) start
(gdb) set architecture csky
(gdb) disassemble main
Dump of assembler code for function main:
BFD: BFD (GNU Binutils) 2.36.50.20210519 assertion fail ../../src/bfd/hash.c:438
Aborted (core dumped)
The fix I propose here is to have bfd_get_section_by_name return NULL
if name is ever NULL. For consistency I updated
bfd_get_section_by_name_if in the same way, even though I'm not
hitting any problems along that code path right now.
I looked through the source tree and removed two NULL checks in
bfd/dwarf2.c which are no longer needed, its possible that there are
additional NULL checks that could be removed, I just didn't find them.
bfd/ChangeLog:
* section.c (bfd_get_section_by_name): Return NULL if name is
NULL.
(bfd_get_section_by_name_if): Likewise.
* dwarf2.c (read_section): Remove unneeded NULL check.
(find_debug_info): Likewise.
When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into:
...
src/sim/ppc/hw_memory.c: In function 'hw_memory_init_address':
src/sim/ppc/hw_memory.c:194:75: error: pointer targets in passing \
argument 4 of 'device_find_integer_array_property' differ in signedness \
[-Werror=pointer-sign]
int nr_cells
= device_find_integer_array_property(me, "available", 0, &dummy);
^
...
Fix this by changing the type of dummy.
Add a powerpc64-prologue testcase, this is based on the existing
powerpc-prologue test, but updated for the powerpc64 (le) target.
YYYY-MM-DD Will Schmidt <will_schmidt@vnet.ibm.com>
gcc/testsuite/ChangeLog
* gdb.arch/powerpc64-prologue.c: New test to exercise prologues
for the powerpc64 LE target.
* gdb.arch/powerpc-prologue.exp: Test Harness.
clang 11 with libc++'s <algorithm> fails to match the existing
operator<() for std::less<> since the method is not marked const.
gdb/ChangeLog:
* dwarf2/read.c (tu_abbrev_offset::operator<): Mark const.
When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into:
...
src/sim/ppc/hw_phb.c: In function 'hw_phb_attach_address':
src/sim/ppc/hw_phb.c:315:12: error: comparison between \
'attach_type {aka enum _attach_type}' and \
'enum <anonymous>' [-Werror=enum-compare]
if (type != hw_phb_normal_decode
^~
...
Fix this by casting type to hw_phb_decode.
When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into:
...
src/sim/ppc/emul_netbsd.c: In function 'do_gettimeofday':
src/sim/ppc/emul_netbsd.c:770:16: error: null argument where non-null \
required (argument 1) [-Werror=nonnull]
int status = gettimeofday((t_addr != 0 ? &t : NULL),
^~~~~~~~~~~~
...
Fix this by unconditionally passing &t as first argument.
These methods are just trivial wrappers around the versions accepting
a char pointer. By moving them to the header the compiler can inline
them.
gdb/ChangeLog:
* ui-out.c (ui_out::field_string): Move to ui-out.h.
(ui_out::text): Ditto.
* ui-out.h (class ui_out): Add definitions of
ui_out::field_string and ui_out::text which were previously
defined in ui-out.c.
When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into:
...
In file included from src/sim/ppc/cpu.h:26:0,
from src/sim/ppc/mon.c:25,
from src/sim/ppc/inline.c:64,
from idecode.c:26:
src/sim/ppc/device.h:788:8: error: 'device_event_queue_deschedule' \
declared 'static' but never defined [-Werror=unused-function]
(void) device_event_queue_deschedule
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
This seems to be caused by the fact that the function is declared using
INLINE_EVENT instead of INLINE_DEVICE.
Fix this and a similar error in the same file.
When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into:
...
In file included from src/sim/ppc/cpu.h:251:0,
from src/sim/ppc/emul_generic.h:24,
from src/sim/ppc/emul_generic.c:24:
src/sim/ppc/cpu.c:76:1: error: 'cpu_create' defined but not used \
[-Werror=unused-function]
cpu_create(psim *system,
^~~~~~~~~~
...
The function is defined as:
...
INLINE_CPU\
(cpu *)
cpu_create(psim *system,
...
which expands to:
...
static cpu * __attribute__((__unused__))
cpu_create(psim *system,
...
The problem is that gcc does not associate the attribute to the function.
I've filed a PR about this ( PR gcc/100670 ), which may or may not be valid.
Work around/fix this by modifying the INLINE_* definitions in inline.h to move
UNUSED to the start such that we have:
...
__attribute__((__unused__)) static cpu *
cpu_create(psim *system,
...
gas/ChangeLog:
2021-05-19 John Buddery <jvb@cyberscience.com>
PR 25599
* config/tc-ia64.c (emit_one_bundle): Increment fixup offset
by one for PCREL60B relocation on HP-UX.
gdb/ChangeLog:
* ui-out.h (class ui_out): Add ui_out::text accepting a constant
reference to a std::string. Fix all callers using
std::string::c_str.
* ui-out.c (ui_out::text): Ditto.
This commit:
commit ecf25064e8
Date: Thu May 13 15:42:20 2021 +0100
gdb: fix pretty printing max depth behaviour
Introduced a couple of duplicate tests, this commit resolves them by
providing unique test names.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-pretty-print.exp: Add test names to resolve
duplicate test names.
