Let's extend lex_type[] to also cover whitespace, then having a simple
macro to uniformly recognize both blanks and tabs (and \r when it's not
EOL) as such.
In macro.c use sb_skip_white() as appropriate, instead of open-coding
it.
When I run:
runtest dw2-using-debug-str.exp
... if I examine the gdb.log, I see:
objcopy: unable to copy file '[...]/dw2-using-debug-str'; reason: Text file busy
This happens because the inferior is still running, and objcopy --
despite the invocation seemingly not needing this -- tries to open it
for writing.
This patch works around the objcopy oddity by having gdb exit (killing
the inferior) before the invocation.
Fixing this points out that the test does not work in the
--target_board=cc-with-gdb-index case. This patch also arranges to
issue an "untested" here.
There is a test in gdb.cp/var-tag.exp that is kfail'd. I happened
across this while working on another series and found that the PR it
referenced was closed as invalid. On that basis I think the test
should be deleted.
Reviewed-By: Keith Seitz <keiths@redhat.com>
I neglected to update "maint print psymbols" when adding TYPE_DOMAIN
and FUNCTION_DOMAIN. This would have been mildly helpful when
debugging a series I am working on. This patch corrects the
oversight.
Approved-By: Andrew Burgess <aburgess@redhat.com>
The Rust compiler emits tuple type names with a space after the comma,
like "(i32, f64)". This changes rust-parse.c to follow. This isn't
ideal -- probably the DWARF reader should canonicalize these names --
but it is a bit more robust if symbol lookup should change; and anyway
this feature of gdb is probably rarely used.
There is inconsistency regarding whether or not +sme implies +sve2 and
whether +nosve2 implies +nosme. In particular, GCC 14 assumes the
dependency exists, and canonicalises target strings accordingly, whereas
LLVM treats the features as independent.
This patch removes the positive implication while retaining the negative
implication. This is the more permissive choice in each case, and
allows us to support target strings written with either interpretation
in mind.
This reduces our ability to detect invalid instructions, but we already
can't rely on this detection because gas doesn't know whether functions
might be executed in streaming mode and/or non-streaming mode.
The aarch64_feature_enable_set change is functionally redundant within
this patch. It is included because the longer term intention is to
instead remove the workaround in aarch64_parse_features, once the
internal feature checks have been modified to support having both
AARCH64_FEATURE_SME set and AARCH64_FEATURE_SVE unset.
Similarly, the dependency from +sme to +fp16 is currently redundant, but
this redundancy relies upon an incorrect dependency from +fcma to +fp16.
This can be fixed in the future, but it might require modifying internal
feature checks for a few FCMA instructions, so it's left unchanged for
now.
We agreed with LLVM that we shouldn't enforce the architectural
dependencies between fp8 muliplication features, so remove them.
Additionally, fix a typo in the gating for FEAT_SME_F8F16 instructions,
which were mistakenly gated by +sme-f8f32 instead. Until now this
mistake had been masked by the dependency between the features.
In the recent GOTPCREL addition I screwed up, in clearing the Rn bits
afterwards rather than setting them. While that ought to be benign (for
the bits being ignored in situations like this), we still want to leave
"canonical" encodings.
The pre-existing GOTTPOFF conversion wasn't doing quite correctly
either: We cannot assume the incoming Bn bits to be in a particular
state, as for the addressing form in question they're ignored as well.
To address both, introduce a helper function. This is then also an
overall reduction of (source) code size (and use of "magic" numbers).
Like for RMPUPDATE documentation is about to change as far as operands
are concerned. They're merely the other way around here.
While adjustind gas documentation, also add the missing RMPQUERY
counterparts there.
AMD are about to update their doc, to help clarify that what we
currently do isn't quite right: In particular it is not %rax but %rcx
which is affected by address size. In fact, that's a normal memory
operand, just not expressed via ModR/M byte, but fixed to (%rcx) (or
(%ecx) with 32-bit addressing).
To support this in the assembler, generalize memory operand handling so
far specific to XLAT (which isn't really a string insn, but requires its
memory operand to be (%bx) / (%ebx) / (%rbx)).
In the disassembler mimic handling after XLAT's, too.
Printing implicit %ds: and %es: prefixes is pretty meaningless in 64-bit
mode. The SDM explicitly omits them for the 64-bit forms, and it
obviously has them for the other ones only to cover non-64-bit modes
(oddly enough the AMD PM has them present).
Do away with at least one of the limitations - all other targets permit
multiple values to be specified with a single directive. Re-arrange the
logic further to also overcome an internal error in
riscv_insert_uleb128_fixes(), as e.g. observed by the all/sleb128-2
testcase. This way there's also no need to parse expressions twice,
thus also not raising the same diagnostics (if any) twice.
Note how this addresses a pre-existing XFAIL (where the comment wasn't
really applicable either for RISC-V).
Also update documentation, also to mention that differences between
symbols may be used with .uleb128 (albeit I'm uncertain whether there
are limitations).
When the changes on the remote protocol are made,
we want to test all the corner cases to prevent
regressions. Currently it can be tricky to simulate
some corner case conditions that would expose possible
regressions. When I want to add or change the remote
protocol packet, I need to hack gdbserver to send a
corrupted packet or an error to make sure GDB is able
to handle such a case.
This test makes it easy to send a corruped packet or
an error message to GDB using the gdbreplay tool and
check GDB deals with it as we expect it to.
This test starts a communication with gdbsever setting
the remotelog file. Then, it modifies the remotelog with
update_log proc, injects an error message instead of
the expected replay to the vMustReplyEmpty packet in order
to test GDB reacts to the error response properly. After
the remotelog modification, this test restarts GDB and starts
communication with gdbreply instead of the gdbserver using
the remotelog.
Add a lib/gdbreplay-support.exp. update_log proc matches lines
from GDB to gdbserver in a remotelogfile. Once a match is found then
the custom line is used to build a replacement line to send from
gdbserver to GDB.
Approved-By: Andrew Burgess <aburgess@redhat.com>
They are unused, according to clangd.
Add some includes to other files, which were relying on transitive
includes.
Change-Id: I3bcb4be93b3a18bf44a4068f4067e567f83e1d4f
dwarf2_per_bfd is used but never declared in this file, forward-declare
it.
dwarf2/types.h is unused, according to clangd.
Change-Id: I324b68894008af20307030c9e36c5abe06e36a78
With test-case gdb.python/py-mi-notify.exp and python 3.4, I occasionally run
into:
...
python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })
&"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n"
=-test-notification,data2="2",data1="1"
^done
(gdb)
FAIL: $exp: python notification, with additional data (unexpected output)
...
In contrast, a passing version looks like:
...
python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })
&"python gdb.notify_mi('-test-notification', { 'data1' : 1 , 'data2' : 2 })\n"
=-test-notification,data1="1",data2="2"
^done
(gdb)
PASS: gdb.python/py-mi-notify.exp: python notification, with additional data
...
The python method "gdb.notify_mi(name, data)" has parameter data which is a
dictionary, and it iterates over that dictionary.
The problem is that dictionaries are only guaranteed to be iterating in
insertion order starting python 3.7 (though cpython does this starting python
3.6).
Fix this in the same way as in commit 362a867f2ac ("[gdb/testsuite] Handle
unordered dict in gdb.python/py-mi-cmd.exp"): by allowing the alternative
order.
Tested on x86_64-linux.
Remove pr19609-4c.d and pr19609-4d.d since they are identical to
pr19609-4a.d and pr19609-4b.d, respectively.
* testsuite/ld-x86-64/pr19609-4c.d: Removed.
* testsuite/ld-x86-64/pr19609-4d.d: Likewise.
* testsuite/ld-x86-64/pr19609-4e.d: Renamed to ...
* testsuite/ld-x86-64/pr19609-4c.d: This.
* testsuite/ld-x86-64/x86-64.exp: Updated.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
cmd_show_list is a bit funny because it shows partial command names --
for a command like "show abc xyz", it will only show "abc xyz".
Nevertheless, I think it makes some sense to highlight these with the
command style. That is what this patch does.
show_index_cache_command prints whether the index-cache is enabled.
This text was added back in 2018 in commit 87d6a7aa (Add DWARF index
cache). Then in 2021, the enabling option was changed via commit
7bc5c369 (gdb: introduce "set index-cache enabled", deprecate "set
index-cache on/off").
This latter change made this output, IMO, redundant. That is,
currently gdb will show:
(gdb) show index-cache
...
index-cache enabled: The index cache is off.
...
The index cache is currently disabled.
This patch removes the redundant output.
This changes the help command to use the new command style when
displaying text like:
List of "catch" subcommands:
As a side effect, this mildly -- but not hugely -- cleans up some i18n
issues in help_list. The header comment for that function is also
changed to the gdb style.
Finally, this function used to print something like:
Type "help catch" followed by catch subcommand name for full documentation.
The second "catch" here seems redundant to me, so this patch removes
it.
I think there is no need to have a prefix command that simply calls
help_list. Instead, add_basic_prefix_cmd can be used. This patch
changes the relevant instances. In one spot, add_setshow_prefix_cmd
is used instead.
PR 32610 says:
File gdb/darwin-nat.c is missing an #include statement of
"cli/cli-style.h". It is needed because there is a reference to class
object command_style in the .c file.
I'm not able to build-test this change (I only have access to arm64
macos machines, which GDB doesn't support yet), but I don't think I'm
doing things worse by adding this.
Change-Id: I2a169664ff91b92caf27cb084334f2eb4df46aa5
Add comments to the assembler generated by the DWARF assembler that
builds the line table. I found these comments useful when debugging
issues with the line table parsing.
This patch should make no difference to what is being tested. The
test binaries should be unchanged after this commit.
Approved-By: Kevin Buettner <kevinb@redhat.com>
The register_status field of regcache is declared as `unsigned char *`.
This is incorrect, because `enum register_status` from
gdbsupport/common-regcache.h is based on signed char and
REG_UNAVAILABLE is defined as -1. Fix the declared type.
Now that we are modifying the declaration, also use a unique_ptr
and make the field private.
The get/set methods already use the correct type, but we update cast
operations in two places.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The supply_regblock function takes a pointer to a buffer as an
argument and implements two different behavior based on the pointer
being null. There are two cases where we pass nullptr, all in
tracepoint.cc, where we are essentially doing a reset on the regcache.
In fast_tracepoint_ctx::regcache, register_status array does not
even exist. Hence, that use simply boils down to zeroing of register
data. Do this at the time of creating the buffer and remove the call
to supply_regblock.
In fetch_traceframe_registers, inline the use with a call to `reset`.
Hence, there are no more cases left, where a nullptr would be passed
to supply_regblock. Assert that the buffer argument is non-null and
simplify the implementation.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Define a `reset` method for a regcache and use it for code
simplification. This patch allows further simplification in the next
patch.
The reset method fills the register data with zeroes. For the use in
get_thread_regcache, this is added behavior, making the patch not a
pure refactoring, and may look like extra overhead. However, it is
better to avoid having arbitrary values left in the data buffer.
Hence, it is considered a behavioral improvement.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When a regcache is initialized, the values of registers are not
fetched yet. Thus, initialize the register statuses to REG_UNKNOWN
instead of REG_UNAVAILABLE, because the latter rather means "we
attempted to fetch but could not obtain the value".
The definitions of the reg status enums (from
gdbsupport/common-regcache.h) as a reminder:
/* The register value is not in the cache, and we don't know yet
whether it's available in the target (or traceframe). */
REG_UNKNOWN = 0,
/* The register value is valid and cached. */
REG_VALID = 1,
/* The register value is unavailable. E.g., we're inspecting a
traceframe, and this register wasn't collected. Note that this
"unavailable" is different from saying the register does not
exist in the target's architecture --- in that case, the target
should have given us a target description that does not include
the register in the first place. */
REG_UNAVAILABLE = -1
Similarly, when the regcache is invalidated, change all the statuses
back to REG_UNKNOWN.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Store the regcache pointer in thread_info as a unique_ptr. This
allows us delete the thread_info destructor.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Convert the `free_register_cache` function into a destructor of the
regcache struct. In one place, we completely remove the call to free
the regcache object by stack-allocating the object.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This is a refactoring that converts
init_register_cache (struct regcache *regcache,
const struct target_desc *tdesc,
unsigned char *regbuf)
into the constructor
regcache (const target_desc *tdesc, unsigned char *regbuf)
and converts
new_register_cache (const struct target_desc *tdesc)
into the constructor
regcache (const target_desc *tdesc)
Also use DISABLE_COPY_AND_ASSIGN for additional compile-time safety.
Tested by rebuilding gdbserver with '--enable-inprocess-agent=no' and
with '--enable-inprocess-agent=yes'.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This is a continuation of the previous refactoring to use inheritance
in the definition of tracepoints contexts. Again, no behavioral change
is intended.
Different tracepoint contexts are identified by the `type` field. The
field is used only in `get_context_regcache`, where we essentially
have 2 cases, each corresponding to a tracepoint context type. Remove
the `type` field and split the `get_context_regcache` function into 2
virtual method implementations.
Tested by rebuilding gdbserver with '--enable-inprocess-agent=no' and
'--enable-inprocess-agent=yes'.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Use inheritance in the definition of tracepoint contexts. This is a
refactoring that aims to improve the code. No behavior should be
altered.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
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>
