Guinevere Larsen [Wed, 29 Jan 2025 12:31:03 +0000 (09:31 -0300)]
gdb: Remove stabs support from XCOFF inferiors
This commit is the second to last in the series fully removing support
for stabs in GDB, removing it from XCOFF inferiors. According to IBM's
AIX documentation[1], xcoff binaries can only have stabs or DWARF debug
info, meaning removing stabs seems pretty trivial, as anything that
isn't related to setting base information on the objfile or reading
dwarf can be removed.
Guinevere Larsen [Tue, 28 Jan 2025 11:47:02 +0000 (08:47 -0300)]
gdb: Remove stabs support for COFF files
This commit continues the removal of stabs by removing support from coff
inferiors. This is trivial for the most part, just a removal of code
setting things only relevant for stabs. A couple of things could do with
some explanations:
The global variables symnum and within_function were kept (and
within_function was converted to boolean). I looked into making them
parameters to the relevant function, but this would require changes to
several otherwise untouched functions, so I kept them as globals
instead.
Reading coff debuginfo also uses a symbol chain similar to stabsread's
global_sym_chain. WIP: NEED TO FIX THIS PART.
Guinevere Larsen [Wed, 22 Jan 2025 17:05:01 +0000 (14:05 -0300)]
gdb: Remove stabs support from ELF files
This commit makes it so that GDB won't read stabs information from ELF
files. If stabs is detected in an ELF file, the reader now warns the user
that stabs is not supported.
This test would cause two new failures in the test gdb.stabs/weird.exp
(that surprisingly didn't happen in the mips commit). Rather than fixing
the test that'll be removed soon, I just removed the test instead.
Guinevere Larsen [Tue, 14 Jan 2025 17:28:18 +0000 (14:28 -0300)]
gdb/mdebug: Remove stabs support from mips inferiors
Ostensibly, the mdebugread.c is about reading debug information in the
ecoff format, but it also supports stabs-in-ecoff according to comments
in there, and also relied in some stabs facilities for ecoff reading
itself. This commit takes the first step in removing stabs support by
removing those dependencies from mdebug. And in order to support
stabs-in-ecoff, mipsread would also call stabsread_new_init.
Removing stabs-in-ecoff is trivial, as the code was well demarcated with
comments mentioning where stabs was read. Plus the call to
stabsread_new_init in mipsread can be trivially removed.
Another simple removal was the dependence on stabs_end_psymtabs: because
the local variables dependencies_used and includes_used were only touched
by stabs-reading code, they are always 0 in the new version, which means
we can find the exact code path that'd be followed in stabs_end_psymtab
and move the relevant lines to mdebug instead.
After all those, the last remaining dependency is when reading a fortran
common block from an inferior compiled by SGI fortran compilers (and
maybe more). The block could have no address, meaning it'd need to be
fixed after all the minimal symbols have been read. This was done by
adding the symbol to the stabs global_sym_chain, then calling
scan_file_globals to fix them up. This commit copies all the necessary
code for handling the fortran symbols onto mdebug, technically making
some code duplication, but since stabsread will be removed soon, this
shouldn't be too concerning.
This change was tested in the compile farm's mips64 machine (number
230), where it actually seems to have solved some 50 failures in the
testsuite, not including changes in tests from gdb.threads, as those are
often very racy. I'm not sure if these were true fixes or racy cases,
but since the new version has no newly introduced fails, only fewer of
them, I'm inclined to think this change is at least harmless.
Guinevere Larsen [Tue, 28 Jan 2025 18:45:10 +0000 (15:45 -0300)]
gdb: move some stabs functions to gdbsupport/common-utils.h
The gdb/stabsread.h and .c files define 2 things that, while originally
intended only for stabs reading, actually end up being used for coff,
ecoff and maybe more debuginfo formats. That is the function "hashname",
and the macro HASHSIZE. Both are used for small hashtables when reading
some symbols with incomplete information.
With the upcoming removal of stabs code, this code should be moved
somewhere, and the only location that looked mildly reasonable was
gdbsupport/common-utils. No change is expected after this commit.
Guinevere Larsen [Mon, 13 Jan 2025 17:04:04 +0000 (14:04 -0300)]
gdb: Deprecate stabs debug info
GCC has deprecated stabs generation in GCC 12 and entirely removed it in
GCC 13, which was released in April 2023. At the time it was proposed
that GDB deprecate stabs as well, but the decision was to support it a
bit longer. With this patch, it'll be deprecated on GDB 17, and removed
on GDB 18, which following the current cadence, will be released early
2026, meaning we will have supported stabs for nearly 3 years longer
than GCC, which I think is reasonable.
As pointed out in the previous discussion on this topic[1], there are
several existing issues on the code, and none of the current maintainers
knows how to fix it. Unless someone steps up to fix this before the
removal on GDB 18, I don't see why we should keep this old code that
breaks all conventions of modern debuginfo readers and doesn't even
work, instead of being able to further advance adjacent code.
Finally, deprecating and removing stabs will make a.out/dbx inferiors be
essentially unsupported, as the only debuginfo GDB supports for those
formats is stabs, meaning users would only have assembly-level debugging
for that format. With that in mind, this commit deprecates the a.out/dbx
format as well.
Tom Tromey [Mon, 13 Jan 2025 17:39:50 +0000 (10:39 -0700)]
Fix gdb.ada/import.exp when using mold
We found that the gdb.ada/import.exp test fails when 'mold' is used as
the linker. This happens because mold decides to mark most of the
symbols in the executable as being file-local. I tend to think this
choice, while non-traditional, is probably fine. So, this patch fixes
the problem by changing the relevant Ada code to look for file-local
symbols as well.
Furthermore, there are two overloads of lookup_minimal_symbol_linkage
that both have a final 'bool' parameter -- but with radically
different meanings. This patch somewhat clears up this confusion as
well.
highlighted the following issue with GDB's 'x' packet implementation.
Unfortunately, LLDB also has an 'x' packet, but their implementation
is different to GDB's and so targets that have implemented LLDB's 'x'
packet are incompatible with GDB.
The above thread is specifically about the 'rr' tool, but there could
be other remote targets out there that have this problem.
The difference between LLDB and GDB is that GDB expects a 'b' prefix
on the reply data, while LLDB does not. The 'b' is important as it
allows GDB to distinguish between an empty reply (which will be a 'b'
prefix with no trailing data) and an unsupported packet (which will be
a completely empty packet). It is not clear to me how LLDB
distinguishes these two cases.
I propose that we add a new feature 'binary-upload' which can be
reported by a stub in its qSupported reply. By default this feature
is "off", meaning GDB will not use the 'x' packet unless a stub
advertises this feature.
I have updated gdbserver to send 'binary-upload+', and when I examine
the gdbserver log I can see this feature being sent back, and then GDB
will use the 'x' packet.
When connecting to an older gdbserver, the feature is not sent, and
GDB does not try to use the 'x' packet at all.
I also built the latest version of `rr` and tested using current HEAD
of master, where I see problems like this:
(rr) x/10i main
0x401106 <main>: Cannot access memory at address 0x401106
Then tested using this patched version of GDB, and now I see:
Guinevere Larsen [Thu, 23 Jan 2025 19:42:53 +0000 (16:42 -0300)]
gdb/configure: fail configure if all targets requested with 32bit bfd
As PR sim/28684 explains, it isn't possible to compile GDB with all
targets enabled and not enabling 64 bit bfd. In 64 bit hosts, 64 bit bfd
is forced, so the build works, but in 32 bit hosts, that has to be
explicitly enabled.
I ran into this when I tried compiling GDB on a mips64 machine running a
32 bit OS. Along with the errors in the PR, several other architectures
are also required, notably aarch64 and other explicitly 64bit targets.
Additionally, some 32 bit files required for the gdb mips target aren't
added to the makefile.
Considering the last comment in the bug says this isn't going to be
fixed on the binutils side, I didn't think it was worth trying to fix
the GDB side. Instead, this commit causes the configure script to fail
if all targets were requested and 64 bit bfd isn't enabled. If that is
ever fixed, we can revert this commit.
I considered adding this to the top level configure script, but couldn't
figure out how to detect the situation in there, so this was my next
best idea.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28684 Approved-by: Kevin Buettner <kevinb@redhat.com>
Jens Remus [Mon, 27 Jan 2025 15:48:58 +0000 (16:48 +0100)]
s390: Error if vector index register omitted in assembly
Vector index registers are currently only used in the VRV instruction
format. Unlike general purpose index registers an operand value of
zero (e.g. %v0, 0, or omitted) does not imply a zero value:
"For VRV format instructions, a vector element is used in the formation
of the intermediate value. This vector element is an unsigned binary
integer value that is added to the base address and 12-bit displacement
to form a 64-bit intermediate sum. The vector element is designated by
a vector register and an element index. A zero V field accesses the
element in vector register zero and does not imply a zero value." [1]
Therefore require vector index register operands to be specified in
assembler source. That is do require coding of D(VX,B) instead of
allowing to omit VX=0 as D(,B), D(B), or D. Emit an error message if
a mandatory vector index register is omitted:
Error: operand <n>: missing vector index register operand
Note that this change is not backwards compatible. But any code that
omitted the specification of the vector index register is likely to be
in error. Therefore it is favorable to report an error than to stay
backward compatible.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
gas/
* config/tc-s390.c (md_gather_operands): Do not allow
vector index register operands to be optionally omitted.
gas/testsuite/
* gas/s390/zarch-base-index-0.d (vgef): Remove tests with
omitted vector index register operands.
* gas/s390/zarch-base-index-0.s (vgef): Move tests with omitted
vector index register operands ...
* gas/s390/zarch-base-index-0-err.s (vgef): ... to here.
* gas/s390/zarch-base-index-0-err.l (vgef): Expect error
for omitted vector index register operands.
* gas/s390/zarch-omitted-base-index.d (vgef): Remove tests with
omitted vector index register operands.
* gas/s390/zarch-omitted-base-index.s (vgef): Move tests with
omitted vector index register operands ...
* gas/s390/zarch-omitted-base-index-err.s (vgef): ... to here.
* gas/s390/zarch-omitted-base-index-err.l (vgef): Expect error
for omitted vector index register operands.
* gas/s390/zarch-warn-areg-zero.l (vgef): Remove tests with
omitted vector index register operands.
* gas/s390/zarch-warn-areg-zero.s (vgef): Likewise.
Jens Remus [Mon, 27 Jan 2025 15:48:58 +0000 (16:48 +0100)]
s390: Do not warn about vector index register 0 in assembly
Vector index registers are currently only used in the VRV instruction
format. Unlike general purpose index registers an operand value of
zero (e.g. %v0, 0, or omitted) does not imply a zero value:
"For VRV format instructions, a vector element is used in the formation
of the intermediate value. This vector element is an unsigned binary
integer value that is added to the base address and 12-bit displacement
to form a 64-bit intermediate sum. The vector element is designated by
a vector register and an element index. A zero V field accesses the
element in vector register zero and does not imply a zero value." [1]
Therefore when using s390-specific assembler option "-mwarn-areg-zero"
do not warn if vector index register 0 is specified.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
gas/
* config/tc-s390.c (md_gather_operands): Do not warn about
vector index register 0.
gas/testsuite/
* gas/s390/zarch-warn-areg-zero.l (vgef): Do not expect warning
about vector index register 0.
Jens Remus [Mon, 27 Jan 2025 15:48:58 +0000 (16:48 +0100)]
s390: Do not omit vector index register 0 in disassembly
Vector index registers are currently only used in the VRV instruction
format. Unlike general purpose index registers an operand value of
zero (e.g. %v0, 0, or omitted) does not imply a zero value:
"For VRV format instructions, a vector element is used in the formation
of the intermediate value. This vector element is an unsigned binary
integer value that is added to the base address and 12-bit displacement
to form a 64-bit intermediate sum. The vector element is designated by
a vector register and an element index. A zero V field accesses the
element in vector register zero and does not imply a zero value." [1]
Therefore do not omit vector index register 0 in disassembly, that is
disassemble D(VX,B) with VX=0 as D(VX,B) instead of D(B). Also do not
disassemble index register 0 as "0", that is disassemble D(VX,B) with
VX=0 as D(%v0,B) instead of D(0,B). Note that a base register 0 still
still gets disassembled as "0", that is D(VX,B) with B=0 disassembles
into D(VX,0).
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
opcodes/
* s390-dis.c (s390_print_insn_with_opcode): Do not omit vector
index register 0 in disassembly. Disassemble it as %v0.
gas/testsuite/
* gas/s390/zarch-base-index-0.d (vgef): Expect vector index
register 0 in disassembly.
* gas/s390/zarch-omitted-base-index.d (vgef): Likewise.
Jens Remus [Mon, 27 Jan 2025 15:47:10 +0000 (16:47 +0100)]
s390: Generate .eh_frame unwind information for .plt section
Enable unwinding using .eh_frame information through PLT entries. Based
on x86-64.
This enhances stack traces if the instruction pointer is in a PLT entry.
For instance perf call graphs, when using --call-graph=dwarf, and Glibc
backtraces, when using backtrace() e.g. from a signal handler.
Note that GDB could already unwind through PLT entries using its s390-
specific prologue unwinder.
Furthermore this lays the foundation to generate SFrame information for
the PLT section in the future.
bfd/
* elf64-s390.c: Include dwarf2.h.
(PLT_CIE_SIZE, PLT_FDE_SIZE,
PLT_FDE_START_OFFSET, PLT_FDE_LEN_OFFSET,
elf_s390x_eh_frame_plt): New .eh_frame template for .plt
section.
(elf_s390_link_hash_table): Add plt_eh_frame field.
(elf_s390_create_dynamic_sections): New s390-specific wrapper
around _bfd_elf_create_dynamic_sections. Create .eh_frame
section for .plt section.
(elf_backend_create_dynamic_sections): Register s390-specific
elf_s390_create_dynamic_sections.
(elf_s390_late_size_sections): Fill in .eh_frame section for
.plt section. Write .plt section size into .eh_frame FDE
covering .plt section.
(elf_s390_finish_dynamic_sections): Write .plt section start
into .eh_frame FDE covering .plt section. Call
_bfd_elf_write_section_eh_frame on on htab->plt_eh_frame
section.
ld/
* NEWS: Add news entry.
* emulparams/elf64_s390.sh: Include plt_unwind.sh.
ld/testsuite/
* ld-s390/plt_64-1_eh.wf: New PLT .eh_frame generation test.
* ld-s390/s390.exp: Link some existing test cases with
--no-ld-generated-unwind-info so that they do not fail. Run
new PLT .eh_frame generation test.
Jens Remus [Mon, 27 Jan 2025 15:47:10 +0000 (16:47 +0100)]
s390: Add basic PLT generation tests
ld/testsuite/
* ld-s390/plt_31_non-pic-1.pd: New non-PIC/PIE PLT generation
test for 31-bit.
* ld-s390/plt_31_pic-1.pd: New PIC/PIE PLT generation test for
31-bit.
* ld-s390/plt_31-1.wf: New PLT generation test for 31-bit.
* ld-s390/plt_64-1.pd: New PLT generation test for 64-bit.
* ld-s390/plt_64-1.wf: Likewise.
* ld-s390/plt-1.s: New PLT generation test for 31/64-bit.
* ld-s390/pltlib.s: Likewise.
* ld-s390/s390.exp: Run new PLT generation tests.
Jens Remus [Mon, 27 Jan 2025 15:43:39 +0000 (16:43 +0100)]
s390: s390_machine leak
Simplify the .machine directive parsing logic, so that cpu_string is
always xstrdup'd and can therefore always be xfree'd before returning
to the caller.
This resolves the following memory leak reported by ASAN:
Direct leak of 13 byte(s) in 3 object(s) allocated from:
#0 0x3ff8aafbb1d in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x2aa338861cf in xmalloc ../../libiberty/xmalloc.c:149
#2 0x2aa338868ff in xstrdup ../../libiberty/xstrdup.c:34
#3 0x2aa320253cb in s390_machine ../../gas/config/tc-s390.c:2172
#4 0x2aa31fddc7b in read_a_source_file ../../gas/read.c:1293
#5 0x2aa31f4f7bf in perform_an_assembly_pass ../../gas/as.c:1223
#6 0x2aa31f4f7bf in main ../../gas/as.c:1436
#7 0x3ff8a02be35 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x3ff8a02bf33 in __libc_start_main_impl ../csu/libc-start.c:360
#9 0x2aa31f5758f (/home/jremus/git/binutils/build-asan/gas/as-new+0x2d5758f) (BuildId: ...)
While at it add tests with double quoted .machine
"<cpu>[+<extension>...]" values.
gas/
* config/tc-s390.c (s390_machine): Simplify parsing and free
cpu_string before returning.
Jens Remus [Mon, 27 Jan 2025 15:43:39 +0000 (16:43 +0100)]
s390: s390_machinemode leak
This resolves the following memory leak reported by ASAN:
Direct leak of 17 byte(s) in 1 object(s) allocated from:
#0 0x3ffb32fbb1d in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x2aa149861cf in xmalloc ../../libiberty/xmalloc.c:149
#2 0x2aa149868ff in xstrdup ../../libiberty/xstrdup.c:34
#3 0x2aa1312391f in s390_machinemode ../../gas/config/tc-s390.c:2241
#4 0x2aa130ddc7b in read_a_source_file ../../gas/read.c:1293
#5 0x2aa1304f7bf in perform_an_assembly_pass ../../gas/as.c:1223
#6 0x2aa1304f7bf in main ../../gas/as.c:1436
#7 0x3ffb282be35 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x3ffb282bf33 in __libc_start_main_impl ../csu/libc-start.c:360
#9 0x2aa1305758f (/home/jremus/git/binutils/build-asan/gas/as-new+0x2d5758f) (BuildId: ...)
gas/
* config/tc-s390.c (s390_machinemode): Free mode_string before
returning.
Tom de Vries [Mon, 27 Jan 2025 15:38:32 +0000 (16:38 +0100)]
[gdb/build] Fix build with gcc 7.5.0
When building gdb with gcc 7.5.0, I run into:
...
gdb/dwarf2/cooked-index.c: In lambda function:
gdb/dwarf2/cooked-index.c:104:5: error: \
the value of ‘_sch_tolower’ is not usable in a constant expression
};
^
In file included from gdbsupport/gdb-safe-ctype.h:47:0,
from gdb/dwarf2/cooked-index.c:34:
include/safe-ctype.h:111:29: note: ‘_sch_tolower’ was not declared ‘constexpr’
extern const unsigned char _sch_tolower[256];
^~~~~~~~~~~~
...
This does not happen with gcc 8.2.1.
Fix this by dropping the constexpr on lambda function munge in
cooked_index_entry::compare for gcc 7.
Tom de Vries [Mon, 27 Jan 2025 11:39:56 +0000 (12:39 +0100)]
[gdb/doc] Use more lower-case in @sc in the documentation
When building gdb with an older makeinfo (4.13), I run into:
...
gdb/doc/gdb.texinfo:49064: warning: @sc argument all uppercase, thus no effect.
...
Using a grep, I found one more instance:
...
$ grep @sc gdb/doc/*.tex* | egrep -v '@sc{[^A-Z]*}'
gdb/doc/gdb.texinfo:\
Bit 1 (@sc{ZA}) shows whether the @code{ZA} register state is active (in use) or
gdb/doc/python.texi:\
corresponding @sc{GDB/MI} command's output. Refer to the
...
Fix this by using lowercase letters in the @sc argument, similar to how that
was done in commit c96452ad168 ("Use lower-case in @sc in the documentation").
Tom de Vries [Mon, 27 Jan 2025 10:22:12 +0000 (11:22 +0100)]
[gdb/doc] Fix qIsAddressTagged anchor
When building gdb with an older makeinfo (4.13), I run into:
...
gdb/doc/gdb.texinfo:44159: @anchor expected braces.
gdb/doc/gdb.texinfo:44159: ` {qIsAddressTagged}
...
This is related to this line:
...
@anchor {qIsAddressTagged}
...
Fix this by removing the space before the left brace.
Tom de Vries [Mon, 27 Jan 2025 09:33:28 +0000 (10:33 +0100)]
[gdb/doc] Fix gdb.unwinder docs
When building gdb with an older makeinfo (4.13), I run into:
...
gdb/doc/python.texi:3015: warning: `(' follows defined name \
`gdb.unwinder.Unwinder.__init__' instead of whitespace.
gdb/doc/python.texi:3041: warning: `(' follows defined name \
`gdb.unwinder.FrameId.__init__' instead of whitespace.
...
The warnings are related to these two lines:
...
@defun gdb.unwinder.Unwinder.__init__(name)
...
@defun gdb.unwinder.FrameId.__init__(sp, pc, special = @code{None})
...
Indeed, when checking the command and variable index, we can see that it
contains an incorrect entry:
...
gdb.unwinder.FrameId.__init__(sp,: Unwinding Frames in Python
...
Fix this by adding a space before the left parenthesis.
Tested by rebuilding the documentation and checking the command and variable
index.
Exclude libpthread from automatic export generation
Before this change, static linking libwinpthread, commonly distributed
as part of Mingw-w64, while using automatic symbol exports would export
the entire threading API, which is never wanted. This is always the case
when static linking libstdc++ built against libpthread.
Alan Modra [Sun, 26 Jan 2025 02:42:45 +0000 (13:12 +1030)]
loongson buffer overflow
bfd_elfNN_loongarch_set_data_segment_info can be called from the target
after_allocation function with a non-ELF hash table. This is seen in
the ld-elf pr21884 testcase. Fix the problem by first checking the
hash table type before writing to a loongarch_elf_hash_table field.
Tom Tromey [Sat, 28 Dec 2024 21:10:56 +0000 (14:10 -0700)]
Fix C++ template function matching in cooked index
In commit 64a97606 ("Support template lookups in
strncmp_iw_with_mode"), gdb was changed so that a command like "break
func<templ>" would match instantiations like "func<templ<int>>".
The new indexer does not support this and so this is a regression.
This went unnoticed because gdb.linespec.cpcompletion.exp puts all
these functions into the main file, and this CU is expanded early.
This patch fixes the bug by changing the cooked index entry comparison
function. It also updates the test to fail without this fix.
gdb/riscv: Add command to switch between numeric & abi register names
In RISC-V, the general registers can be shown in their abi
form (e.g. sp, a0) or their numeric form (e.g. x2, x10).
Depending on context/preference, someone may prefer to
see one form over the other. The disassembler already
supports this configuration, which can be changed using
the 'set disassembler-options numeric' command.
This commit adds a new set/show command to change gdb's
preference: 'set riscv numeric-registers-names on/off'.
If on, 'info registers' and other situations will print
the numeric register names, rather than the abi versions.
The alias generation has been modified so that the abi
versions are still available for access if specifically
requested such as 'print $ra'. This was done by changing
the behaviour of the code which adds the aliases: all
register names will be added as aliases, even if the name
is the primary one.
There is also no functional downside to adding aliases
which are surplus-to-requirement, since they will be
ignored if there is a 'true' register with the same
name.
Tom de Vries [Fri, 24 Jan 2025 15:43:52 +0000 (16:43 +0100)]
[gdb/tdep] Fix gdb.ada/O2_float_param.exp on s390x-linux
With test-case gdb.ada/O2_float_param.exp on s390x-linux, I get:
...
(gdb) frame^M
#0 callee.increment (val=99.0, val@entry=<error reading variable: \
register has not been saved in frame>, msg=...) at callee.adb:19^M
19 procedure Increment (Val : in out Float; Msg: String) is^M
(gdb) FAIL: $exp: scenario=all: frame
...
The frame command calls read_frame_arg to get:
- the current value of val, and
- the value of val at function entry.
The first scenario succeeds, and the second scenario fails.
For context and contrast, let's also investigate the first scenario: getting
the current value of val.
Function parameter val:
...
<2><b51>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<b52> DW_AT_name : val
<b58> DW_AT_type : <0xb86>
<b5c> DW_AT_location : 0xab (location list)
...
has location list:
... 000000ab00000000010029280000000001002967
(DW_OP_reg16 (f0)) 000000be00000000010029670000000001002968
(DW_OP_reg24 (f8)) 000000d100000000010029680000000001002974
(DW_OP_GNU_regval_type: 24 (f8) <0xb29>;
DW_OP_GNU_const_type: <0xb29> 4 byte block: 3f 80 0 0 ; DW_OP_plus;
DW_OP_stack_value) 000000ef00000000010029740000000001002982
(DW_OP_GNU_entry_value: (DW_OP_GNU_regval_type: 16 (f0) <0xb29>);
DW_OP_GNU_const_type: <0xb29> 4 byte block: 3f 80 0 0 ; DW_OP_plus;
DW_OP_stack_value) 0000010f <End of list>
...
and since we're stopped at address 0x1002928:
...
(gdb) print $pc
$1 = (access procedure) 0x1002928 <callee.increment>
...
we get the value from dwarf register 16.
The s390x ABI [1] specifies that dwarf register 16 maps onto 8-byte register
f0 or 16-byte register v0 (where f0 is part of v0), and in this case (because
the v0 register is available) s390_dwarf_reg_to_regnum maps it to v0.
Val is only 4 bytes:
...
(gdb) ptype val
type = <4-byte float>
...
and s390_value_from_register takes care to get the value from the correct part
of v0.
The value of v0 is found in the prologue cache, and the value of parameter val
is printed.
Now the second scenario: getting the value of val at function entry.
FWIW, since we're stopped at function entry, we could simply return the same
value, reading the same register, but that's currently not implemented [2].
Instead we start from the fact that val is in dwarf reg 16 at function entry,
and then use call site information:
...
<4><cf7>: Abbrev Number: 13 (DW_TAG_GNU_call_site)
<cf8> DW_AT_low_pc : 0x1002a46
<d00> DW_AT_abstract_origin: <0xdda>
<5><d04>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter)
<d05> DW_AT_location : 1 byte block: 60 (DW_OP_reg16 (f0))
<d07> DW_AT_GNU_call_site_value: 3 byte block: f5 18 2d \
(DW_OP_GNU_regval_type: 24 (f8) <0xc42>)
<5><d0b>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter)
...
to conclude that the value we're looking for is in dwarf reg 24, which
s390_dwarf_reg_to_regnum maps to v8.
As before, s390_value_from_register takes care to get the value from the
correct part of v8.
However, v8 is not available in the prologue cache, and we take a different
path and end up in s390_unwind_pseudo_register, where v8 and similar
(regnum_is_vxr_full) is unhandled, and we get:
...
return value::allocate_optimized_out (type);
...
which eventually causes the "error reading variable: register has not been
saved in frame".
Fix this by handling the regnum_is_vxr_full case in
s390_unwind_pseudo_register, similar to how that is done in
s390_pseudo_register_read.
Tom de Vries [Fri, 24 Jan 2025 15:37:36 +0000 (16:37 +0100)]
[gdb/testsuite] Record less in gdb.reverse/time-reverse.exp
While stepping through gdb.reverse/time-reverse.exp I realized that we're
recording the instructions for resolving the PLT entries for functions time
and syscall, while that's not really the focus of the test-case.
Limit the scope of the test, by calling the functions once before starting
to record.
Also call "info record" after recording to make it clear how many
instructions were recorded.
On x86_64-linux, before this patch (but with info record added), we have:
...
$ grep "Log contains" gdb.log
Log contains 750 instructions.
Log contains 1218 instructions.
...
and with this patch we have:
...
$ grep "Log contains" gdb.log
Log contains 24 instructions.
Log contains 19 instructions.
...
Richard Earnshaw [Thu, 23 Jan 2025 10:53:54 +0000 (10:53 +0000)]
aarch64: Fix PLT fixups when BTI is used [PR32572]
PR ld/32572
There are two problems addressed in this PR. Firstly, the choice of
whether or not a PLT stub needs a BTI on entry was too strict,
resulting in non-pie executables not having a BTI on their stub. But
secondly, the logic to handle each stub types did not agree across the
various places where this information is used.
The first issue is fixed by using bfd_link_executable rather than
bfd_link_pde. The second is addressed by recording a delta for PLT
stub alongside the stub itself. This is then used without needing
additional logic later on since it has been pre-calculated.
A more comprehensive fix would involve creating a data structure to
describe each fixup, including a call-back function to apply any
relocations. But that's a fairly large change and not appropriate for
backporting.
Jan Beulich [Fri, 24 Jan 2025 09:26:46 +0000 (10:26 +0100)]
x86-64: tighten convert-load-reloc checking
Even if the assembler avoids using relaxable relocations for
inapplicable insns, such relocations can still appear for other reasons.
Be more thorough in the opcode checking we do, to avoid bogusly altering
other insns.
Furthermore correct an opcode mask (even if with the added condition
that's now fully benign).
Jan Beulich [Fri, 24 Jan 2025 09:26:02 +0000 (10:26 +0100)]
x86/APX: widen @gotpcrel and @gottpoff support (incl to MOVRS)
If legacy-encoded arithmetic insns are eligible for @gotpcrel
relaxation, EVEX-encoded ones ought to be, too.
Further anything that MOV-from-memory can be used for (and transformed
from) should then also extend to MOVRS.
While extending the apx-load* testcases add -mrelax-relocations=yes to
the two ones which were missing this: Without this option the intended
testing would not occur on configurations defaulting the option to off.
Jose E. Marchesi [Thu, 23 Jan 2025 19:16:09 +0000 (20:16 +0100)]
bfd: fix generation of bfd.texi in out-of-tree builds
[In the sequel TS means $(top_srcdir) and TB means $(top_builddir)]
The Texinfo file TS/bfd/doc/bfd.texi @includes many other .texi files
such as:
bfdt.texi
bfdio.texi
section.texi
...
These .texi files are generated from the bfd/*.c source files, by a
program called `chew' that is distributed along with BFD, via some
default rules and macro magic in TS/bfd/doc/local.mk. Important
point: the .texi files are generated in TB/bfd/doc/, not TS/bfd/doc.
Where %D% is 'doc/' in this case. Now, it looks like the directory
containing the .texi file is automatically inserted in the @include
search path, so the -I %D% above places TB/bfd/doc _after_ TS/bfd/doc.
Since currently TS/bfd/doc/bfdt.texi is outdated and is missing some
nodes, the error above happens.
This patch changes bfd/doc/local.mk to use -P to prepend the current
build directory to the @include search path, rather than -I, which
appends it.
bfd/ChangeLog:
2025-01-23 Jose E. Marchesi <jose.marchesi@oracle.com>
* doc/local.mk (AM_MAKEINFOFLAGS): Prepend the build directory to
the @include search path.
* Makefile.in: Regenerate.
Function bar is an inlined function, and consequently we cannot return from
it:
...
(gdb) b bar
Breakpoint 1 at 0x4006ac: file return-3.c, line 25.
(gdb) r
Starting program: return-3
...
Breakpoint 1, bar () at return-3.c:25
25 c++;
(gdb) return
Can not force return from an inlined function.
(gdb)
...
However, function foo is not an inline function, and we should be able to
return from it, but we get the same error message:
...
(gdb) up
31 bar ();
(gdb) return
Can not force return from an inlined function.
(gdb)
...
Fix this by using the selected frame rather than the current frame in
return_command, such that we get instead:
...
(gdb) up
31 bar ();
(gdb) return
40 printf ("%d\n", c);
(gdb)
...
ld: fix alignment issue for ARM thumb long branch stub using PureCode section
When pure-code option is activated. The linker creates for M-profile architecures
a 2-bytes branch instruction. This causes the section alignment to be set to 2-byte
alignment instead of 4-byte alignment. This is a problem for long branch stub
without pure-code section as it contains a 32-bit address as data, which is expected
to be 4-byte aligned. Hence creating a long branch stub for PureCode section followed
by a long branch stub will result in a misalignment for the 32-bit address.
An easy fix is to add a nop instruction after the branch to keep the section alignment
to 4 bytes.
Alan Modra [Wed, 22 Jan 2025 23:54:46 +0000 (10:24 +1030)]
ld plugin bfd_make_readable leak
bfd_make_readable leaks memory that could be freed by
_free_cached_info except that does too much in releasing all bfd
memory. (The fact that we had to hack around keeping the bfd filename
also indicates that releasing all bfd memory was too much.) So this
patch moves code releasing bfd_alloc'd memory to the COFF
_free_cached_info, where the syms and suchlike are released. This is
the memory that archive handling wants to release in the call there to
bfd_free_cached_info.
* coffgen.c (_bfd_coff_free_cached_info): Release syms.
* opncls.c (_bfd_new_bfd): Correct error return path.
(_bfd_free_cached_info): Don't kill all abfd->memory.
(_bfd_delete_bfd): Adjust fallback for bfd_free_cached_info.
(bfd_make_readable): Call target bfd_free_cached_info and
_bfd_free_cached_info plus reinstate section_htab.
Alan Modra [Wed, 22 Jan 2025 23:53:48 +0000 (10:23 +1030)]
ld compact eh-frame leak
u.compact.extries wasn't being freed anywhere. Free it when
destroying the linker hash table. Also free u.dwarf.aray there in
case errors result in the linker not getting to the slightly earlier
free in write_dwarf_eh_frame_hdr.
* elf-eh-frame.c (write_dwarf_eh_frame_hdr): Don't exit without
freeing u.dwarf.array.
* elflink.c (_bfd_elf_link_hash_table_free): Free u.compact.entries
and u.dwarf.array.
Alan Modra [Tue, 21 Jan 2025 21:19:56 +0000 (07:49 +1030)]
unusual eh_frame memory leak
This one happens with --gc-sections and a linker script that either
discards some or all .eh_frame sections (eg. ld-elf/pr14265 test) or
maps an input .eh_frame to some other named output section. In that
case the discarded/renamed .eh_frame won't have local_cies freed.
Alan Modra [Tue, 21 Jan 2025 04:11:54 +0000 (14:41 +1030)]
More ld testsuite fixes
* testsuite/ld-elf/indirect.exp: Run compiler capability checks
using run_host_noleak.
* testsuite/ld-ifunc/ifunc.exp: Don't exit without restoring
ASFLAGS. Don't run ifuncmod5 twice.
Tom Tromey [Thu, 9 Jan 2025 20:08:49 +0000 (13:08 -0700)]
Remove gnatmake_version_at_least
This removes gnatmake_version_at_least in favor of using the more
flexible gnat_version_compare. I think these two version numbers
should be the same, as gnatmake is shipped with the compiler.
There is still a problem building the bfd docs from a release tar
file.
As the release tar file contains the pre-generated .texi files we
expect the bfd/doc build stage to symlink to the pre-existing .texi
files in the source tree.
However, this is still not working as expected if $(srcdir) is
relative. The problem is this line in REGEN_TEXI:
test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \
This is executed from the build/bfd/ directory, so if $(srcdir) is
relative, then this will get you from the bfd/ directory in the build
tree to the corresponding bfd/ directory in the src tree. However,
the symlink is created in the bfd/doc/ build directory. The relative
path will then fail to take you to the bfd/ directory in the src
tree.
Fix this by using $(abs_srcdir) when creating the symlink.
Tom de Vries [Wed, 22 Jan 2025 09:46:08 +0000 (10:46 +0100)]
[gdb/testsuite] Fix gdb.base/branch-to-self.exp on arm-linux
On arm-linux (ubuntu 24.04 with gcc 13.3.0) with target board unix/-marm and
test-case gdb.base/branch-to-self.exp I run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
0x0040058c 38 for (;;); /* loop-line */^M
(gdb) FAIL: $exp: single-step: si
...
In contrast, on the same machine but with debian testing and gcc 14.2.0 we have:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: stepi
...
The difference is in the instruction(s) generated for the loop.
In the passing case, we have:
...
588: eafffffe b 588 <main+0x24>
...
and in the failing case:
...
588: e320f000 nop {0}
58c: eafffffd b 588 <main+0x24>
...
The purpose of this part of the test-case is to:
- generate a branch instruction that jumps to itself, and
- set a breakpoint on it, and check that stepi-ing from that breakpoint
triggers the breakpoint again.
As we can see, in the failing case we failed to generate a branch instruction
that jumps to itself, and consequently we cannot expect to hit the breakpoint
again after issuing a single si.
Fix this by issuing stepi until we hit the breakpoint.
Jan Beulich [Wed, 22 Jan 2025 08:51:23 +0000 (09:51 +0100)]
x86/Solaris: correct support for Sun form of CMOV<size>.S
PR gas/32579
The deprecated .s (swapped operand encoding) functionality got in the
way of properly recognizing this specific form. Move the Solaris-
specific code ahead of that.
Tom de Vries [Tue, 21 Jan 2025 14:23:19 +0000 (15:23 +0100)]
[gdb/symtab] Fix gdb.base/fission-macro.exp with unix/-m32
When running test-case gdb.base/fission-macro.exp on openSUSE Tumbleweed
(using gcc 14) with target board unix/-m32, I get:
...
(gdb) info macro FIRST^M
Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:0^M
-DFIRST=1^M
(gdb) FAIL: $exp: \
dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
...
instead of the expected:
...
(gdb) info macro FIRST^M
Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:18^M
(gdb) PASS: $exp: \
dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
...
A dwarf-5 .debug_str_offsets section starts with a header consisting of:
- an initial length (4 bytes for 32-bit and 12 bytes for 64-bit),
- a 2 byte version string, and
- 2 bytes padding
so in total 8 bytes for 32-bit and 16 bytes for 64-bit.
This offset is calculated here in dwarf_decode_macros:
...
str_offsets_base = cu->header.addr_size;
...
which is wrong for both dwarf-5 cases (and also happens to be wrong for
dwarf-4).
Fix this by computing str_offsets_base correctly for dwarf-5, for both the
32-bit and 64-bit case.
Likewise, fix this for dwarf-4, using str_offsets_base 0. We can only test
this with gcc-15, because gcc 14 and earlier don't have the fix for
PR debug/115066.
Tested on x86_64-linux.
Tested test-case using a current gcc trunk build, and gcc 14.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/31897
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31897
Alan Modra [Sat, 18 Jan 2025 12:09:05 +0000 (22:39 +1030)]
Support broken gcc test for gas string merge support
On casual reading of older gcc configure scripts it might be supposed
that the test for gas string merge support tries with %progbits after
a fail on ARM with @progbits. It doesn't succeed due to a bug. So to
support building of older gcc's for ARM without users having to edit
gcc sources, add a hack to gas. The hack can disappear in a few years
when building older gcc's likely requires other work too.
I've changed the docs to reflect what we actually allow for .section
syntax prior to this patch. (No way should this hack be documented as
allowed!)
PR 32491
* config/obj-elf.c (obj_elf_section): Allow missing entsize
for ARM gcc configure bug.
* doc/as.texi: Correct syntax of ELF .section directive.
* testsuite/gas/elf/string.s,
* testsuite/gas/elf/string.d: Test it.
Alan Modra [Sat, 18 Jan 2025 11:51:03 +0000 (22:21 +1030)]
run_dump_test warning/error regexp
This allows you to specify a run_dump_test warning that may or may not
be present using
warning: (warning_text_goes_here)?
ie. the regexp matches an empty string.
Alan Modra [Mon, 20 Jan 2025 07:28:00 +0000 (17:58 +1030)]
asan ld builds without detect_leaks=0
I found that building binutils with -fsanitize=address,undefined
results in much of the testsuite not being run. The problem is that
running gcc results in linker plugin memory leaks which of course are
errors, so the testsuite sees this as lack of compiler support.
* testsuite/lib/ld-lib.exp (run_host_noleak): New proc.
(check_compiler_available, check_lto_available),
(check_lto_fat_available, check_lto_shared_available),
(check_ifunc_available, check_ifunc_attribute_available),
(check_libdl_available, check_gnu2_tls_available),
(compile_one_cc): Use run_host_noleak.
* testsuite/config/default.exp (compiler_supports): Likewise.
Guinevere Larsen [Mon, 20 Jan 2025 12:20:59 +0000 (09:20 -0300)]
gdb/testsuite: Fix file location for gdb.base/backtrace-through-cu-nodebug
The newly added test gdb.base/backtrace-through-cu-nodebug.exp had a
problem in the call to gdb_compile, that caused the .o files to be
outputted in the GDB file tree. This commit fixes the issues in the calls.
Reported-By: Tom de Vries <tdevries@suse.de> Approved-By: Tom de Vries <tdevries@suse.de>
Richard Earnshaw [Fri, 17 Jan 2025 15:03:47 +0000 (15:03 +0000)]
gas: elf: Relax rules for SHF_STRING sections
Commit af3394d97a8c5187085c0eec5fb03e8da88db5fb allowed sections
declared with "S" (SHF_STRING) to specify the entity size, but then
would warn if the entity size was omitted, as with the old syntax.
Unfortunately, since specifying the entity size is incompatible with
binutils 2.43 or earlier, this makes it impossible to specify a
strings section in source code without generating an assembly warning
(the new syntax isn't supported in older assemblers and the old syntax
generates warnings).
Nevertheless, the old code was wrong in that it did not set the entity
size at all, in contravention of the ELF specification (though to date
there are no known cases where this mattered outside of mergeable
sections).
Fix this by permitting the original syntax without a warning again,
but by defaulting the entity size to 1. This is compatible with the
most common case of strings being byte-based.
Added some tests for the various flavours of declaration that we
support.
Alan Modra [Mon, 20 Jan 2025 07:11:56 +0000 (17:41 +1030)]
ldelf_before_allocation leak
ldelf_before_allocation is passed the audit and depaudit strings built
from command line args, then possibly adds to the depaudit string,
freeing the original. The new string isn't freed. Fix this leak by
keeping the string attached to the static vars.
* ldelf.c (ldelf_before_allocation): Pass char** for audit
and depaudit. Adjust uses.
* ldelf.h (ldelf_before_allocation): Update prototype.
* gld${EMULATION_NAME}_before_allocation: Update call.
Alan Modra [Sat, 18 Jan 2025 22:05:22 +0000 (08:35 +1030)]
_bfd_elf_get_dynamic_symbols
This fixes an error path in _bfd_elf_get_dynamic_symbols, fixes the
minimum size required when reading DT_HASH header, and tidies
formatting in a few places. Nit-fixes all.
Very likely we shouldn't be trying to mmap DT_DYNAMIC as it won't be
large enough for the mmap size threshold.
* elf.c (_bfd_elf_get_dynamic_symbols): Use _bfd_munmap_temporary
in error return path rather than free. Corrent size passed to
offset_from_vma when reading DT_HASH header. Formatting.
Tom de Vries [Mon, 20 Jan 2025 04:41:01 +0000 (05:41 +0100)]
[gdb/testsuite] Fix gdb.cp/non-trivial-retval.exp on arm-linux with gcc 13
On arm-linux, with target board unix/-mthumb, we get:
...
(gdb) PASS: gdb.cp/non-trivial-retval.exp: continue to breakpoint: Break here
p f1 (i1, i2)^M
$1 = {a = -136274256}^M
(gdb) FAIL: gdb.cp/non-trivial-retval.exp: gdb-command<p f1 (i1, i2)>
...
This is not a problem with the inferior call, which works fine:
...
(gdb) p f1 (23, 100)
$3 = {a = 123}
...
but instead it's a problem with the location information:
...
(gdb) p i1
$1 = -136274356
(gdb) p i2
$2 = 100
...
which tells us to find the value of i1 in (DW_OP_fbreg: -12).
The test-case passes if we drop -fvar-tracking, in which case the debug info
tells us to find the value of i1 in (DW_OP_fbreg: -20).
This is with gcc 13.3.0 on Ubuntu 24.04. With gcc 14.2.0 on Debian testing,
the code is the same, but -fvar-tracking does use the correct
'(DW_OP_fbreg: -20)'.
There seems to be some bugfix in -fvar-tracking for gcc 14.
Workaround the bug by using constants 23 and 100 instead of i1 and i2 when
using -fvar-tracking and gcc < 14.
Alan Modra [Mon, 13 Jan 2025 10:03:54 +0000 (20:33 +1030)]
reloc caching
This arranges to free section relocs cached in elf_section_data. To
do that, some relocs stored there need to use bfd_malloc buffers
rather than bfd_alloc ones.
Alan Modra [Sat, 11 Jan 2025 05:50:36 +0000 (16:20 +1030)]
sec->alloced and freeing section contents
This modifies _bfd_elf_free_cached_info to unmap/free section
contents. To do that we need to *not* free sections where contents
are bfd_alloc'd or point to constant strings or somesuch. I've chosen
to implement this be adding another flag to struct bfd_section,
"alloced" to say the section contents can't be freed. Most of the
patch is about setting that flag in many places.
Alan Modra [Sat, 11 Jan 2025 05:49:09 +0000 (16:19 +1030)]
Replace xmalloc with stat_alloc in ld parser
A few place dealing with ld script handling made some attempt to free
memory, but this was generally ignored and would be quite a lot of
work to implement. Instead, use the stat_obstack rather than
mallocing in many more cases.
* ldexp.c (exp_get_fill): Use stat_alloc for fill.
* ldfile.c (ldfile_try_open_bfd): Don't free yylval fields.
* ldgram.y: Replace xmalloc with stat_alloc throughout.
* ldlang.c (stat_memdup, stat_strdup): New functions.
(ldirname): Use stat_memdup. Don't strdup ".".
(output_section_callback_sort): Use stat_alloc.
(output_section_callback_tree_to_list): Don't free.
(lang_memory_region_lookup): Use stat_strdup.
(lang_memory_region_alias): Likewise.
(add_excluded_libs): Use stat_alloc and stat_memdup.
(ldlang_add_undef, ldlang_add_require_defined): Use stat_strdup.
(lang_add_nocrossref, lang_leave_overlay): Use stat_alloc.
(realsymbol): Use stat_strdup for return value and always
free symbol.
(lang_new_vers_pattern, lang_new_vers_node): Use stat_alloc.
(lang_finalize_version_expr_head): Don't free. Delete FIXME.
(lang_register_vers_node): Don't free.
(lang_add_vers_depend): Use stat_alloc.
(lang_do_version_exports_section): Likewise.
(lang_add_unique): Use stat_alloc and stat_strdup.
(lang_append_dynamic_list): Use stat_alloc.
* ldlang.h (stat_memdup, stat_strdup): Declare.
* ldlex.l: Replace xstrdup with stat_strdup throughout.
Replace xmemdup with stat_memdup too.
* lexsup.c (parse_args): Don't free export list or dynamic
list.
Alan Modra [Sat, 18 Jan 2025 00:25:22 +0000 (10:55 +1030)]
Re: binary outsymbols
The "of course to free outsymbols" turned out to be wrong. outsymbols
belongs to objcopy which frees them, so commit 6ca01b0bdd59 introduced
a double free.
Tom Tromey [Fri, 17 Jan 2025 19:01:38 +0000 (12:01 -0700)]
Simplify get_frame_unwind_table
This simplifies get_frame_unwind_table, changing it to use the
registry 'emplace' method and to pass the initialization iterators to
the constructor. This fixes a build problem on x86 -- reported by the
auto-builder -- as a side effect.
Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were
failing. In my machine xmm3 was consistently set to 0x54, but apparently
that is different depending on the system. This commit zeroes out xmm3
at the start of the test instead.
While debugging the test failures, I also noticed an issue where the
recording wasn't saving all the required memory. That happened because
vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to
share code paths, but the latter encodes memory modification size on
VEX.L whereas the former encodes in VEX.pp. So this commit fixed that,
and made the relevant tests more robust and complete.
Andrew Burgess [Sat, 12 Oct 2024 10:08:04 +0000 (11:08 +0100)]
gdb/doc: some more details in the README file
After some recent discussions on the mailing list, I've made some
changes to the README to (I hope) provide more clarity.
The changes I made are:
1. Removed the use of a lone 'HOST' on the configure line. I tried
this and 'configure' gave me a warning:
configure: WARNING: you should use --build, --host, --target
So I don't think this is approved practice any more. We should
encourage users to use `--host` instead.
2. Added and reworded the --host, --target, and --enable-targets
descriptions in the 'configure options' section. My goals here are
to clarify that 'cross-debugging' is really the same as 'remote
debugging', and also to make it clearer what the defaults are.
3. Added some additional text to the 'Remote debugging' section
mentioning that 'remote debugging' is basically the same as 'cross
debugging', given that we use 'cross-debugging' in the text above.
projects / thirdparty / binutils-gdb.git / log
