| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Make it a unique_ptr, so it gets automatically deleted when the so_list
is deleted.
Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
I think this typedef hinders readability. First, it's not well named
(it's not clear it contains lm_info_target objects). And hiding the
fact that it contains unique pointers is not very useful either. I was
looking at the code in solib_target_current_sos where the unique
pointers get moved from the vector, and it wasn't obvious at all what
the source of the move was.
Change-Id: I4a5cda7c90554f018b7c466b1535b41d69cbcbe7
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Same rationale as the previous patch, but for solib-rocm.
- Introduce rocm_so, which is a name a unique_name (see comment in
rocm_update_solib_list for that) and a unique_ptr to the
lm_info_svr4.
- Change the internal lists from so_list lists to vectors of rocm_so.
- Remove rocm_free_solib_list, as everything is automatic now.
- Replace rocm_solib_copy_list with so_list_from_rocm_sos.
Change-Id: I71e06e3ea22d6420c9e4e500501c06e9a13398a8
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
A subsequent patch makes use of non-trivial types in struct so_list.
This trips on the fact that svr4_copy_library_list uses memcpy to copy
so_list objects:
so_list *newobj = new so_list;
memcpy (newobj, src, sizeof (struct so_list));
solib-svr4 maintains lists of so_list objects in its own internal data
structures. When requested to return a list of so_list objects (through
target_so_ops::current_sos), it duplicates the internal so_list lists,
using memcpy. When changing so_list to make it non-trivial, we would
need to replace this use of memcpy somehow. That would mean making
so_list copyable, with all the complexity that entails, just to satisfy
this internal usage of solib-svr4 (and solib-rocm, which does the same).
Change solib-svr4 to use its own data type for its internal lists. The
use of so_list is a bit overkill anyway, as most fields of so_list are
irrelevant for this internal use.
- Introduce svr4_so, which contains just an std::string for the name
and a unique_ptr for the lm_info.
- Change the internal so_list lists to be std::vector<svr4_so>. Vector
seems like a good choice for this, we don't need to insert/remove
elements in the middle of these internal lists.
- Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as
everything is managed automatically now.
- Replace svr4_copy_library_list (which duplicated internal lists in
order to return them to the core) with so_list_from_svr4_sos, which
creates an so_list list from a vector of svr4_so.
- Generalize svr4_same a bit, because find_debug_base_for_solib now
needs to compare an so_list and an svr4_so to see if they are the
same.
Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Now that the lm_info class hierarchy has a virtual destructor and
therefore a vtable, use checked_static_cast instead of C-style cases to
ensure (when building in dev mode) that we're casting to the right kind
of lm_info.
Change-Id: I9a99b7d6aa9a44edbe76377d57a7008cfb75a744
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
target_so_ops::free_so is responsible for freeing the specific lm_info
object. All implementations basically just call delete. Remove that
method, make the destructor of lm_info virtual, and call delete directly
from the free_so function. Make the sub-classes final, just because
it's good practice.
Change-Id: Iee1fd4861c75034a9e41a656add8ed8dfd8964ee
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
The base class doesn't need to have "_base" in its name, all the
sub-classes have a specific suffix.
Change-Id: I87652105cfedd87898770a81f0eda343ff7f2bdb
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Initialize all fields in the class declaration, change allocations to
use "new", change deallocations to use "delete". This is needed by a
subsequent patches that use C++ stuff in so_list.
Change-Id: I4b140d9f1ec9ff809554a056f76e3eb2b9e23222
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
It is only used in solib.c.
Change-Id: I43461d13d84d65c4f6913d4033678d8983b9910b
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
A subsequent patch changes so_list to be linked using
intrusive_list. Iterating an intrusive_list yields some references to
the list elements. Convert some functions accepting so_list objects to
take references, to make things easier and more natural. Add const
where possible and convenient.
Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
A subsequent patch changes the interp::on_solib_loaded and
interp::on_solib_unloaded methods to take references. This highlighted
that interps_notify did not work with reference parameters.
Fix that by changing interps_notify's `args` arg to be a universal
reference (&&). Change the type of the method to be auto-deduced as an
additional template parameter, otherwise the signature of the callback
function would never match:
CXX interps.o
/home/simark/src/binutils-gdb/gdb/interps.c: In function ‘void interps_notify_signal_received(gdb_signal)’:
/home/simark/src/binutils-gdb/gdb/interps.c:378:18: error: no matching function for call to ‘interps_notify(void (interp::*)(gdb_signal), gdb_signal&)’
378 | interps_notify (&interp::on_signal_received, sig);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: candidate: ‘template<class ... Args> void interps_notify(void (interp::*)(Args ...), Args&& ...)’
363 | interps_notify (void (interp::*method) (Args...), Args&&... args)
| ^~~~~~~~~~~~~~
/home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: template argument deduction/substitution failed:
/home/simark/src/binutils-gdb/gdb/interps.c:378:18: note: inconsistent parameter pack deduction with ‘gdb_signal’ and ‘gdb_signal&’
378 | interps_notify (&interp::on_signal_received, sig);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: I0cd9378e24ef039f30f8e14f054f8d7fb539c838
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
The clear_solib is implicitly meant to clear the resources associated to
the current program space (that's what the solib implementations that
actually support multi-program-space / multi-inferior do). Make that
explicit by adding a program_space parameter and pass down
current_program_space in call sites. The implementation of the
clear_solib callbacks is fairly simple, I don't think any of them rely
on global state other than accessing current_program_space.
Change-Id: I8d0cc4db7b4f8db8d7452879c0c62db03269bf46
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Make the target_so_ops::clear_solib method optional, remove two empty
implementations.
Change-Id: Ifda297d50c74327d337091c58cdb5b3b60382591
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
multi-inferior-gpu.exp
The gdb.rocm/multi-inferior-gpu.exp testcase uses a "continue $thread"
command, but this is incorrect. If "continue" is given an argument, it
sets the ignore count of the breakpoint the thread stopped at.
For this testcase it does not really matter since the breakpoint is not
meant to be hit anymore, so whatever the ignore count is won't influence
the outcome of the test. It is worth fixing nevertheless.
Change-Id: I0eb674d5529cdeb9e808b74870a29b6077265737
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Functions of the hip runtime returning a hipError_t can be marked
nodiscard depending on the configuration[1] (when compiled with C++17).
This patch makes sure that we always check the value returned by
hipDeviceSynchronize and friends, and print an error message when
appropriate. This avoid a wall of warnings when running the testsuite
if the compiler defaults to using C++17.
It is always a good practice to check the return values anyway.
[1] https://github.com/ROCm-Developer-Tools/HIP/blob/docs/5.7.1/include/hip/hip_runtime_api.h#L203-L218
Change-Id: I2a819a8ac45f4bcf814efe9a2ff12c6a7ad22f97
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
When running test-case gdb.base/jit-bfd-name.exp, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.base/jit-bfd-name.exp.
ERROR: can't read "start": no such variable
...
The problem is that commit c96ceed9dce ("gdb: include the end address in
in-memory bfd filenames") introduced a use of variable start, but not a
definition.
Fix this by adding the missing definition.
Tested on x86_64-linux.
|
|
While reviewing gdb/dwarf2/index-write.c I noticed two style issues.
Fix these.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Post-commit review pointed out a few style issues in commit 8b9c08eddac
("[gdb/symtab] Add name_of_main and language_of_main to the DWARF index").
Fix these.
Tested on x86_64-linux.
Reported-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Commit
66984afd29e gdb: include the base address in in-memory bfd filenames
added the base address to in-memory bfd filenames. Also add the end
address to allow dumping the in-memory bfd using the 'dump memory'
command.
|
|
In source_cache::ensure, keep track of which files failed to be styled, and
don't attempt to style them again in case the file dropped out of the cache.
Tested on x86_64-linux.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
Function source_cache::ensure contains some code using the GNU
source-highlight library.
The code is a sizable part of the function, and contains conditional
compilation in a slightly convoluted way:
...
if (!already_styled)
#endif /* HAVE_SOURCE_HIGHLIGHT */
{
...
Fix this by factoring out the code into new function try_source_highlight,
such that:
- source_cache::ensure is easier to read, and
- the conditional compilation is at the level of the function body.
Tested on x86_64-linux.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
In function source_cache::ensure we have:
...
std::ostringstream output;
...
contents = output.str ();
...
The last line causes an unnecessary string copy.
C++20 allows us to skip it, like this:
...
contents = std::move (output).str ();
...
Use the more efficient solution.
Tested on x86_64-linux.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
|
|
This header is only suitable for use on x86 hosts and is only included
there, so these fallbacks should not be needed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I found that these local declarations were not needed, remove them.
Tested by rebuilding.
Change-Id: I8d4fd0839ee1063b91dc002216d683aee0d4be22
|
|
A pretty-printer's 'children' method may return values other than a
gdb.Value -- it may return any value that can be converted to a
gdb.Value.
I noticed that this case did not work for DAP. This patch fixes the
problem.
|
|
Andry pointed out that the DAP code did not properly handle
gdb.LazyString results from a pretty-printer, yielding:
TypeError: Object of type LazyString is not JSON serializable
This patch fixes the problem, partly with a small patch in varref.py,
but mainly by implementing tp_str for LazyString.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Andry noticed that given a DAP setExpression request, where the
expression to set is a register, DAP will return the wrong value -- it
will return the old value, not the updated one.
This happens because gdb.Value.assign (which was recently added for
DAP) does not update the value.
In this patch, I chose to have the assign method update the Value
in-place. It's also possible to have it return a new value, but this
didn't seem very useful to me.
|
|
Andry Ogorodnik, a co-worker, noticed that multiple "scopes" requests
with the same frame would yield different variableReference values in
the response.
This patch adds a regression test for this, and adds a scope cache in
scopes.py, ensuring that multiple identical requests will get the same
response.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
When using glibc debuginfo generated with gas 2.39, we run into PR gas/29517:
...
$ gdb -q -batch a.out -ex start -ex "p (char *)strstr (\"haha\", \"ah\")"
Temporary breakpoint 1 at 0x40051b: file hello.c, line 6.
Temporary breakpoint 1, main () at hello.c:6
6 printf ("hello\n");
Invalid cast.
...
while without glibc debuginfo installed we get the expected result:
...
$n = 0x7ffff7daa1b1 "aha"
...
and likewise with glibc debuginfo generated with gas 2.40.
The strstr ifunc resolves to __strstr_sse2_unaligned. The problem is that gas
generates dwarf that states that the return type is void:
...
<1><3e1e58>: Abbrev Number: 2 (DW_TAG_subprogram)
<3e1e59> DW_AT_name : __strstr_sse2_unaligned
<3e1e5d> DW_AT_external : 1
<3e1e5e> DW_AT_low_pc : 0xbbd2e
<3e1e66> DW_AT_high_pc : 0xbc1c3
...
while the return type should be a DW_TAG_unspecified_type, as is the case
with gas 2.40.
We can still use the workaround of casting to another function type for both
__strstr_sse2_unaligned:
...
(gdb) p ((char * (*) (const char *, const char *))__strstr_sse2_unaligned) \
("haha", "ah")
$n = 0x7ffff7daa211 "aha"
...
and strstr (which requires using *strstr to dereference the ifunc before we
cast):
...
gdb) p ((char * (*) (const char *, const char *))*strstr) ("haha", "ah")
$n = 0x7ffff7daa251 "aha"
...
but that's a bit cumbersome to use.
Work around this in the dwarf reader, such that we have instead:
...
(gdb) p (char *)strstr ("haha", "ah")
$n = 0x7ffff7daa1b1 "aha"
...
This also requires fixing producer_is_gcc to stop returning true for
producer "GNU AS 2.39.0".
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR symtab/30911
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30911
|
|
Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion in
displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure
is available whenever we have a match between the provided address argument and
the buffer address.
That is fine, but the report in PR30872 shows this assertion triggering when
it really shouldn't. After some investigation, here's what I found out.
The 32-bit Arm architecture is the only one that calls
gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's because
32-bit Arm needs to figure out the thumb state of the original instruction
that we displaced-stepped through the displaced-step buffer.
Before the assertion was put in place by commit
1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of
getting nullptr back, which meant we were not doing a displaced-stepping
operation.
Now, with the assertion in place, this is running into issues.
It looks like displaced_step_buffers::copy_insn_closure_by_addr is
being used to return a couple different answers depending on the
state we're in:
1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr
is supposed to return a valid closure for us, so we can determine the
thumb mode.
2 - If we are not actively displaced-stepping, then copy_insn_closure_by_addr
should return nullptr to signal that there isn't any displaced-step buffers
in use, because we don't have a valid closure (but we should always have
this).
Since the displaced-step buffers are always allocated, but not always used,
that means the buffers will always contain data. In particular, the buffer
addr field cannot be used to determine if the buffer is active or not.
For instance, we cannot set the buffer addr field to 0x0, as that can be a
valid PC in some cases.
My understanding is that the current_thread field should be a good candidate
to signal that a particular displaced-step buffer is active or not. If it is
nullptr, we have no threads using that buffer to displaced-step. Otherwise,
it is an active buffer in use by a particular thread.
The following fix modifies the displaced_step_buffers::copy_insn_closure_by_addr
function so we only attempt to return a closure if the buffer has an assigned
current_thread and if the buffer address matches the address argument.
Alternatively, I think we could use a function to answer the question of
whether we're actively displaced-stepping (so we have an active buffer) or
not.
I've also added a testcase that exercises the problem. It should reproduce
reliably on Arm, as that is the only architecture that faces this problem
at the moment.
Regression-tested on Ubuntu 20.04. OK?
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30872
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This commit replaces the architecture_changed observer with a
new_architecture observer.
Currently the only user of the architecture_changed observer is the
Python code, which uses this observer to register the Python unwinder
with the architecture.
The problem is that the architecture_changed observer is triggered
from inferior::set_arch(), which only sees the inferior-wide gdbarch
value. For targets that use thread-specific architectures, these
never trigger the architecture_changed observer, and so never have the
Python unwinder registered with them.
When it comes to unwinding GDB makes use of the frame's gdbarch, which
is based on the thread's regcache gdbarch, which is set in
get_thread_regcache to the value returned from
target_thread_architecture, which is not always the inferiors gdbarch
value, it might be a thread-specific gdbarch which has not passed
through inferior::set_arch().
The new_architecture observer will be triggered from
gdbarch_find_by_info, whenever a new gdbarch is created and
initialised. As GDB caches and reuses gdbarch values, we should
expect to see each new architecture trigger the new_architecture
observer just once.
After this commit, targets that make use of thread-specific
architectures should be able to make use of Python unwinders.
As I don't have access to a machine that makes use of thread-specific
architectures right now, I asked Luis to confirm that an AArch64
target that uses SVE/SME can't use the Python unwinders in threads
that are using a thread-specific architectures, and he confirmed that
this is indeed the case, see this discussion:
https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com
Tested-By: Lancelot Six <lancelot.six@amd.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
__SVE_VQ_BYTES is only available if SVE definitions are available in
the system's headers, and this is not true for all systems.
For this purpose, we define SVE_VQ_BYTES. This patch fixes the
name of the constant being used.
|
|
A user pointed out that the -lsocket check in gdb should also apply to
gdbserver -- otherwise it can't find the Solaris socketpair. This
patch makes the change. It also removes a couple of redundant
function checks from gdb's configure.ac.
This was tested by the person who reported the bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Simon pointed out that the new file-then-restart.exp test fails with
the extended-remote target board.
The problem is that the test suite doesn't use gdb_file_cmd -- which
handles things like "set remote exec-file". This patch changes
gdb_file_cmd to make the "kill" command optional, and then switches
the test case to use it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"
there exist some failed testcases:
=== gdb Summary ===
# of expected passes 5533
# of unexpected failures 367
The root cause is related with a struct containing floating-point
members as function argument or return value for a dummy call.
(1) Structure consists of one floating-point member within FRLEN bits
wide, it is passed in an FAR if available.
(2) Structure consists of two floating-point members both within FRLEN
bits wide, it is passed in two FARs if available.
(3) Structure consists of one integer member within GRLEN bits wide and
one floating-point member within FRLEN bits wide, it is passed in a
GAR and an FAR if available.
Note that in the above cases, empty structure or union members are also
ignored even in C++.
Here is a simple test on LoongArch:
loongson@bogon:~$ cat test.c
#include<stdio.h>
struct test {
long a;
double b __attribute__((aligned(16)));
};
struct test val = { 88, 99.99 };
int check_arg_struct (struct test arg)
{
printf("arg.a = %ld\n", arg.a);
printf("arg.b = %f\n", arg.b);
printf("sizeof(val) = %d\n", sizeof(val));
return 1;
}
int main()
{
check_arg_struct (val);
return 0;
}
loongson@bogon:~$ gcc -g test.c -o test
loongson@bogon:~$ ./test
arg.a = 88
arg.b = 99.990000
sizeof(val) = 32
Before:
loongson@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:19
19 check_arg_struct (val);
(gdb) p check_arg_struct (val)
arg.a = 140737488286128
arg.b = -nan
sizeof(val) = 32
$1 = 1
...
After:
loongson@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:19
19 check_arg_struct (val);
(gdb) p check_arg_struct (val)
arg.a = 88
arg.b = 99.990000
sizeof(val) = 32
$1 = 1
...
With this patch, there are no failed testcases:
make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp"
=== gdb Summary ===
# of expected passes 5900
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
As reported in bug 30630 [1], we hit a case where the remote target's
async flag is marked while the target is not configured (yet) to work
async. This should not happen. It is caught thanks to this assert in
remote_target::wait:
/* Start by clearing the flag that asks for our wait method to be called,
we'll mark it again at the end if needed. If the target is not in
async mode then the async token should not be marked. */
if (target_is_async_p ())
rs->clear_async_event_handler ();
else
gdb_assert (!rs->async_event_handler_marked ());
This is helpful, but I think that we could have caught the problem earlier than
that, at the moment we marked the handler. Catching problems earlier
makes them easier to debug.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30630
Change-Id: I7e229c74b04da82bef6a817d5a676be5cf52e833
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
A subsequent patch will want to know if the remote is async within a
remote_state method. Add a helper method for that, and for "can async"
as well, for symmetry.
Change-Id: Id0f648ee4896736479fa942f5453eeeb0e5d4352
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Make remote_async_inferior_event_token private (rename to
m_async_event_handler_token) and add methods for the various operations
we do on it. This will help by:
- allowing to break on those methods when debugging
- allowing to add assertions in the methods
Change-Id: Ia3b8a2bc48ad4849dbbe83442c3f83920f03334d
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Change-Id: I88d136b6b5a0a54d1c8a9f8a0068762a5456a29a
|
|
inferior::set_arch calls registers_changed, which invalidates all
regcaches. It would be enough to invalidate only regcaches of threads
belonging to this inferior. Call registers_changed_ptid instead, with
the proper process target / ptid. If the inferior does not have a
process target, there should be no regcaches for that inferior, so no
need to invalidate anything.
Change-Id: Id8b5500acb7f373b01a534f16d3a7d028dc0d882
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This function is just a wrapper around the current inferior's gdbarch.
I find that having that wrapper just obscures where the arch is coming
from, and that it's often used as "I don't know which arch to use so
I'll use this magical target_gdbarch function that gets me an arch" when
the arch should in fact come from something in the context (a thread,
objfile, symbol, etc). I think that removing it and inlining
`current_inferior ()->arch ()` everywhere will make it a bit clearer
where that arch comes from and will trigger people into reflecting
whether this is the right place to get the arch or not.
Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
set_target_gdbarch is basically a setter for the current inferior's
arch, that notifies other parts of GDB of the architecture change. Move
the code of set_target_gdbarch to the inferior::set_arch method.
Add gdbarch_initialized_p, so we can keep the assertion.
Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This is to make it explicit which inferior's architecture just changed,
and that the callbacks should not assume it is the current inferior.
Update the only caller, pyuw_on_new_gdbarch, to add the parameter,
although it doesn't use it currently.
Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Make the inferior's gdbarch field private, and add getters and setters.
This helped me by allowing putting breakpoints on set_arch to know when
the inferior's arch was set. A subsequent patch in this series also
adds more things in set_arch.
Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This commit adds a new Python function, gdb.notify_mi, that can be used
to emit custom async notification to MI channel. This can be used, among
other things, to implement notifications about events MI does not support,
such as remote connection closed or register change.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This commit generalizes serialize_mi_result() to make usable in
different contexts than printing result of custom MI command.
To do so, the check whether passed Python object is a dictionary has been
moved to the caller - at the very least, different uses require different
error messages. Also it has been renamed to serialize_mi_results() to better
match GDB/MI output syntax (see corresponding section in documentation,
in particular rules 'result-record' and 'async-output'.
Since it is now more generic function, it has been moved to py-mi.c.
This is a preparation for implementing Python support for sending custom
MI async events.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This patch adds a new section to the DWARF index containing the name
and the language of the main function symbol, gathered from
`cooked_index::get_main`, if available. Currently, for lack of a better name,
this section is called the "shortcut table". The way this name is both saved and
applied upon an index being loaded in mirrors how it is done in
`cooked_index_functions`, more specifically, the full name of the main function
symbol is saved and `set_objfile_main_name` is used to apply it after it is
loaded.
The main use case for this patch is in improving startup times when dealing with
large binaries. Currently, when an index is used, GDB has to expand symtabs
until it finds out what the language of the main function symbol is. For some
large executables, this may take a considerable amount of time to complete,
slowing down startup. This patch bypasses that operation by having both the name
and language of the main function symbol be provided ahead of time by the index.
In my testing (a binary with about 1.8GB worth of DWARF data) this change brings
startup time down from about 34 seconds to about 1.5 seconds.
When testing the patch with target board cc-with-gdb-index, test-case
gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a
pre-existing issue, filed as PR symtab/30946.
Tested on x86_64-linux, with target board unix and cc-with-gdb-index.
PR symtab/24549
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
This thread:
https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/
pointed out that within gdb.base/maint.exp, some regexps within a
gdb_test_multiple were failing to match a complete line, while later
regexps within the gdb_test_multiple made use of the '^' anchor, and
so assumed that earlier lines had been completely matched and removed
from expect's buffer.
When testing with READ1 set this assumption was failing.
Fix this by extending the offending patterns with a trailing '\r\n'.
Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
This commit a new section for the next release branch, and renames
the section of the current branch, now that it has been cut.
|
|
Now that the GDB 14 branch has been created,
this commit bumps the version number in gdb/version.in to
15.0.50.DATE-git
For the record, the GDB 14 branch was created
from commit 8f12a1a841cd0c447de7a5a0f134a0efece73588.
Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_major to 15.
|
