A review comment on the SCFI V4 series was to handle ginsn creation for
certain lea opcodes more precisely.
Specifically, we should preferably handle the following two cases of lea
opcodes similarly:
- #1 lea with "index register and scale factor of 1, but no base
register",
- #2 lea with "no index register, but base register present".
Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the
case of #1 above. For #2, however, the lea insn is translated to either
a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate
for displacement is non-zero or not respectively.
Change the handling in x86_ginsn_lea so that both of the above lea
manifestations are handled similarly.
While at it, remove the code paths creating GINSN_TYPE_OTHER altogether
from the function. It makes sense to piggy back on the
x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the
destination register is interesting. This was also suggested in one of
the previous review rounds; the other functions already follow that
model, so this keeps functions symmetrical looking.
gas/
* gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with
no base register similar to the case of no index register. Remove
creation of GINSN_TYPE_OTHER from the function.
gas/testsuite/
* gas/scfi/x86_64/ginsn-lea-1.l: New test.
* gas/scfi/x86_64/ginsn-lea-1.s: Likewise.
* gas/scfi/x86_64/scfi-x86-64.exp: Add new test.
This commit fixes some of the easier duplicate test names in the
gdb.trace/ directory.
All of these duplicates are resolved by either given tests a name, or
by extended the existing name to make it more descriptive.
There should be no change in what is tested after this commit.
Fix some duplicate test names in gdb.base/cond-eval-mode.exp when
running with native-gdbserver or native-extended-gdbserver board
files.
I've just added some 'with_test_prefix' blocks to make the test names
unique, there should be no change in what is tested after this commit.
A recent commit broke AIX build. The thread_local type defined functions
were being considered a weak symbol and hence while creating the binary these
symbols were not visible.
This patch is a fix for the same.
This code was probably needed before we had reinflatable
frame_info_ptrs, it's not necessary anymore.
Change-Id: I5474c6081ee1e39624c9266b05dbe01351a130b5
Approved-By: Tom Tromey <tom@tromey.com>
Supply these symbols as computed by the linker scripts, even when there are weak definitions.
PR 31124
* scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE.
My earlier attempt to mask the segment registers in gdbserver for
Windows introduced some bugs. That patch is here:
https://sourceware.org/pipermail/gdb-patches/2023-December/205306.html
The problem turned out to be that these fields in the Windows
'CONTEXT' type are just 16 bits, so while masking the values on read
is fine, writing the truncated values back then causes zeros to be
written to some subsequent field.
This patch cleans this up by arranging never to write too much data to
a field.
I also noticed that two register numbers here were never updated for
the 64-bit port. This patch fixes this as well, and renames the "FCS"
register to follow gdb.
Finally, this patch applies the same treatment to windows-nat.c.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
This patch removes support for the two instructions above from the GNU
simulator, including the corresponding tests. These instructions do
not really exist in BPF and are not recognized as such by the kernel
verifier. This has now been pointed out during the standardization of
the BPF ISA.
Signed-off-by: Jose E. Marchesi <jose.marchesi@oracle.com>
Since commit 6771fc6f1d "Use a .def file for domain_enum", the
sym-domains.def file has been introduced, and requires the user to
define the DOMAIN(x) macro.
On older systems (centos-7 with glibc-2.17 for example), this DOMAIN
macro conflicts with another macro defined in /usr/include/math.h.
Fix this conflict by changing sym-domains.def to use a macro named
SYM_DOMAIN instead of DOMAIN.
Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3
Approved-By: Tom Tromey <tom@tromey.com>
There are no legacy ldind nor ldabs BPF instructions with BPF_SIZE_DW.
For some reason we were (incorrectly) supporting these. This patch
updates the opcodes so the instructions get removed and modifies the
GAS manual and testsuite accordingly.
See discussion at
https://lore.kernel.org/bpf/110aad7a-f8a3-46ed-9fda-2f8ee54dcb89@linux.dev
Tested in bpf-uknonwn-none target, x86-64-linux-gnu host.
include/ChangeLog:
2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and
BPF_INSN_LDABSDW instructions.
opcodes/ChangeLog:
2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and
BPF_INSN_LDABSDW instructions.
gas/ChangeLog:
2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* doc/c-bpf.texi (BPF Instructions): There is no indirect 64-bit
load instruction.
(BPF Instructions): There is no absolute 64-bit load instruction.
* testsuite/gas/bpf/mem.s: Update test accordingly.
* testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem-be.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
* testsuite/gas/bpf/mem.d: Likewise.
* testsuite/gas/bpf/mem.s: Likewise.
If you have set up a backtrace limit, and the backtrace stops
because of this in an inline frame with arguments, you get an
assertion failure:
```
(gdb) bt
(gdb) set backtrace limit 2
(gdb) bt
C:/src/repos/binutils-gdb.git/gdb/frame.c:3346: internal-error: reinflate: Assertion `m_cached_level >= -1' failed.
```
And if this one is fixed, there is another one as well:
```
(gdb) bt
C:/src/repos/binutils-gdb.git/gdb/dwarf2/loc.c:1160: internal-error: dwarf_expr_reg_to_entry_parameter: Assertion `frame != NULL' failed.
```
The reason for both of them is this kind of loop:
```
while (get_frame_type (frame) == INLINE_FRAME)
frame = get_prev_frame (frame);
```
Since get_prev_frame respects the backtrace limit, it will return
NULL, and from there on you can't continue.
This changes these loops to use get_prev_frame_always instead, so
you always get a non-inline frame in the end.
With this backtrace works:
```
(gdb) bt
(gdb)
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29865
Approved-By: Andrew Burgess <aburgess@redhat.com>
This changes cp_search_static_and_baseclasses to only search for
types, functions, and modules. The latter two cases were discovered
by regression testing. I found it somewhat surprising the Fortran
name lookup ends up in this code, but did not attempt to change this.
This changes cp_lookup_rtti_type to only search for types -- not
functions or variables. Due to the symbol-matching hack, this could
just use SEARCH_TYPE_DOMAIN, but I think it's better to be clear; also
I hold on to some hope that perhaps the hack can someday be removed.
This simplifies some symbol searches in linespec.c. In particular,
two separate searches here can now be combined into one, due to the
new use of flags.
Arguably the STRUCT_DOMAIN searches should perhaps not even be done.
Only C really has these, and C doesn't have member functions.
However, it seems relatively harmless -- and clearly compatible -- to
leave this in.
This changes some of the Ada code to simplify symbol searches. For
example, if a function is being looked for, the search is narrowed to
use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT. In one spot, a
search of the "struct" domain is removed, because Ada does not have a
tag domain.
This patch changes the DWARF reader to use the new symbol domains. It
also adjusts many bits of associated code to adapt to this change.
The non-DWARF readers are updated on a best-effort basis. This is
somewhat simpler since most of them only support C and C++. I have no
way to test a few of these.
I went back and forth a few times on how to handle the "tag"
situation. The basic problem is that C has a special namespace for
tags, which is separate from the type namespace. Other languages
don't do this. So, the question is, should a DW_TAG_structure_type
end up in the tag domain, or the type domain, or should it be
language-dependent?
I settled on making it language-dependent using a thought experiment.
Suppose there was a Rust compiler that only emitted nameless
DW_TAG_structure_type objects, and specified all structure type names
using DW_TAG_typedef. This DWARF would be correct, in that it
faithfully represents the source language -- but would not work with a
purely struct-domain implementation in gdb. Therefore gdb would be
wrong.
Now, this approach is a little tricky for C++, which uses tags but
also enters a typedef for them. I notice that some other readers --
like stabsread -- actually emit a typedef symbol as well. And, I
think this is a reasonable approach. It uses more memory, but it
makes the internals simpler. However, DWARF never did this for
whatever reason, and so in the interest of keeping the series slightly
shorter, I've left some C++-specific hacks in place here.
Note that this patch includes language_minimal as a language that uses
tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp,
which doesn't specify the language for a type unit. Arguably this
test case is wrong.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
Nothing calls the variant of symbol_matches_domain that accepts a
domain_enum for searching, so this patch removes it and the
corresponding symbol::matches.
This changes lookup_symbol and associated APIs to accept
domain_search_flags rather than a domain_enum.
Note that this introduces some new constants to Python and Guile. I
chose to break out the documentation patch for this, because the
internals here do not change until a later patch, and it seemed
simpler to patch the docs just once, rather than twice.
This changes quick_symbol_functions::lookup_global_symbol_language to
accept domain_search_flags rather than just a domain_enum, and fixes
up the fallout.
To avoid introducing any regressions, any code passing VAR_DOMAIN now
uses SEARCH_VFT.
That is, no visible changes should result from this patch. However,
it sets the stage to refine some searches later on.
The Python and Guile code exposed the internal domain constants both
as attributes of symbols and as values to pass to lookup functions.
Now, perfect backward compatibility here can't be achieved: some
symbols are going to have domain changes by the end of this series.
However, it seemed to me that we can preserve lookups using the basic
domain values.
This patch implements this by exporting the "or"-able search constants
with an extra bit set. Then it introduces some functions to convert
such constants to domain_search_flags. This will be used by the
Python and Guile code, so that both old- and new-style lookups will
work properly; and while preserving the idea that the domain constants
can be compared to a symbol's domain.
completion_list_add_symbol checks that the returned symbol has
VAR_DOMAIN, but also checks that its address class is LOC_BLOCK. The
domain check is redundant -- only functions can possibly be LOC_BLOCK
-- and leaving this in place will cause a regression when combined
with a later patch in this series. This patch preemptively removes
the redundant check.
This adds a new flag enum type, domain_search_flags, which is the flag
version of domain_enum. Nothing uses this yet, but the goal here is
to have all symbol searches and lookups use these flags. The new
names are chosen to exactly parallel domain_enum.
This adds two new symbol domain constants, TYPE_DOMAIN and
FUNCTION_DOMAIN.
Historically, gdb was a C debugger, and the symbol tables continue to
reflect this. In particular, symbol domains match the C language,
with VAR_DOMAIN including variables, functions, and types.
However, other languages have other approaches to namespacing. And,
in any case, it is often useful for other parts of gdb to be able to
distinguish between some domains at lookup time, without resorting to
examining a symbol's location -- in some situations, this sort of
filtering happens too late.
Nothing uses these new domains yet, but the idea behind the patch is
to separate symbols into more domains and then let the
language-specific parts of gdb implement their semantics in terms of
these categories.
Future patches will change and reuse the names from domain_enum. This
patch makes this less error-prone by having a single point to define
these names, using the typical gdb ".def" file.
global_symbol_searcher::add_matching_symbols in symtab.c has a
gigantic 'if' statement -- 33 lines of conditional expression. This
patch splits it up into a series of separate 'if's.
NR_DOMAINS is only used for a static assert, but we no longer need it
now. If we add too many constants to this enum, GCC will warn about
the bitfield overflow:
error: ‘symbol::m_domain’ is too small to hold all values of ‘enum domain_enum’
Sandra Loosemore
GDB Administrator
Indu Bhagat
Vladimir Mezentsev
Tom Tromey
Andrew Burgess
Aditya Vidyadhar Kamath
Simon Marchi
Nick Clifton
Georg-Johann Lay
Alan Modra
Jose E. Marchesi
Lancelot SIX
Hannes Domani
Tom Tromey