| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Before the removal of the UST/static-tracepoint support, the
`static_tracepoint_ctx` struct contained comments for its fields,
whereas `fast_tracepoint_ctx` did not. Nevertheless, those comments
also applied to `fast_tracepoint_ctx`. With the removal of
`static_tracepoint_ctx`, the comments were lost, making
`fast_tracepoint_ctx` data members completely commentless. Add back
those comments.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
In gdbserver there are a couple of places where we perform manual
memory management using a 'std::vector<char *>' with the vector owning
the strings within it. We need to take care to call
free_vector_argv() before leaving the scope to cleanup the strings
within the vector.
This commit introduces a new class gdb::argv_vec which wraps around a
'std::vector<char *>' and owns the strings within the vector, taking
care to xfree() them when the gdb::argv_vec is destroyed.
Right now I plan to use this class in gdbserver.
But this class will also be used to address review feedback on this
commit:
https://inbox.sourceware.org/gdb-patches/72227f1c5a2e350ca70b2151d1b91306a0261bdc.1736860317.git.aburgess@redhat.com
where I tried to introduce another 'std::vector<char *>' which owns
the strings. That patch will be updated to use gdb::argv_vec instead.
The obvious question is, instead of introducing this new class, could
we change the APIs to avoid having a std::vector<char *> that owns the
strings? Could we use 'std::vector<std::string>' or
'std::vector<gdb::unique_xmalloc_ptr<char>>' instead?
The answer is yes we could.
I originally posted this larger patch set:
https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com
however, getting a 14 patch series reviewed is just not possible, so
instead, I'm posting the patches one at a time. The earlier patch I
mentioned is pulled from the larger series.
The larger series already includes changes to gdbserver which removes
the need for the 'std::vector<char *>', however, getting those changes
in depends (I think) on the patch I mention above. Hence we have a
bit of a circular dependency.
My proposal is to merge this patch (adding gdb::argv_vec) and make use
of it in gdbserver.
Then I'll update the patch above to also use gdb::argv_vec, which will
allow the above patch to get reviewed and merged.
Then I'll post, and hopefully merge additional patches from my larger
inferior argument series, which will remove the need for gdb::argv_vec
from gdbserver.
At this point, the only use of gdb::argv_vec will be in the above
patch, where I think it will remain, as I don't think that location
can avoid using 'std::vector<char *>'.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The debug output that says a line has been recorded is currently
outside the `if` block which decides if the line should be recorded or
not. This means the debug output will claim the line was recorded,
when actually it wasn't!
Fixed by moving the debug output inside the `if` block.
Should be no user visible changes after this commit (except if debug
output is turned on).
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
This is a preparatory patch to support native linux port
of gdbserver for MicroBlaze
* gdb/features/Makefile : Add microblaze-expedite
* gdb/features/microblaze-linux.xml : New
* gdb/features/microblaze-linux.c : New (generated)
* gdb/regformats/microblaze-linux.dat : New (generated)
Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com>
Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com>
Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com>
Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
|
|
Say we use the executable of test-case gdb.tui/tui-missing-src.exp like this:
...
$ gdb.sh -q -tui outputs/gdb.tui/tui-missing-src/tui-missing-src \
-ex "b f2"\
-ex run
...
(from a directory not containing a file called main.c to make sure that the
missing source stays missing) and then issue finish:
...
(gdb) finish
Run till exit from #0 f2 (x=4)
at f2.c:5
0x0000000000400570 in main ()
at main.c:7
Value returned is $1 = 13
(gdb)
...
and use control-<minus> to decrease the font size (IOW increase the $LINES and
$COLUMNS) on the terminal, we get:
...
gdb/tui/tui-winsource.c:340: internal-error: refresh_window: \
Assertion `pad_x + view_width <= pad_width || m_pad.get () == nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
The tui_source_window_base class has variable m_pad which keeps track of a
curses pad that is used to display the source code or disassembly efficiently.
The assert in tui_source_window_base::refresh_window triggers while preparing
to display part of the pad.
The problem is that the window is in a state in which the pad is not used,
because m_content.empty () == true. Instead, it simply shows
"[ No Source Available ]".
Fix this by bailing out of tui_source_window_base::refresh_window before
accessing the m_pad variable, if m_content.empty () == true.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/32592
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32592
|
|
I build gdb with libguile v2.0.9, and ran into:
...
In file included from /usr/include/guile/2.0/libguile.h:56,
from ../../gdb/guile/guile-internal.h:30,
from ../../gdb/guile/scm-arch.c:26:
/usr/include/guile/2.0/libguile/inline.h: In function 'int scm_is_pair(SCM)':
/usr/include/guile/2.0/libguile/tags.h:97:53: error: \
operation on '*0' may be undefined [-Werror=sequence-point]
# define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x))
~~~~~~~~~^~~~~
...
Fix this by using SCM_DEBUG_TYPING_STRICTNESS 0.
We were already using this for c++20 due to a Werror=volatile in SCM_UNPACK
when using libguile v2.0.10.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31378
|
|
|
|
This mailing list discussion:
https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com
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.
See for discussion of the 'x' packet:
https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r
with the part specific to the 'b' marker in:
https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/
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:
(rr) x/10i main
0x401106 <main>: push %rbp
0x401107 <main+1>: mov %rsp,%rbp
0x40110a <main+4>: mov 0x2f17(%rip),%rax # 0x404028 <global_ptr>
... etc ...
and looking in the remote log I see GDB is now using the 'm' packet
instead of the 'x' packet.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32593
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
|
|
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>
|
|
When building gdb with an older makeinfo (4.13), I run into:
...
gdb/doc/gdb.texinfo:42613: warning: `.' or `,' must follow @xref, not `f'.
...
This is related to this line:
...
@xref{Standard Replies} for standard error responses, and how to
respond indicating a command is not supported.
...
Fix this by adding a comma.
Tested by rebuilding the docs.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
|
|
|
|
Instead of using 0xFFFF0000, or with (~0xFFFF) to sign extend
negative 16-bit value and with (~0xFFFF) to extract higher order
address bits
opcodes/
* microblaze-dis.c: (print_insn_microblaze): Widen mask
(microblaze_get_target_address): Likewis
Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
|
|
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.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
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.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
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.
Suggested-by: Florian Krohm <flo2030@eich-krohm.de>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
This complements commit aacf780bca29 ("s390: Allow to explicitly omit
base register operand in assembly").
gas/testsuite/
* gas/s390/zarch-warn-areg-zero.l: Add tests for omitted base
register operands.
* gas/s390/zarch-warn-areg-zero.s: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
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.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
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.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
Append s390-specific emulation options to the shell variables instead of
replacing their contents.
ld/
* emultempl/s390.em (PARSE_AND_LIST_LONGOPTS,
PARSE_AND_LIST_OPTIONS, PARSE_AND_LIST_ARGS_CASES): Append to
emulation options instead of replacing them.
Fixes: b4cbbe8f7294 ("S/390: Add support for pgste marker")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
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.
gas/testsuite/
* gas/s390/machine-parsing-1.l: Add tests with double quoted
values.
* gas/s390/machine-parsing-1.s: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
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.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
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.
Tested by completing the build on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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").
Tested by rebuilding the documentation.
|
|
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.
Tested by rebuilding the documentation.
|
|
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.
|
|
Reviewed-By Richard Earnshaw <richard.earnshaw@arm.com>
|
|
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.
|
|
|
|
* testsuite/ld-x86-64/pr19609-2d.d: Move "#pass" to the end.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
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.
|
|
Restores ihex get_symtab_upper_bound to what it was prior to commit
394a3f4f8d. This will enable objcopy of other no-sym formats too.
PR 32599
* libbfd-in.h (_bfd_nosymbols_get_symtab_upper_bound): Define
as _bfd_long_bfd_0.
* libbfd.h: Regenerate.
|
|
|
|
Commit 3097045a18a8 runs into an abort in objalloc_free_block when the
memory being bfd_release'd wasn't bfd_alloc'd. Fix that.
* coffgen.c (_bfd_coff_free_cached_info): Don't release
raw_syments when obj_coff_keep_raw_syms.
* libcoff-in.h (obj_coff_keep_raw_syms): Define.
(struct coff_tdata): Add keep_raw_syms.
* peicode.h (pe_ILF_build_a_bfd): Set obj_coff_keep_raw_syms.
* libcoff.h: Regenerate.
|
|
|
|
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.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32482
|
|
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.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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:
...
000000ab 0000000001002928 0000000001002967
(DW_OP_reg16 (f0))
000000be 0000000001002967 0000000001002968
(DW_OP_reg24 (f8))
000000d1 0000000001002968 0000000001002974
(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)
000000ef 0000000001002974 0000000001002982
(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.
Tested on s390x-linux.
This also fixes test-case gdb.base/savedregs.exp.
[1] https://github.com/IBM/s390x-abi
[2] https://sourceware.org/pipermail/gdb-patches/2024-September/211589.html
|
|
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.
...
Tested on x86_64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
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.
|
|
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).
|
|
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.
|
|
|
|
[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.
Now, AM_MAKEINFOFLAGS in local.mk is defined as:
AM_MAKEINFOFLAGS = --no-split -I "$(srcdir)/%D%" -I %D%
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.
|
|
Consider test-case gdb.base/return-3.exp:
...
$ gdb -q outputs/gdb.base/return-3/return-3
Reading symbols from outputs/gdb.base/return-3/return-3...
(gdb)
...
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)
...
Tested on aarch64-linux.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
PR cli/32479
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32479
|
|
opcodes/
* ppc-opc.c (insert_m2, extract_m2): New functions.
(AESM, PGF1, XX2M, XX3M, XX3GF, XX2AES_MASK, XX2AESM_MASK,
XX3AES_MASK, XX3AESM_MASK, XX3GF_MASK): New macros.
(UIM): Update for new macros.
(powerpc_opcodes): Add xxaes128encp, xxaes192encp, xxaes256encp,
xxaesencp, xxaes128decp, xxaes192decp, xxaes256decp, xxaesdecp,
xxaes128genlkp, xxaes192genlkp, xxaes256genlkp, xxaesgenlkp,
xxgfmul128gcm, xxgfmul128xts, xxgfmul128.
gas/
* testsuite/gas/ppc/future.s: New test.
* testsuite/gas/ppc/future.d: Likewise.
|
|
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.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Co-authored-by: Guillaume VACHERIAS <guillaume.vacherias@st.com>
|
|
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.
|
|
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.
|
