| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently, there's the location_spec hierarchy, and then some
location_spec subclasses have their own struct type holding all their
data fields.
I.e., there is this:
location_spec
explicit_location_spec
linespec_location_spec
address_location_spec
probe_location_spec
and then these separate types:
explicit_location
linespec_location
where:
explicit_location_spec
has-a explicit_location
linespec_location_spec
has-a linespec_location
This patch eliminates explicit_location and linespec_location,
inlining their members in the corresponding location_spec type.
The location_spec subclasses were the ones currently defined in
location.c, so they are moved to the header. Since the definitions of
the classes are now visible, we no longer need location_spec_deleter.
Some constructors that are used for cloning location_specs, like:
explicit explicit_location_spec (const struct explicit_location *loc)
... were converted to proper copy ctors.
In the process, initialize_explicit_location is eliminated, and some
functions that returned the "data type behind a locspec", like
get_linespec_location are converted to downcast functions, like
as_linespec_location_spec.
Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a
|
|
Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs. This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:
breakpoint::location;
breakpoint::loc;
"location" is the location spec, and "loc" is the resolved locations.
And then, we have a method called "locations()", which returns the
resolved locations as range...
The location spec type is presently called event_location:
/* Location we used to set the breakpoint. */
event_location_up location;
and it is described like this:
/* The base class for all an event locations used to set a stop event
in the inferior. */
struct event_location
{
and even that is incorrect... Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events. E.g., "list" works with location specs.
To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec". Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.
Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
|
|
When testing on openSUSE Leap 15.4 I ran into this FAIL:
...
FAIL: gdb.arch/i386-mpx-map.exp: NULL address of the pointer
...
and likewise for all the other mpx tests.
The problem is that have_mpx is supposed to return 0, but it doesn't because
it tries to match this output:
...
builtin_spawn -ignore SIGHUP temp/20294/have_mpx-2-20294.x^M
No MPX support^M
No MPX support^M
...
using:
...
&& ![string equal $output "No MPX support\r\n"]]
...
Fix this by matching using a regexp instead.
Tested on x86_64-linux.
|
|
I noticed that emit_exiting_event does not check whether there are any
listeners before creating the event object. All other event emitters
do this, so this patch updates this one as well.
|
|
PR python/28533 points out that the Python 'dont_repeat' documentation
is a bit ambiguous about when the method ought to be called. This
patch spells it out.
|
|
For Cortex-M targets, SP register is never detached from msp or
psp, it always has the same value as one of them. Let GDB treat
ARM_SP_REGNUM as an alias similar to what is done in hardware.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
|
|
For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns). To be compatible
with earlier Cortex-M derivates, the msp and psp registers are
aliases for one of the 4 real stack pointer registers.
These are the combinations that exist:
sp -> msp -> msp_s
sp -> msp -> msp_ns
sp -> psp -> psp_s
sp -> psp -> psp_ns
This means that when the GDB client is to show the value of "msp",
the value should always be equal to either "msp_s" or "msp_ns".
Same goes for "psp".
To add a bit more context; GDB does not really use the register msp
(or psp) internally, but they are part of the set of registers which
are provided by the target.xml file. As a result, they will be part
of the set of registers printed by the "info r" command.
Without this particular patch, GDB will hit the assert in the bottom
of arm_cache_get_sp_register function.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29121
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
|
|
For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns). In order to
identify the active one, compare the values of the different
stacks. The value of the initial sp register needs to be fetched to
perform this comparison.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
|
|
After the recent restructuring of the disassembler code, GDB has ended
up with two identical class static functions, both called
dis_asm_read_memory, with identical implementations.
My first thought was to move these out of their respective classes,
and just make them global functions, then I'd only need a single
copy.
And maybe that's the right way to go. But I disliked that by doing
that I loose the encapsulation of the method with the corresponding
disassembler class.
So, instead, I placed the static method into its own class, and had
both the gdb_non_printing_memory_disassembler and gdb_disassembler
classes inherit from this new class as an additional base-class.
In terms of code generated, I don't think there's any significant
difference with this approach, but I think this better reflects how
the function is closely tied to the disassembler.
There should be no user visible changes after this commit.
|
|
This commit started from an observation I made while working on some
other disassembler patches, that is, that the function
gdb_buffered_insn_length, is broken ... sort of.
I noticed that the gdb_buffered_insn_length function doesn't set up
the application data field if the disassemble_info structure.
Further, I noticed that some architectures, for example, ARM, require
that the application_data field be set, see gdb_print_insn_arm in
arm-tdep.c.
And so, if we ever use gdb_buffered_insn_length for ARM, then GDB will
likely crash. Which is why I said only "sort of" broken. Right now
we don't use gdb_buffered_insn_length with ARM, so maybe it isn't
broken yet?
Anyway to prove to myself that there was a problem here I extended the
disassembler self tests in disasm-selftests.c to include a test of
gdb_buffered_insn_length. As I run the test for all architectures, I
do indeed see GDB crash for ARM.
To fix this we need gdb_buffered_insn_length to create a disassembler
that inherits from gdb_disassemble_info, but we also need this new
disassembler to not print anything.
And so, I introduce a new gdb_non_printing_disassembler class, this is
a disassembler that doesn't print anything to the output stream.
I then observed that both ARC and S12Z also create non-printing
disassemblers, but these are slightly different. While the
disassembler in gdb_non_printing_disassembler reads the instruction
from a buffer, the ARC and S12Z disassemblers read from target memory
using target_read_code.
And so, I further split gdb_non_printing_disassembler into two
sub-classes, gdb_non_printing_memory_disassembler and
gdb_non_printing_buffer_disassembler.
The new selftests now pass, but otherwise, there should be no user
visible changes after this commit.
|
|
This commit extends the Python API to include disassembler support.
The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.
To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one. This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.
The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:
DisassembleInfo
Similar to libopcodes disassemble_info structure, has read-only
properties: address, architecture, and progspace. And has methods:
__init__, read_memory, and is_valid.
Each time GDB wants an instruction disassembled, an instance of
this class is passed to a user written disassembler function, by
reading the properties, and calling the methods (and other support
methods in the gdb.disassembler module) the user can perform and
return the disassembly.
Disassembler
This is a base-class which user written disassemblers should
inherit from. This base class provides base implementations of
__init__ and __call__ which the user written disassembler should
override.
DisassemblerResult
This class can be used to hold the result of a call to the
disassembler, it's really just a wrapper around a string (the text
of the disassembled instruction) and a length (in bytes). The user
can return an instance of this class from Disassembler.__call__ to
represent the newly disassembled instruction.
The gdb.disassembler module also provides the following functions:
register_disassembler
This function registers an instance of a Disassembler sub-class
as a disassembler, either for one specific architecture, or, as a
global disassembler for all architectures.
builtin_disassemble
This provides access to GDB's builtin disassembler. A common
use case that I see is augmenting the existing disassembler output.
The user code can call this function to have GDB disassemble the
instruction in the normal way. The user gets back a
DisassemblerResult object, which they can then read in order to
augment the disassembler output in any way they wish.
This function also provides a mechanism to intercept the
disassemblers reads of memory, thus the user can adjust what GDB
sees when it is disassembling.
The included documentation provides a more detailed description of the
API.
There is also a new CLI command added:
maint info python-disassemblers
This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
|
|
This commit is setup for the next commit.
In the next commit I will add a Python API to intercept the print_insn
calls within GDB, each print_insn call is responsible for
disassembling, and printing one instruction. After the next commit it
will be possible for a user to write Python code that either wraps
around the existing disassembler, or even, in extreme situations,
entirely replaces the existing disassembler.
This commit does not add any new Python API.
What this commit does is put the extension language framework in place
for a print_insn hook. There's a new callback added to 'struct
extension_language_ops', which is then filled in with nullptr for Python
and Guile.
Finally, in the disassembler, the code is restructured so that the new
extension language function ext_lang_print_insn is called before we
delegate to gdbarch_print_insn.
After this, the next commit can focus entirely on providing a Python
implementation of the new print_insn callback.
There should be no user visible change after this commit.
|
|
The motivation for this change is an upcoming Python disassembler API
that I would like to add. As part of that change I need to create a
new disassembler like class that contains a disassemble_info and a
gdbarch. The management of these two objects is identical to how we
manage these objects within gdb_disassembler, so it might be tempting
for my new class to inherit from gdb_disassembler.
The problem however, is that gdb_disassembler has a tight connection
between its constructor, and its print_insn method. In the
constructor the ui_file* that is passed in is replaced with a member
variable string_file*, and then in print_insn, the contents of the
member variable string_file are printed to the original ui_file*.
What this means is that the gdb_disassembler class has a tight
coupling between its constructor and print_insn; the class just isn't
intended to be used in a situation where print_insn is not going to be
called, which is how my (upcoming) sub-class would need to operate.
My solution then, is to separate out the management of the
disassemble_info and gdbarch into a new gdb_disassemble_info class,
and make this class a parent of gdb_disassembler.
In arm-tdep.c and mips-tdep.c, where we used to cast the
disassemble_info->application_data to a gdb_disassembler, we can now
cast to a gdb_disassemble_info as we only need to access the gdbarch
information.
Now, my new Python disassembler sub-class will still want to print
things to an output stream, and so we will want access to the
dis_asm_fprintf functionality for printing.
However, rather than move this printing code into the
gdb_disassemble_info base class, I have added yet another level of
hierarchy, a gdb_printing_disassembler, thus the class structure is
now:
struct gdb_disassemble_info {};
struct gdb_printing_disassembler : public gdb_disassemble_info {};
struct gdb_disassembler : public gdb_printing_disassembler {};
In a later commit my new Python disassembler will inherit from
gdb_printing_disassembler.
The reason for adding the additional layer to the class hierarchy is
that in yet another commit I intend to rewrite the function
gdb_buffered_insn_length, and to do this I will be creating yet more
disassembler like classes, however, these will not print anything,
thus I will add a gdb_non_printing_disassembler class that also
inherits from gdb_disassemble_info. Knowing that that change is
coming, I've gone with the above class hierarchy now.
There should be no user visible changes after this commit.
|
|
Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this
removes the need for manual reference count management, and allows the
destructor to be removed.
There should be no functional change after this commit.
I think this cleanup is worth doing on its own, however, in a later
commit I will want to copy instances of gdbpy_err_fetch, and switching
to using gdbpy_ref means that I can rely on the default copy
constructor, without having to add one that handles the reference
counts, so this is good preparation for that upcoming change.
|
|
Just like on s390x with g++ 11.2.1 and ppc64le with g++ 11.3.1 g++ 11
on hppa produces a spurious warning for stringop-overread in
debuginfod_is_enabled for url_view. Just always suppress it on all
arches.
https://sourceware.org/bugzilla/show_bug.cgi?id=29198
gdb/ChangeLog:
* debuginfod-support.c (debuginfod_is_enabled): Always use
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD.
|
|
When running test-case gdb.python/py-mi-cmd.exp on openSUSE Leap 42.3 with
python 3.4, I occasionally run into:
...
Expecting: ^(-pycmd dct[^M
]+)?(\^done,result={hello="world",times="42"}[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd dct^M
^done,result={times="42",hello="world"}^M
(gdb) ^M
FAIL: gdb.python/py-mi-cmd.exp: -pycmd dct (unexpected output)
...
The problem is that the data type used here in py-mi-cmd.py:
...
elif argv[0] == "dct":
return {"result": {"hello": "world", "times": 42}}
...
is a dictionary, and only starting version 3.6 are dictionaries insertion
ordered, so using PyDict_Next in serialize_mi_result doesn't guarantee a
fixed order.
Fix this by allowing the alternative order.
Tested on x86_64-linux.
|
|
Some ravenscar runtimes implement lazy FPU handling. On these
runtimes, the FPU is only initialized when a task tries to use it.
Furthermore, the FP registers aren't automatically saved on a task
switch -- instead, the save is deferred until the new task tries to
use the FPU. Furthermore, each task's context area has a flag
indicating whether the FPU has been initialized for this task.
This patch teaches GDB to understand this implementation. When
fetching or storing registers, GDB now checks to see whether the live
FP registers should be used. If not, the task's saved FP registers
will be used if the task has caused FPU initialization.
Currently only AArch64 uses this code. bb-runtimes implements this
for ARM as well, but GDB doesn't yet have an arm-ravenscar-thread.c.
|
|
Currently, the ravenscar-thread implementation for each architecture
is written by hand. However, these are actually written by
copy-paste. It seems better to switch to a table-driven approach.
The previous code also fetched all registers whenever any register was
requested. This is corrected in the new implementation.
|
|
We found a few bugs in aarch64-ravenscar-thread.c.
First, some of the register offsets were incorrect. The "bb-runtimes"
file for this runtime had the wrong offsets in comments, which GDB
took to be correct. However, those comments didn't account for
alignment. This patch adjusts the offsets.
Next, the "FPU Saved field" is not a register -- it is an
implementation detail of the runtime. This is removed.
Finally, I think the FP registers are actually named V0-V31, and the
"Q" names are pseudo-registers. This patch fixes the comment.
|
|
PR gdb/17160 points out that "interrupt -a" errors in all-stop mode,
but there's no good reason for this. This patch removes the error.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17160
|
|
Implement LoongArch/Linux support, including XML target description
handling based on features determined, GPR regset support, and software
breakpoint handling.
In the Linux kernel code of LoongArch, ptrace implements PTRACE_POKEUSR
and PTRACE_PEEKUSR in the arch_ptrace function, so srv_linux_usrregs is
set to yes.
With this patch on LoongArch:
$ make check-gdb TESTS="gdb.server/server-connect.exp"
[...]
# of expected passes 18
[...]
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
With gcc-12 and target board unix/-m32, we run into:
...
(gdb) ^M
Expecting: ^(-var-create A_String_Access \* A_String_Access[^M
]+)?(\^done,name="A_String_Access",numchild="1",.*[^M
]+[(]gdb[)] ^M
[ ]*)
-var-create A_String_Access * A_String_Access^M
^error,msg="Value out of range."^M
(gdb) ^M
FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
...
What happens is easier to understand if we take things out of the mi context:
...
$ gdb -q -batch \
outputs/gdb.ada/mi_var_access/mi_access \
-ex "b mi_access.adb:19" \
-ex run \
-ex "p A_String_Access"
...
Breakpoint 1, mi_access () at mi_access.adb:19
19 A_String : String (3 .. 5) := "345"; -- STOP
$1 = (pck.string_access) <error reading variable: Value out of range.>
...
while with target board unix we have instead:
...
$1 = (pck.string_access) 0x431b40 <ada_main.sec_default_sized_stacks>
...
The var-create command samples the value of the variable at a location where
the variable is not yet initialized, and with target board unix we
accidentally hit a valid address, but with target board unix/-m32 that's not
the case.
Fix the FAIL by accepting the error message.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28464
|
|
Starting with (future) Clang 15 (since
https://reviews.llvm.org/D120989), Clang emits the DWARF information
of global alias variables as DW_TAG_imported_declaration. However,
GDB does not handle it. It incorrectly always reads this tag as
C++/Fortran imported declaration (type alias, namespace alias and
Fortran module). This commit adds support to handle this tag as an
alias variable.
This change fixes the failures in the gdb.base/symbol-alias.exp
testcase with current git Clang. This testcase is also updated to
test nested (recursive) aliases.
|
|
When running test-case gdb.reverse/test_ioctl_TCSETSW.exp with glibc debuginfo
installed, I run into:
...
(gdb) PASS: gdb.reverse/test_ioctl_TCSETSW.exp: at TCSETSW call
step^M
__tcsetattr (fd=0, optional_actions=1, termios_p=0x7fffffffcf50) at \
../sysdeps/unix/sysv/linux/tcsetattr.c:45^M
45 {^M
(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: handle TCSETSW
...
The problem is that the step is expected to step over the call to tcsetattr,
but due to glibc debuginfo being installed, we step into the call.
Fix this by using next instead of step.
Tested on x86_64-linux.
|
|
With --enable-targets=all we have:
...
$ gdb -q -batch -ex "maint selftest"
...
Running selftest regcache::cooked_read_test::m68hc11.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
Running selftest regcache::cooked_read_test::m68hc12.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
Running selftest regcache::cooked_read_test::m68hc12:HCS12.
warning: No frame soft register found in the symbol table.
Stack backtrace will not work.
...
Likewise for regcache::cooked_write_test.
The warning has no use in the selftest context.
Fix this by skipping the specific selftests.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29224
|
|
We can't put a breakpoint in the middle of a ll/sc atomic sequence,
so look for the end of the sequence and put the breakpoint there.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Results in configure output like:
```
checking for X... no
/var/tmp/portage/sys-devel/gdb-12.1/work/gdb-12.1/gdb/configure: 18837: test: yes: unexpected operator
checking whether to use babeltrace... auto
```
... when /bin/sh is provided by a POSIX-compliant shell, like dash,
instead of bash.
|
|
Registers in CSKY architecture included:
1. 32 gprs
2. 16 ars (alternative gprs used for quick interrupt)
3. hi, lo, pc
4. fr0~fr31, fcsr, fid, fesr
5. vr0~vr15
6. ((32 banks) * 32) cr regs (max 32 banks, 32 control regs a bank)
For register names:
Except over control registers, other registers, like gprs, hi, lo ...
are fixed names. Among the 32*32 control registers, some used registers
will have fixed names, others will have a default name "cpxcry". 'x'
refers to bank, y refers index in the bank(a control register in bank
4 with index 14 will has a default name cp4cr14).
For register numbers in GDB:
We assign a fixed number to each register in GDB, like:
r0~r31 with 0~31
hi, lo with 36, 37
fpu/vpu with 40~71
...
described in function csky_get_supported_register_by_index().
Function csky_get_supported_tdesc_registers_count():
To calculate the total number of registers that GDB can analyze,
including those with fixed names and those with default register names.
Function csky_get_supported_register_by_index():
To find a supported struct csky_supported_tdesc_register, return a
struct include name with regnum via index.
Arrays csky_supported_tdesc_feature_names[]:
Include all supported feature names in tdesc-xmls.
We use the information described above to load the register description
file of the target from the stub. When loading, do a little check that
whether the register description file contains SP, LR and PC.
|
|
On openSUSE Leap 42.3 with python 3.4, I run into:
...
(gdb) python import pygments^M
Traceback (most recent call last):^M
File "<string>", line 1, in <module>^M
ImportError: No module named 'pygments'^M
Error while executing Python code.^M
(gdb) FAIL: gdb.base/style.exp: python import pygments
ERROR: unexpected output from python import
...
because gdb_py_module_available doesn't handle the single quotes around the
module name in the ImportError.
Fix this by allowing the single quotes.
Tested on x86_64-linux.
|
|
Mark pointed out that my recent addrmap C++-ficiation changes caused a
regression in the self-tests. This patch fixes the problem by
updating this test not to allocate the mutable addrmap on an obstack.
|
|
While working on addrmaps, I noticed that psymtab_addrmap is no longer
needed now. It was introduced in ancient times as an optimization for
DWARF, but no other symbol reader was ever updated to use it. Now
that DWARF does not use psymtabs, it can be deleted.
|
|
Mutable addrmaps currently require an obstack. This was probably done
to avoid having to call splay_tree_delete, but examination of the code
shows that all mutable obstacks have a limited lifetime -- now it's
simple to treat them as ordinary C++ objects, in some cases
stack-allocating them, and have a destructor to make the needed call.
This patch implements this change.
|
|
addrmap::create_fixed is just a simple wrapper for 'new', so remove it
in favor of uses of 'new'.
|
|
This removes addrmap_create_mutable in favor of using 'new' at the
spots where the addrmap is created.
|
|
This removes the various addrmap wrapper functions in favor of simple
method calls on the objects themselves.
|
|
This moves the addrmap class definitions to addrmap.h. This is safe
to do now that the contents are private.
|
|
This changes addrmap_mutable so that its data members are private.
|
|
This changes addrmap_fixed so that its data members are private.
It also makes struct addrmap_transition private as well.
|
|
This is a simply C++-ification of the basics of addrmap: it uses
virtual methods rather than a table of function pointers, and it
changes the concrete implementations to be subclasses.
|
|
* Remove a stray semicolon
* Restore dropped nullptr program argument in use of create_process() under CYGWIN
|
|
Prior to c6ca3dab dropping support for Cygwin 1.5, __USEWIDE was not
defined for Cygwin 1.5. After that, it's always defined if __CYGWIN__
is, so remove __USEWIDE conditionals inside __CYGWIN__ conditionals.
|
|
Prior to c6ca3dab dropping support for Cygwin 1.5, cygwin_buf_t was
defined as char for Cygwin 1.5. After that, it's always wchar_t, so
just use that.
|
|
With the registry rewrite series, on Fedora 34, I started seeing this
error in xcoffread.c:
../../binutils-gdb/gdb/xcoffread.c: In function ‘void read_xcoff_symtab(objfile*, legacy_psymtab*)’:
../../binutils-gdb/gdb/xcoffread.c:948:25: error: ‘main_aux’ is used uninitialized [-Werror=uninitialized]
948 | union internal_auxent fcn_aux_saved = main_aux;
| ^~~~~~~~~~~~~
../../binutils-gdb/gdb/xcoffread.c:933:25: note: ‘main_aux’ declared here
933 | union internal_auxent main_aux;
| ^~~~~~~~
I don't know why this error started suddenly... that seems weird,
because it's not obviously related to the changes I made.
Looking into it, it seems this line was intended to avoid a similar
warning -- but since 'main_aux' is uninitialized at the point where it
is used, this fix was incomplete.
This patch avoids the warning by initializing using "{}". I'm
checking this in.
|
|
The if statement in case gdb_sys_ioctl in function
record_linux_system_call in file gdb/linux-record.c is as follows:
if (tmpulongest == tdep->ioctl_FIOCLEX
|| tmpulongest == tdep->ioctl_FIONCLEX
....
|| tmpulongest == tdep->ioctl_TCSETSW
...
}
The PowerPC ioctl value for ioctl_TCSETW is 0x802c7415. The variable
ioctl_TCSETW is defined in gdb/linux-record.h as an int. The TCSETW value
has the MSB set to one so it is a negative integer. The comparison of the
unsigned long value tmpulongest to a negative integer value for
ioctl_TCSETSW fails.
This patch changes the declarations for the ioctl_* values in struct
linux_record_tdep to unsigned long to fix the comparisons between
tmpulongest and the tdep->ioctl_* values.
An additional test gdb.reverse/test_ioctl_TCSETSW.exp is added to verify
the gdb record_linux_system_call() if statement for the ioctl TCSETSW
succeeds.
This patch has been tested on Power 10 and Intel with no test failures.
|
|
Some of the ioctl numbers are based on the size of kernel termios structure.
Currently the PowerPC GDB definitions are "hard coded" into the ioctl
number.
The current PowerPC values for TCGETS, TCSETS, TCSETSW and TCSETSF are
defined in gdb/ppc-linux-tdep.c as:
record_tdep->ioctl_TCGETS = 0x403c7413;
record_tdep->ioctl_TCSETS = 0x803c7414;
record_tdep->ioctl_TCSETSW = 0x803c7415;
record_tdep->ioctl_TCSETSF = 0x803c7416;
Where the termios structure size is in hex digits [5:4] as 0x3c.
The definition for the PowerPC termios structure is given in:
arch/powerpc/include/uapi/asm/termbits.h
The size of the termios data structure in this file is 0x2c not 0x3c.
This patch changes the hex digits for the size of the PowerPC termios size
in the ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF to 0x2c.
This patch also changes the hard coding to generate the number based on a
it easier to update the ioctl numbers.
|
|
Since pretty much forever the get_compiler_info function has included
these lines:
# Most compilers will evaluate comparisons and other boolean
# operations to 0 or 1.
uplevel \#0 { set true 1 }
uplevel \#0 { set false 0 }
These define global variables true (to 1) and false (to 0).
It seems odd to me that these globals are defined in
get_compiler_info, I guess maybe the original thinking was that if a
compiler had different true/false values then we would detect it there
and define true/false differently.
I don't think we should be bundling this logic into get_compiler_info,
it seems weird to me that in order to use $true/$false a user needs to
first call get_compiler_info.
It would be better I think if each test script that wants these
variables just defined them itself, if in the future we did need
different true/false values based on compiler version then we'd just
do:
if { [test_compiler_info "some_pattern"] } {
# Defined true/false one way...
} else {
# Defined true/false another way...
}
But given the current true/false definitions have been in place since
at least 1999, I suspect this will not be needed any time soon.
Given that the definitions of true/false are so simple, right now my
suggestion is just to define them in each test script that wants
them (there's not that many). If we ever did need more complex logic
then we can always add a function in gdb.exp that sets up these
globals, but that seems overkill for now.
There should be no change in what is tested after this commit.
|
|
This variable is useful when exercising AArch64 multi-arch support (debugging
32-bit AArch32 executables).
Unfortunately it isn't well documented. This patch adds information about it
and explains how to use it.
|
|
With gcc-12, I get for test-case gdb.base/vla-struct-fields.exp:
...
(gdb) print inner_vla_struct_object_size == sizeof(inner_vla_struct_object)^M
$7 = 1^M
(gdb) XPASS: gdb.base/vla-struct-fields.exp: size of inner_vla_struct_object
...
Fix this by limiting the xfailing to gcc-11 and earlier. Also, limit the
xfailing to the equality test.
Tested on x86_64-linux.
|
|
On openSUSE Tumbleweed with gcc-12, I run into a timeout:
...
(gdb) print value^M
Multiple matches for value^M
[0] cancel^M
[1] ada.strings.maps.value (<ref> ada.strings.maps.character_mapping; \
character) return character at a-strmap.adb:599^M
[2] pck.value at src/gdb/testsuite/gdb.ada/ghost/pck.ads:17^M
[3] system.object_reader.value (<ref> system.object_reader.object_symbol) \
return system.object_reader.uint64 at s-objrea.adb:2279^M
[4] system.traceback.symbolic.value (system.address) return string at \
s-trasym.adb:200^M
> FAIL: gdb.ada/ghost.exp: print value (timeout)
print ghost_value^M
Argument must be choice number^M
(gdb) FAIL: gdb.ada/ghost.exp: print ghost_value
...
Fix this by prefixing value (as well as the other printed values) with the
package name:
...
(gdb) print pck.value^M
...
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29055
|
|
I noticed that the Python event documentation referred to the event's
"breakpoint" field as a function, whereas it is actually an attribute.
This patch fixes the error.
|
