| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I noticed a few ui_out methods that are just trivial wrappers. This
patch moves these to ui-out.h, as it seems like they should be
inlineable.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
|
|
It will be used for all segments in a qualified name,
not only the last one.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
The added check fixes the case when an unqualified lookup
name without template arguments causes expansion of many CUs
which contain the name with template arguments.
This is similar to what dw2_expand_symtabs_matching_symbol does
before expanding the CU.
In the referenced issue the lookup name was wxObjectDataPtr and many
CUs had names like wxObjectDataPtr<wxBitmapBundleImpl>. This caused
their expansion and the lookup took around a minute. The added check
helps to avoid the expansion and makes the symbol lookup to return in
a second or so.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520
|
|
Hopefully this library is no longer quite so much a "you have to look
in the source to understand anything" library.
No semantic changes, though some functions have been moved around for
clarity.
include/
ctf-api.h: Add comments.
|
|
Ever since commit 1fa7a0c24e78e7f ("libctf: sort out potential refcount
loops") ctf_dict_close has only freed anything if the refcount on entry
to the function is precisely 1. >1 obviously just decrements the
refcount, but the linker machinery can sometimes cause freeing to recurse
from a dict to another dict and then back to the first dict again, so
we interpret a refcount of 0 as an indication that this is a recursive call
and we should just return, because a caller is already freeing this dict.
Unfortunately there is one situation in which this is not true: the bad:
codepath in ctf_bufopen entered when opening fails. Because the refcount is
bumped only at the very end of ctf_bufopen, any failure causes
ctf_dict_close to be entered with a refcount of zero, and it frees nothing
and we leak the entire dict.
The solution is to bump the refcount to 1 right before freeing... but this
codepath is clearly delicate enough that we need to properly validate it,
so we add a test that uses malloc interposition to count allocations and
frees, creates a dict, writes it out, intentionally corrupts it (by setting
a bunch of bytes after the header to a value high enough that it is
definitely not a valid CTF type kind), then tries to open it again and
counts the malloc/free pairs to make sure they're matched. (Test run only
on *-linux-gnu, because malloc interposition is not a thing you can rely
upon working everywhere, and this test is not arch-dependent so if it
passes on one arch it can be assumed to pass on all of them.)
libctf/
* ctf-open.c (ctf_bufopen): Bump the refcount on failure.
* testsuite/libctf-regression/open-error-free.*: New test.
|
|
This .lk option lets you run the lookup program via a wrapper executable.
For example, to run under valgrind and check for leaks (albeit noisily
because of the libtool shell script wrapper):
libctf/
* testsuite/lib/ctf-lib.exp (run_lookup_test): Add wrapper.
|
|
This .lk option lets you execute particular tests only on specific host
architectures.
libctf/
* testsuite/lib/ctf-lib.exp (run_lookup_test): Add host.
|
|
This .lk option lets you link the lookup program with extra libraries
in addition to -lctf.
libctf/
* testsuite/lib/ctf-lib.exp (run_lookup_test): Add lookup_link.
|
|
If iteration fails because opening a dict has failed, ctf_archive_next does
not destroy the iterator, so the caller can keep going and try to open other
dicts further into the archive. ctf_archive_iter just returns, though, so
it should free the iterator rather than leaking it.
libctf/
* ctf-archive.c (ctf_archive_iter): Don't leak the iterator on
failure.
|
|
CTF archive member opening (via ctf_arc_open_by_name, ctf_archive_iter, et
al) attempts to be helpful and auto-open and import any needed parent dict
in the same archive. But if this fails, the error is not reported but
simply discarded, and you silently get back a dict with no parent, that
*you* suddenly have to remember to import.
This is not helpful behaviour: if the parent is corrupted or we run out of
memory or something, the caller is going to want to know! Split it in two:
if the dict cites a parent that doesn't exist at all (a lot of historic
dicts name "PARENT" as their parent, even when they're not even children, or
perhaps the parent dict is stored separately and you plan to manually
associate it), we skip it as now, but if the import fails with an actual
error other than ECTF_ARNNAME, return the error and fail the open.
libctf/
* ctf-archive.c (ctf_arc_import_parent): Return failure if
parent opening fails for reasons other thnn nonexistence.
(ctf_dict_open_sections): Adjust.
|
|
Some functions were renamed without the comments catching up.
libctf/
* ctf-open.c (upgrade_types_v1): Fix comment typos.
|
|
It's opcode was wrong, as was e.g. easily visible from the inappropriate
testcase expectation.
|
|
Like their byte, half, word, and doubleword counterparts their
immediates are multiples of 3 / 4 respectively.
|
|
Set DWARF2_CIE_DATA_ALIGNMENT (data alignment factors) to -8.
It helps to save space.
Data Alignment Factor
A signed LEB128 encoded value that is factored out of all offset
instructions that are associated with this CIE or its FDEs. This value
shall be multiplied by the register offset argument of an offset
instruction to obtain the new offset value.
|
|
|
|
gas/
* gen-sframe.c (output_sframe_internal): Use BP instead of FP.
|
|
When printing complaints with one of the execs from test-case
gdb.dwarf2/macro-source-path.exp, we run into:
...
$ gdb -q -batch \
-iex "set complaints 100" \
macro-source-path-clang14-dw4-absolute-cwd-32 \
-ex "p main"
During symbol reading: debug info runs off end of .debug_macro section \
[in module macro-source-path-clang14-dw4-absolute-cwd-32]
$1 = {int ()} 0x4004b7 <main>
...
and readelf complains more specifically:
...
Contents of the .debug_macro section:
Offset: 0
Version: 5
Offset size: 4
Offset into .debug_line: 0xe3
DW_MACRO_define - lineno : 0 macro : ONE 1
DW_MACRO_define_strp - lineno : 0 macro : THREE 3
DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c
DW_MACRO_define - lineno : 1 macro : TWO 2
DW_MACRO_end_file
readelf: Error: .debug_macro section not zero terminated
...
Fix this by adding the missing terminator in Dwarf::_macro_unit.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Remove some includes reported as unused by clangd.
Change-Id: I7768232c28b9b86b0a03628a1d15dede2b30c76a
|
|
The 'univeral_compile_options' in gdb.exp file only verifies the support
of '-fdiagnostics-color=never' for the "C" source file. So while running
tests with assembly source file (.s), many of them are not able to run
on icx/clang compilers because '-fdiagnostics-color=never' option is not
supported. This problem is not seen for the ".S" assembly source files so
these files are not handled separately. After this change, this function
is split into multiple functions to check the support for different type
of sources individually.
Before this change, in the case of clang and ICX compiler, this error is
shown for assembly source files (.s):
'''
icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o
amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300)
icx: warning: argument unused during compilation: '-fdiagnostics-color=never'
[-Wunused-command-line-argument]
gdb compile failed, icx: warning: argument unused during compilation:
'-fdiagnostics-color=never' [-Wunused-command-line-argument]
UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare
'''
Similarly this error is shown for the clang compiler:
'''
clang -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0
-o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s
clang: warning: argument unused during compilation:
'-fdiagnostics-color=never' [-Wunused-command-line-argument]
'''
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The `fork_inferior()` function accepts multiple callbacks, making its
signature a bit hard to read. Define some type aliases to make it a bit
clearer. Use function view for all, while at it.
Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When building GDB with -O2 and --enable-ubsan, I get some random errors
in the packet_result self test:
/home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool'
This happens because packet_result::m_textual_err_msg is uninitialized
when using the second constructor. When such a packet_result object
gets copied, an invalid value for m_textual_err_msg (a bool field) is
loaded, which triggers ubsan.
Avoid this by initializing m_textual_err_msg.
Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85
Approved-By: Tom Tromey <tom@tromey.com>
|
|
clangd reports this header as unused.
Change-Id: I7bf413f57b2840a52d83bd4f8b9415728bc0917b
|
|
Remove some include files reported as unused by clangd.
Change-Id: I39f9d40b9d5bbf040250b41ef258fb8f32dd5c0a
|
|
Run `pre-commit autoupdate`, this is the outcome. There is no change in
formatting of Python files.
Change-Id: I79c221af1b2192f866a344ab17d6199b137371cb
|
|
Commit 8971d2788e79 ("gdb: link so_list using intrusive_list")
mistakenly removed the line that moves the lm_info unique pointer to
sop->lm_info, probably due to a bad conflict resolution. Restore that
line.
Unfortunately, this code is only used for TI C66, which is not widely
tested (if used at all).
Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add the SME2 variant of the FP8 convert and scale
instructions, enabled at assembly-time using the `+sme2+fp8'
architectural extension flag. More specifically, support is
added for the following instructions:
Multi-vector floating-point convert from FP8 to
BFloat16 (in-order):
-----------------------------------------------
- bf1cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
- bf2cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
Multi-vector floating-point convert from FP8 to
deinterleaved BFloat16:
-----------------------------------------------
- bf1cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
- bf2cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
Multi-vector floating-point convert from BFloat16
to packed FP8 format:
-------------------------------------------------
- bfcvt <Zd>.B, { <Zn1>.H-<Zn2>.H }
Multi-vector floating-point convert from FP8 to
half-precision (in-order):
-----------------------------------------------
- f1cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
- f2cvt { <Zd1>.H-<Zd2>.H }, <Zn>.B
Multi-vector floating-point convert from FP8 to
deinterleaved half-precision:
-----------------------------------------------
- f1cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
- f2cvtl { <Zd1>.H-<Zd2>.H }, <Zn>.B
Multi-vector floating-point convert from half-precision
to packed FP8 format:
-------------------------------------------------------
fcvt_2h
Multi-vector floating-point convert from single-precision
to packed FP8 format:
---------------------------------------------------------
fcvt_4s
Multi-vector floating-point convert from single-precision
to interleaved FP8 format:
---------------------------------------------------------
- fcvtn <Zd>.B, { <Zn1>.S-<Zn4>.S }
Multi-vector floating-point adjust exponent by vector:
------------------------------------------------------
- fscale { <Zdn1>.H-<Zdn2>.H }, { <Zdn1>.H-<Zdn2>.H },
<Zm>.H
- fscale { <Zdn1>.S-<Zdn2>.S }, { <Zdn1>.S-<Zdn2>.S },
<Zm>.S
- fscale { <Zdn1>.D-<Zdn2>.D }, { <Zdn1>.D-<Zdn2>.D },
<Zm>.D
Multi-vector floating-point adjust exponent:
--------------------------------------------
- fscale { <Zdn1>.H-<Zdn2>.H }, { <Zdn1>.H-<Zdn2>.H },
{ <Zm1>.H - <Zm2>.H }
- fscale { <Zdn1>.S-<Zdn2>.S }, { <Zdn1>.S-<Zdn2>.S },
{ <Zm1>.S - <Zm2>.S }
- fscale { <Zdn1>.D-<Zdn2>.D }, { <Zdn1>.D-<Zdn2>.D },
{ <Zm1>.D - <Zm2>.D }
|
|
Add the SVE2 variant of the FP8 convert and scale instructions,
enabled at assembly-time using the `+sve2+fp8' architectural
extension flag. More specifically, support is added for the
following instructions:
FP8 convert to BFloat16 (bottom/top):
-------------------------------------
- bf1cvt Z<d>.H, Z<n>.B
- bf2cvt Z<d>.H, Z<n>.B
- bf1cvtlt Z<d>.H, Z<n>.B
- bf2cvtlt Z<d>.H, Z<n>.B
FP8 convert to half-precision (bottom/top):
-------------------------------------------
- f1cvt Z<d>.H, Z<n>.B
- f2cvt Z<d>.H, Z<n>.B
- f1cvtlt Z<d>.H, Z<n>.B
- f2cvtlt Z<d>.H, Z<n>.B
BFloat16/half-precision convert, narrow and
interleave to FP8:
-------------------------------------------
- bfcvtn Z<d>.B, { Z<n>1.H - Z<n>2.H }
- fcvtn Z<d>.B, { Z<n>1.H - Z<n>2.H }
Single-precision convert, narrow and interleave
to FP8 (bottom/top):
-----------------------------------------------
- fcvtnb Z<d>.B, { Z<n>1.S - Z<n>2.S }
- fcvtnt Z<d>.B, { Z<n>1.S - Z<n>2.S }
|
|
Add the advanced SIMD variant of the FP8 convert and scale
instructions, enabled at assembly-time using the `+fp8'
architectural extension flag. More specifically, support is
added for the following instructions:
FP8 convert to BFloat16 (vector):
---------------------------------
- bf1cvtl V<d>.8H, V<n>.8B
- bf2cvtl V<d>.8H, V<n>.8B
- bf1cvtl2 V<d>.8H, V<n>.16B
- bf2cvtl2 V<d>.8H, V<n>.16B
FP8 convert to half-precision (vector):
---------------------------------------
- f1cvtl V<d>.8H, V<n>.8B
- f2cvtl V<d>.8H, V<n>.8B
- f1cvtl2 V<d>.8H, V<n>.16B
- f2cvtl2 V<d>.8H, V<n>.16B
Single-precision to FP8 convert and narrow (vector):
----------------------------------------------------
- fcvtn V<d>.8B, V<n>.4S, V<m>.4S
- fcvtn2 V<d>.16B, V<n>.4S, V<m>.4S
Half-precision to FP8 convert and narrow (vector):
--------------------------------------------------
- fcvtn V<d>.8B, V<n>.4H, V<m>.4H
- fcvtn V<d>.16B, V<n>.8H, V<m>.8H
Floating-point adjust exponent by vector:
-----------------------------------------
- fscale V<d>.4H, V<n>.4H, V<m>.4H
- fscale V<d>.8H, V<n>.8H, V<m>.8H
- fscale V<d>.2S, V<n>.2S, V<m>.2S
- fscale V<d>.4S, V<n>.4S, V<m>.4S
- fscale V<d>.2d, V<n>.2d, V<m>.2d
|
|
|
|
Currently, if you configure gdb with explicit --enable-threading, but
then configure detects std::thread does not work, configure silently
disables threading support and continues configuring.
This patch makes that scenario cause a configuration error, like so:
$ /home/pedro/gdb/src/configure --enable-threading && make
...
configure: error: std::thread does not work; disable threading
make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1
make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads'
make: *** [Makefile:1041: all] Error 2
$
Additionally, if you don't explicitly pass --enable-threading, and
std::thread does not work, we will now get a warning (and the build
continues):
$ /home/pedro/gdb/src/configure && make
...
configure: WARNING: std::thread does not work; disabling threading
...
This is similar to how we handle --enable-tui and missing curses. The
code and error/warning messages were borrowed from there.
Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
that do not support it.
|
|
This hunk of code in move_or_literal_pool just looks wrong, but I
can't find a testcase that will tickle it to prove it. It looks a bit
like it was intended to catch cases where a bignum contained a
floating-point value, but there were a number of problems with it.
- It tested X_add_number == -1, but an FP bignum is indicated by any
value <= 0.
- It converted the floating-point value to extended precision, but
that's not used on Arm beyond the legacy FPA code. No attempt was
made to match the FP value to the intended memory/mov operation.
Since I can't construct a viable testcase, I've just removed the existing
code and made the function error out in this case: this seems more sensible
than generating wrong code or trying to write something more complex that
can't be tested anyway.
|
|
Add support for DW_MACRO_define_strp in dwarf assembly, and use it in
test-case gdb.dwarf2/macro-source-path.exp.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
spu-elf and z80-coff fail this test due to "def" being a pseudo-op.
tic30-unknown-coff fails it due to '#' not starting comments.
* testsuite/gas/macros/altmacro.s: Use /* */ comments. Rename
DEF to EDF.
|
|
|
|
.irp and .irpc receive a null macro_entry. \+ causes a crash after the
recent \+ support. Restore the previous behavior.
Signed-off-by: Fangrui Song <maskray@gcc.gnu.org>
|
|
We should revisit sysreg feature enablement and dependencies in future, but
this change should help until then.
OK for master?
|
|
This matches the existing behaviour in GCC and LLVM, and also the current
documentation.
OK for master?
|
|
This patch rewrites assembly tests to use utils macros declared in
sysreg-test-utils.inc. Some tests were adapted to use the new macro
rw_sys_reg.
|
|
This patch aims at grouping write and read for a same system register
one after another so that the diff for the macro replacement does not
generate too much noise.
|
|
This patch aims at making easier to replacement of read and write
instructions to system registers by a macro that will use the same
registers for read and write.
|
|
This patch removes the instruction addresses from the objdump's expected
output (.d files). The intended benefit from this clean-up is to allow to
swap lines around more easilly, and removes the noise of patches that add,
remove or reorder instructions.
|
|
When printing a DW_MACRO_define_strx entry in a .debug_macro.dwo section, we
run into:
...
DW_MACRO_define_strx lineno : 0 macro : <no .debug_str_offsets section>
...
Fix this in display_debug_macro by passing the correct dwo argument to a
fetch_indexed_string call.
That works fine for readelf -w, with with readelf -wm we have:
...
DW_MACRO_define_strx lineno : 0 macro : <no .debug_str_offsets.dwo section>
...
Fix this in display_debug_macro by doing load_debug_section_with_follow for
str_dwo / str_index_dwo sections instead of str / str_index sections when
handling .debug_macro.dwo.
PR 31735
|
|
When compiling a hello world with dwarf4 split dwarf:
...
$ gcc -gdwarf-4 -gsplit-dwarf hello.c -save-temps -dA
...
we have in a-hello.s these three initial entries in .debug_str_offsets:
...
.section .debug_str_offsets.dwo,"e",@progbits
.4byte 0 // indexed string 0x0: short int
.4byte 0xa // indexed string 0x1: /home/vries/binutils
.4byte 0x1f // indexed string 0x2: main
...
but "readelf -ws a.out" starts at the third entry:
...
Contents of the .debug_str_offsets.dwo section (loaded from a-hello.dwo):
Length: 0x30
Index Offset [String]
0 00000000 main
...
This is a regression since commit 407115429b3 ("Modified changes for
split-dwarf and dwarf-5."), which introduced a variable
debug_str_offsets_hdr_len in display_debug_str_offsets.
Fix this by setting display_debug_str_offsets to 0 for the dwarf4 case.
PR 31734
|
|
|
|
With previous behaviour, multiple mapping symbols within the same
function would result in all the mapping symbols being searched.
This could slow down disassembly dramatically.
Multiple mapping symbols within a function can be a result of encoding
instructions as data, like sometimes seen in random instruction
generators.
opcodes/ChangeLog:
* riscv-dis.c (riscv_search_mapping_symbol): Use last mapping
symbol if it exists.
|
|
While debugging gdb, I saw this:
During symbol reading: unexpected demangled name 'operator<=><std::chrono::_V2::system_clock, std::chrono::duration<long int>, std::chrono::duration<long int> >'
This happens because cp-name-parser.y does not handle the spaceship
operator. This patch implements this.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
