Tom de Vries [Wed, 13 Nov 2024 21:38:19 +0000 (22:38 +0100)]
[gdb/contrib] Handle capitalized words in spellcheck.sh
The dictionary contains a few entries with capital letters:
...
$ grep -E '[A-Z]' .git/wikipedia-common-misspellings.txt | wc -l
143
...
but they don't look too interesting in the gdb context (for instance,
Habsbourg->Habsburg), so filter them out.
That leaves us with entries looking only like "foobat->foobar", so add
handling of capitalized words, such that we also rewrite "Foobat" to "Foobar".
Tested on aarch64-linux. Verified with shellcheck.
Tom de Vries [Wed, 13 Nov 2024 20:06:58 +0000 (21:06 +0100)]
[gdb/contrib] Handle double quotes in spellcheck.sh
Add handling of double quotes in gdb/contrib/spellcheck.sh, and fix the
following typos:
...
inheritence -> inheritance
psuedo -> pseudo
succeded -> succeeded
...
Tom de Vries [Wed, 13 Nov 2024 20:03:42 +0000 (21:03 +0100)]
[precommit] Add some documentation in .pre-commit-config.yaml
Add some documention to .pre-commit-config.yaml that explains:
- what the file is,
- how it can be used, and
- how to skip specific hooks in case of trouble.
Tom de Vries [Wed, 13 Nov 2024 18:44:21 +0000 (19:44 +0100)]
[gdb/tdep] Fix recording of T1 push
When running test-case gdb.reverse/recursion.exp on arm-linux with target
board unix/-mthumb, I run into:
...
(gdb) PASS: gdb.reverse/recursion.exp: Skipping recursion from inside
reverse-next^M
bar (x=4195569) at /home/linux/gdb/src/gdb/testsuite/gdb.reverse/recursion.c:34^M
34 int r = foo (x);^M
(gdb) FAIL: gdb.reverse/recursion.exp: print frame when stepping out
...
The problem is the recording of the T1 push instruction [1,2], specifically:
... 000004d8 <foo>:
4d8: b580 push {r7, lr}
...
The current code fails to add a memory record for the memory written with the
value of the lr register.
Tom de Vries [Wed, 13 Nov 2024 18:37:04 +0000 (19:37 +0100)]
[gdb/tdep] Handle sycall statx for arm-linux
When running test-case gdb.reverse/fstatat-reverse.exp on arm-linux, I run
into:
...
(gdb) continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 397^M
Process record does not support instruction 0xdf00 at address 0xf7ebf774.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7ebf774 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2
...
Syscall number 397 stands for statx on arm-linux.
Fix this by handling 397 in arm_canonicalize_syscall.
Tested on arm-linux.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Luis Machado <luis.machado@arm.com>
And I have written the stand alone test for this issue. The original
patch included this paragraph to explain this change (I've fixed one
typo in this text replacing 'program' with 'function'):
... it may happen that the infrun machinery steps from one inline
range to another inline range of the same inline function. That can
look like jumping back and forth from the calling function to the
inline function, while really the inline function just jumps from a
hot to a cold section of the code, i.e. error handling.
The important thing that happens here is that both the outer function
and the inline function must both have multiple ranges. When the
inferior is within the inline function and moves from one range to
another it is critical that the address we stop at is the start of a
range in both the outer function and the inline function.
The diagram below represents how the functions are split and aligned:
(A) (B)
bar: |------------| |---|
foo: |------------------| |--------|
The inferior is stepping through 'bar' and eventually reaches
point (A) at which point control passes to point (B).
Currently, when the inferior stops, GDB notices that both 'foo' and
'bar' start at address (B), and so GDB uses the inline frame mechanism
to skip 'bar' and tells the user that the inferior is in 'foo'.
However, as we were in 'bar' before the step then it makes sense that
we should be in 'bar' after the step, and this is what the patch does.
There are two tests using the DWARF assembler, the first checks the
above situation and ensures that GDB reports 'bar' after the step.
The second test is similar, but after the step we enter a new range
where a different inline function starts, something like this:
(A) (B)
bar: |------------|
baz: |---|
foo: |------------------| |--------|
In this case as we step at (A) and land at (B) we leave 'bar' and
expect to stop in 'foo', GDB shouldn't automatically enter 'baz' as
that is a completely different inline function. And this is, indeed,
what we see.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Andrew Burgess [Thu, 10 Oct 2024 10:37:34 +0000 (11:37 +0100)]
gdb: fix handling of DW_AT_entry_pc of inlined subroutines
The entry PC for a DIE, e.g. an inline function, might not be the base
address of the DIE. Currently though, in block::entry_pc(), GDB
always returns the base address (low-pc or the first address of the
first range) as the entry PC.
This commit extends the block class to carry the entry PC as a
separate member variable. Then the DWARF reader is extended to read
and set the entry PC for the block. Now in block::entry_pc(), if the
entry PC has been set, this is the value returned.
If the entry-pc has not been set to a specific value then the old
behaviour of block::entry_pc() remains, GDB will use the block's base
address. Not every DIE will set the entry-pc, but GDB still needs to
have an entry-pc for every block, so the existing logic supplies the
entry-pc for any block where the entry-pc was not set.
The DWARF-5 spec for reading the entry PC is a super-set of the spec
as found in DWARF-4. For example, if there is no DW_AT_entry_pc then
DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base
address, which is DW_AT_low_pc or the first address in the first range
specified by DW_AT_ranges if there is no DW_AT_low_pc.
I have taken the approach of just implementing the DWARF-5 spec for
everyone. There doesn't seem to be any benefit to deliberately
ignoring a ranges based entry PC value for DWARF-4. If some naughty
compiler has emitted that, then lets use it.
Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5
allows an address or a constant, where the constant is an offset from
the base address. I allow both approaches for all DWARF versions.
There doesn't seem to be any downsides to this approach.
I ran into an issue when testing this patch where GCC would have the
DW_AT_entry_pc point to an empty range. When GDB parses the ranges
any empty ranges are ignored. As a consequence, the entry-pc appears
to be outside the address range of a block.
The empty range problem is certainly something that we can, and should
address, but that is not the focus of this patch, so for now I'm
ignoring that problem. What I have done is added a check: if the
DW_AT_entry_pc is outside the range of a block then the entry-pc is
ignored, GDB will then fall-back to its default algorithm for
computing the entry-pc.
If/when in the future we address the empty range problem, these
DW_AT_entry_pc attributes will suddenly become valid and GDB will
start using them. Until then, GDB continues to operate as it always
has.
An early version of this patch stored the entry-pc within the block
like this:
std::optional<CORE_ADDR> m_entry_pc;
However, a concern was raised that this, on a 64-bit host, effectively
increases the size of block by 16-bytes (8-bytes for the CORE_ADDR,
and 8-bytes for the std::optional's bool plus padding).
If we remove the std::optional part and just use a CORE_ADDR then we
need to have a "special" address to indicate if m_entry_pc is in use
or not. I don't really like using special addresses; different
targets can access different address ranges, even zero is a valid
address on some targets.
However, Bernd Edlinger suggested storing the entry-pc as an offset,
and I think that will resolve my concerns. So, we store the entry-pc
as a signed offset from the block's base address (the first address of
the first range, or the start() address value if there are now
ranges). Remember, ranges can be out of order, in which case the
first address of the first range might be greater than the entry-pc.
When GDB needs to read the entry-pc we can add the offset onto the
blocks base address to recalculate it.
With this done, on a 64-bit host, block only needs to increase by
8-bytes.
The inline-entry.exp test was originally contributed by Bernd here:
though I have made some edits, making more use of lib/gdb.exp
functions, making the gdb_test output patterns a little tighter, and
updating the test to run with Clang. I also moved the test to
gdb.opt/ as that seemed like a better home for it.
Mark Harmstone [Sat, 2 Nov 2024 22:05:06 +0000 (22:05 +0000)]
gas: add .cv_ucomp and .cv_scomp pseudo-directives
Add .cv_ucomp and .cv_scomp pseudo-directives for object files for
Windows targets, which encode compressed CodeView integers according to
the algorithm in CVCompressData in
https://github.com/Microsoft/microsoft-pdb/blob/master/include/cvinfo.h.
This is essentially Microsoft's answer to the LEB128, though used in far
fewer places.
CodeView uses these to encode the "binary annotations" in the
S_INLINESITE symbol, which express the relationship between code offsets
and line numbers in inlined functions. This has to be done in the
assembler as GCC doesn't know how many bytes each instruction takes up.
There's no equivalent for this for MSVC or LLVM, as in both cases the
assembler and compiler are integrated.
.cv_ucomp represents an unsigned big-endian integer between 0 and 0x1fffffff,
taking up 1, 2, or 4 bytes:
.cv_scomp represents a signed big-endian integer between -0xfffffff and
0xfffffff, encoded according to EncodeSignedInt32 in cvinfo.h. The
absolute value of the integer is shifted left one bit, the LSB set
for a negative value, and the result expressed as if it were a
.cv_ucomp: cv_scomp(x) = cv_ucomp((abs(x) << 1) | (x < 0 ? 1 : 0))
Mark Wielaard [Fri, 8 Nov 2024 10:57:30 +0000 (11:57 +0100)]
bfd: Add WARN_CFLAGS_FOR_BUILD to doc/chew.c build, fix warnings
doc/chew.c was compiled without any warning flags set. Adding the
common warnings for build showed various issues with non-static
functions missing prototypes and globals with common names (ptr and
idx) that shadowed local arguments or variables.
Andrew Burgess [Sat, 9 Nov 2024 15:02:15 +0000 (15:02 +0000)]
gdb/testsuite: some cleanups in gdb.base/annota{1,3}.exp tests
Fedora GDB has, for years, carried an out of tree patch for the
gdb.base/annota{1,3}.exp tests. The patch simply adds a call to 'set
breakpoint pending off' near the start of each test.
Normally GDB tests are written using gdb_test or gdb_test_multiple,
with gdb_test being a wrapper around gdb_test_multiple. Inside
gdb_test_multiple we add a test pattern which detects if GDB offers
the user an interactive yes/no prompt and immediately fails the test.
What this means is that if something goes wrong with a test like:
gdb_test "break main" ".*"
and GDB ends up offering this prompt:
Make breakpoint pending on future shared library load? (y or [n])
then instead of hanging waiting for the test to timeout, DejaGNU will
spot the interactive prompt and immediately fail the test.
In the gdb.base/annota{1,3}.exp tests we turn on GDB's annotation
mode, and many of the tests in these scripts are written using
send_gdb and gdb_expect or gdb_expect_list. This is done because in
the past, gdb_test_multiple and friends were hard-coded to use the
"normal" GDB prompt, and these tests instead expect the annotated
prompt. Specifically, gdb_test_multiple expects '$gdb_prompt $' as
the full prompt, that is the value of $gdb_prompt followed by a single
white space. The annotation tests do update the value of $gdb_prompt,
but with annotations on there is no trailing whitespace, so
gdb_test_multiple's default behaviour doesn't work, which is why the
test scripts originally avoided using gdb_test_multiple.
As a result none of the tests in these files would early exit if we
got an interactive yes/no prompt, and instead we'd be relying on each
test to timeout, which could take a while.
However, gdb_test_multiple now accepts a -prompt argument, so we can
modify the prompt we are looking for, which is neat.
So, I started off by going through these tests an changing all of the
tests that create a breakpoint to use gdb_test, passing the -prompt
option to change the prompt.
While doing that I noticed some other things that I could improve in
these tests, I've cleaned up the use of standard_testfile, switched to
use prepare_for_testing, and removed some redundant clean_restart and
'set height 0' calls (set height 0 is done within clean_restart, which
is called by prepare_for_testing).
I've updated some comments which said "we can't use gdb_test" to say
"we can use gdb_test with -prompt option", and I've removed some
commented out debug code (e.g. setting 'exp_internal').
Finally, I ran these two tests through check-all-boards, and spotted
that annota1.exp failed when using a remote host. This is because one
test checks for a full path to the binary in some output, and with a
remote host the binary ends up being copied and the path is not as
expected.
I'm assuming that checking the full path is important, so I've
disabled this test on remote host boards.
After all these changes I checked using 'make check-all-boards' and
there are no unexpected results on either of these tests.
Tested-By: Tom de Vries <tdevries@suse.de> Acked-By: Tom de Vries <tdevries@suse.de>
we are now seeing some duplicate test names in gdb.trace/ tests when
using native-gdbserver or native-extended-gdbserver boards. This is
all due to tests that use some text in trailing parenthesis to make
the test name unique.
I've gone through and edited the test names as best I could to make
them all unique. Hopefully the updated test names should all make
sense.
On my machine I'm no longer seeing any duplicates with either of the
boards listed above.
Andrew Burgess [Wed, 30 Oct 2024 12:16:46 +0000 (12:16 +0000)]
gdb/readline: don't get stuck thinking an EOF arrived
It was brought to my attention[1] that if a user makes use of Ctrl+d
to quit from a secondary prompt (e.g. the prompt used to enter lines
for the 'commands' command) then GDB will start displaying some
unexpected blank lines. Here's an example:
Reading symbols from /tmp/hello.x...
(gdb) break main
Breakpoint 1 at 0x401198: file hello.c, line 18.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>quit # <----------- Use Ctrl+d to quit here.
(gdb) show architecture
# <----------- This blank line is unexpected.
The target architecture is set to "auto" (currently "i386:x86-64").
(gdb)
I've marked up where I press 'Ctrl+d', and also the unexpected blank
line.
This issue will only happen if bracketed-paste-mode is in use. If
this has been disabled (e.g. in ~/.inputrc) then this issue will not
occur.
The blank line is not just emitted for the 'show architecture'
command. The blank line is actually caused by an extra '\n' character
emitted by readline after it has gathered a complete line of input,
and so will occur for any command.
The problem is caused by readline getting "stuck" in a state where it
thinks that an EOF has just been delivered. This state is set when
the 'Ctrl+d' does deliver an EOF, but then this state is never fully
reset. As a result, every time readline completes a line, it thinks
that the line was completed due to an EOF and so adds an extra '\n'
character.
Obviously the real fix for this issue is to patch readline, and I do
have a patch for that[2], however, version 8.2 of readline has been
released, and contains this issue. As such, if GDB is linked against
the system readline, and that system readline is 8.2, then we can
expect to see this issue.
There's a pretty simple, and cheap workaround that we can add to GDB
that will mitigate this issue.
I propose that we add this workaround to GDB. If/when the readline
patch is accepted then I'll back-port this to our local readline copy,
but retaining the workaround will be harmless, and will make GDB play
nicer with system readline libraries (version 8.2).
Andrew Burgess [Wed, 30 Oct 2024 11:44:23 +0000 (11:44 +0000)]
gdb/readline: add readline library version to 'show configuration'
When debugging readline issues I'd like an easy way to know (for sure)
what version of readline GDB is using. This could also be useful when
writing readline tests, knowing the precise readline version will
allow us to know if we expect a test to pass or not.
Add the readline library version to the output of the 'show
configuration' command. Also include a suffix indicating if we are
using the system readline, or the statically linked in readline.
The information about static readline vs shared readline can be
figured out from the configure command output, but having it repeated
in the readline version line makes it super easy to grok within tests,
and it's super cheap, so I don't see this as a problem.
Andrew Burgess [Fri, 4 Oct 2024 18:30:04 +0000 (19:30 +0100)]
gdbserver: pass osabi to GDB in more target descriptions
Problem Description
-------------------
On a Windows machine I built gdbserver, configured for the target
'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with
support for all target (--enable-targets=all).
On the Windows machine I start gdbserver with a small test binary:
On the GNU/Linux machine I start GDB without the test binary, and
connect to gdbserver.
As I have not given GDB the test binary, my expectation is that GDB
would connect to gdbserver and then download the file over the remote
protocol, but instead I was presented with this message:
(gdb) target remote 192.168.129.25:54321
Remote debugging using 192.168.129.25:54321
warning: C:\some\directory\executable.exe: No such file or directory.
0x00007ffa3e1e1741 in ?? ()
(gdb)
What I found is that if I told GDB where to find the binary, like
this:
(gdb) file target:C:/some/directory/executable.exe
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading C:/some/directory/executable.exe from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading C:/some/directory/executable.exe from remote target...
Reading symbols from target:C:/some/directory/executable.exe...
(gdb)
then GDB would download the executable.
The Actual Issue
----------------
I tracked the problem down to exec_file_find (solib.c). The remote
target was passing an absolute Windows filename (beginning with "C:/"
in this case), but in exec_file_find GDB was failing the
IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as
relative.
The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that
the file system kind was "unix", and as the filename didn't start with
a "/" it assumed the filename was not absolute.
But I'm connecting to a Windows target and 'target-file-system-kind'
was set to "auto", so GDB should be figuring out that the target
file-system is "dos-based".
Looking in effective_target_file_system_kind (filesystem.c), we find
that the logic of "auto" is delegated to the current gdbarch. However
in windows-tdep.c we see:
So if we are using a Windows gdbarch we should have "dos-based"
filesystems. What this means is that after connecting to the remote
target GDB has selected the wrong gdbarch.
What's happening is that the target description sent back by the
remote target only includes the x86-64 registers. There's no
information about which OS we're on. As a consequence, GDB picks the
first x86-64 gdbarch which can handle the provided register set, which
happens to be a GNU/Linux gdbarch.
And indeed, there doesn't appear to be anywhere in gdbserver that sets
the osabi on the target descriptions. Some target descriptions do have
their osabi set when the description is created, e.g. in:
gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate.
gdb/arch/i386.c - Likewise.
gdb/arch/tic6x.c - Always set GNU/Linux osabi.
There are also some cases in gdb/features/*.c where the tdesc is set,
but these locations are only called from GDB, not from gdbserver.
This means that many target descriptions are created without an osabi,
gdbserver does nothing to fix this, and the description is returned to
GDB without an osabi included. This leaves GDB having to guess what
the target osabi is, and in some cases, GDB can get this wrong.
Proposed Solution
-----------------
I propose to change init_target_desc so that it requires an gdb_osabi
to be passed in, this will then be used to set the target_desc osabi
field.
I believe that within gdbserver init_target_desc is called for every
target_desc, so this should mean that every target_desc has an
opportunity to set the osabi to something sane.
I did consider passing the osabi into the code which creates the
target_desc objects, but that would require updating far more code, as
each target has its own code for creating target descriptions.
The approach taken here requires minimal changes and forces every
user of init_target_desc to think about what the correct osabi is.
In some cases, e.g. amd64, where the osabi is already set when the
target_desc is created, the init_target_desc call will override the
current value, however, we should always be replacing it with the same
actual value. i.e. if the target_desc is created with the osabi set
to GNU/Linux, then this should only happen when gdbserver is built for
GNU/Linux, in which case the init_target_desc should also be setting
the osabi to GNU/Linux.
The Tricky Bits
---------------
Some targets, like amd64, use a features based approach for creating
target_desc objects, there's a function in arch/amd64.c which creates
a target_desc, adds features too it, and returns the new target_desc.
This target_desc is then passed to an init_target_desc call within
gdbserver. This is the easy case to handle.
Then there are other targets which instead have a fixed set of xml
files, each of which is converted into a .dat file, which is then used
to generate a .cc file, which is compiled into gdbserver. The
generated .cc file creates the target_desc object and calls
init_target_desc on it. In this case though the target description
that is sent to GDB isn't generated from the target_desc object, but
is instead the contents of the fixed xml file. For this case the
osabi which we pass to init_target_desc should match the osabi that
exists in the fixed xml file.
Luckily, in the previous commit I copied the osabi information from
the fixed xml files into the .dat files. So in this commit I have
extended regdat.sh to read the osabi from the .dat file and use it in
the generated init_target_desc call.
The problem with some of these .dat base targets is that their fixed
xml files don't currently contain any osabi information, and the file
names don't indicate that they are Linux only (despite them currently
only being used from gdbserver for Linux targets), so I don't
currently feel confident adding any osabi information to these files.
An example would be features/rs6000/powerpc-64.xml. For now I've just
ignored these cases. The init_target_desc will use GDB_OSABI_UNKNOWN
which is the default. This means that for these targets nothing
changes from the current behaviour. But many other targets do now
pass the osabi back. Targets that do pass the osabi back are
improved with this commit.
Conclusion
----------
Now when I connect to the Windows remote the target description
returned includes the osabi name. With this extra information GDB
selects the correct gdbarch object, which means that GDB understands
the target has a "dos-based" file-system. With that correct GDB
understands that the filename it was given is absolute, and so fetches
the file from the remote as we'd like.
Andrew Burgess [Fri, 11 Oct 2024 20:28:47 +0000 (21:28 +0100)]
gdb/regformats: add osabi information to generated .dat files
Some gdbserver targets generate their target description based on the
gdb/regformats/*.dat files. These .dat files are generated from a
matching xml file in gdb/features/.
Lets consider a concrete example:
Take gdb/features/or1k-linux.xml, this file is processed by
gdb/features/Makefile to create gdb/regformats/or1k-linux.dat.
When gdbserver is built for the or1k target the file
or1k-linux-generated.cc is generated using the
gdb/regformats/regdat.sh script. This .cc file is then compiled and
linked into gdbserver.
The or1k-linux-generated.cc file contains the function
init_registers_or1k_linux which is called from within gdbserver, this
function creates a target_desc object and sets its xmltarget field to
a fixed string. This fixed string is the xml filename that was
originally used to generate the xml file, in this case or1k-linux.xml.
Additionally, as part of the gdbserver build the file or1k-linux.xml
is converted to a string and placed in the file
xml-builtin-generated.cc which is then built into gdbserver.
Now when GDB asks gdbserver for the target description, gdbserver
returns the fixed xmltarget string, which is the name of an xml file.
GDB will then ask gdbserver for that file and gdbserver will return
the contents of that file thanks to the xml-builtin-generated.cc
file's contents.
This is all rather complicated, but it does work. So what's the
problem that I'm fixing?
Well or1k-linux.xml does contain the osabi information, so this will
be returned from gdbserver to GDB. That's good.
However, the target_desc object created in init_registers_or1k_linux
will not have its osabi set correctly.
Now this doesn't really matter too much except
init_registers_or1k_linux includes a call to init_target_desc.
In the next commit I want to extend init_target_desc to require an
osabi to be passed in. The motivation for this will be explained in
the next commit, but if we accept for a moment that this is something
that should be done, then the question is what osabi should we use in
init_registers_or1k_linux?
Ideally we'd use the osabi which is set in or1k-linux.xml. If we do
that then everything will remain consistent, which is a good thing.
And so, to get the osabi from or1k-linux.xml into
init_registers_or1k_linux, we first need to get the osabi information
into or1k-linux.dat file, and this is what this commit does.
I've added a new xsl script print-osabi.xsl and updated
gdb/features/Makefile to make use of this script. Then I regenerated
all of the .dat files. Now every .dat file contains either:
osabi:GNU/Linux
osabi:unknown
The first is for xml files containing <osabi>GNU/Linux</osabi> and the
second is for xml files that don't contain an osabi element.
This commit doesn't attempt to make use of the osabi information in
the .dat files, that will come in the next commit. There should be no
user visible changes after this commit.
Andrew Burgess [Fri, 11 Oct 2024 13:53:25 +0000 (14:53 +0100)]
gdb/features: set osabi in all Linux related features/*.xml files
Some of the top level (i.e. those that contain the <target> element)
xml files in gdb/features/ are clearly Linux only. I conclude this
based on the files names containing the string "linux".
I think that all of these files should have the <osabi> element
included with the value "GNU/Linux".
This commits adds the <osabi> element where I believe it is
appropriate and regenerates the associated .c files.
The benefit of this change is that gdbserver, which makes use of these
files, will now send the osabi back in more cases. Sending back more
descriptive target descriptions is a good thing as this makes it
easier for GDB to select the correct gdbarch.
gdb/record: support AVX instructions VMOVDQ(U|A) when recording
In that commit I added a few calls to the instruction vmovdqa to and
from memory addresses. Because my local gcc testing always had aligned
pointers, I thought this would always work, but clang (and maybe other
compilers) might not do the same, which will cause vmovdqa to segfault,
and the test to fail spectacularly.
This commit fixes that by using the pre-existing precise-aligned-alloc
to allocate the dynamic buffers, forcing them to be aligned to the
required boundary for vmovdqa instruction to work. The code was then
re-shuffled to keep the current clustering of instructions.
Alan Modra [Wed, 30 Oct 2024 22:20:22 +0000 (08:50 +1030)]
Remove redundant section merge hash table field
sec_merge_hash.size duplicates sec_merge_hash.table.count, albeit using
bfd_size_type rather than unsigned int. The only reason to have the
duplicate field is to catch unsigned int overflows, and that can be
done easily enough when and if required. Overflow isn't possible at
the moment. See the needs_resize comment.
Alan Modra [Sun, 10 Nov 2024 23:54:09 +0000 (10:24 +1030)]
Re: tekhex object file output fixes
Commit 8b5a212495 supported *ABS* symbols by allowing "section" to be
bfd_abs_section, but bfd_abs_section needs to be treated specially.
In particular, bfd_get_next_section_by_name (.., bfd_abs_section_ptr)
is invalid.
PR 32347
* tekhex.c (first_phase): Guard against modification of
_bfd_std_section[] entries.
Shahab Vahedi [Fri, 25 Oct 2024 15:18:24 +0000 (17:18 +0200)]
Handle type-casting in template parameter list when hashing symbols
Due to a logical bug in gdb/cp-support.c:cp_search_name_hash(), GDB
may not be able to find a symbol when asked by the user. See the
accompanying test for such demonstration.
The cp_search_name_hash() cannot correctly handle a (demangled) symbol
that comprises of type-casting for the first parameter in its template
parameter list, e.g.:
foo<(enum_test)0>(int, int)
In this example, the processing logic in cp_search_name_hash() considers
the "foo<" string for hashing instead of "foo". This is due to a faulty
logic in the processing loop that tries to _keep_ hashing if a '<' char
with the following property is encountered:
Ostensibly, this logic strives to bail out of the processing loop as
soon as the beginning of an argument list is encountered, "(int, int)"
in the example, or the beginning of a template parameter list, the
"<(enum_test)0>" in the example. However, when "string" is pointing
at '<', the following incorrect logic takes precedence:
---------------------------------------------------------------------
for (const char *string = search_name; *string != '\0'; ++string)
{
if (*string == '(')
break;
...
if (string[0] == '<' && string[1] != '(' ...)
break;
In "foo<(enum_test)0>(int, int)", the '(' char that is positioned after
the '<' char causes the "if" condition at the end of the loop not to
"break". As a result, the '<' is considered for hashing and at the
beginning of the next iteration, the loop is exited because "string"
points to '(' char.
It's obvious that the intention of the "if" condition at the end of the
loop body is to handle cases where the method name is "operator<",
"operator<<", or "operator<=". While fixing the issue, I've re-written
the logic as such to make that more explicit. Still, the complexity of
the function remains O(n). It is worth mentioning that in the same
file the "find_toplevel_char()" follows the same explicit logic.
Reviewed-By: Lancelot SIX <lancelot.six@amd.com> Reviewed-By: Pedro Alves <pedro@palves.net> Approved-by: Tom Tromey <tom@tromey.com>
Change-Id: I64cbdbe79671e070cc5da465d1cce7989c58074e
Hannes Domani [Mon, 11 Nov 2024 16:13:28 +0000 (17:13 +0100)]
Fix using Page-Up in TUI source window close to the top
Currently, when you're already less than a page from the top in the TUI
source window, and you press Page-Up, nothing happens, while I would
expect that it then scrolls the source up to the first line.
It's happening because scrolling a full page up would result in a
negative starting line number, which is then checked if it's higher than
the (unsigned) number of available lines, and since this will always be
true, the original starting line number is restored.
Afterwards it would check if the line number is too low, but since the
negative value was already gone, it didn't do much.
Fixed by moving the low line number check before the maximum line number
check.
Andrew Burgess [Mon, 11 Nov 2024 10:51:46 +0000 (10:51 +0000)]
gdb/testsuite: fix failure in gdb.base/info_sources.exp
I ran into an unexpected failure in gdb.base/info_sources.exp. The
test in question runs this command:
(gdb) info sources -d -- -d
That is, list all the source files whose directory name matches the
regexp '-d'. The expectation is that no source files will be listed.
Unfortunately, when I ran the test some source files are listed; the
directory I am running in contains the pattern '-d', and so the test
fails.
As we cannot control where the developer is building and testing GDB,
I propose that instead of just testing with '-d' we should search
through all the letters a-z and find one that isn't present in the
source file directory name. I'm still including the leading '-'
character in the regexp.
So now, unless GDB is being built in a directory that contains '-a',
'-b', '-c', .... '-z', the test will find one letter which isn't
present, and use that for the test.
To avoid test names changing between runs in different directories
I've had to tweak the test name to something more generic, but there
should be no change in which parts of GDB are actually being tested.
Tom de Vries [Mon, 11 Nov 2024 14:57:38 +0000 (15:57 +0100)]
[gdb/testsuite] Avoid intermittent failures on another debuginfod test
With test-case gdb.debuginfod/solib-with-soname.exp on aarch64-linux, I ran
into:
...
(gdb) core-file solib-with-soname.core^M
Downloading 197.86 K file libfoo_1.so...^M
[New LWP 997314]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
Core was generated by `solib-with-soname'.^M
Program terminated with signal SIGABRT, Aborted.^M
(gdb) FAIL: $exp: load core file, use debuginfod: load core file
...
The test-case doesn't expect the "197.86 K" part.
The same problem was fixed for another test-case in commit a723c56efb0
("gdb/testsuite: avoid intermittent failures on a debuginfod test").
Tom Tromey [Wed, 23 Oct 2024 16:50:32 +0000 (10:50 -0600)]
Use an iterator range for 'using' directives
This patch changes block::get_using to return an iterator range. This
seemed cleaner to me than the current approach of returning a pointer
to the first using directive; all the callers actually use this to
iterate.
Tom Tromey [Mon, 3 Jun 2024 16:06:51 +0000 (10:06 -0600)]
Wrap help options when building help string
When building a help string, it's possible that the resulting options
will go over 80 columns. This patch changes this code to add line
wrapping where needed.
This can most be seen by looking "help bt" and in particular the
"-frame-info" help text.
Tom Tromey [Mon, 10 Jun 2024 16:05:46 +0000 (10:05 -0600)]
Shorten internal problem help text
The help text for various "internal problem" settings is longer than
80 columns. This patch tightens this up a bit. Note that these
commands are all "maint" commands so, IMO, it is sufficient if they
are clear to a gdb developer.
Tom Tromey [Fri, 7 Jun 2024 19:20:36 +0000 (13:20 -0600)]
Remove the "title" from the remote packet help
The help for remote packet controls includes the "title". However
this is is just the parameter name, and not really useful to see
repeated in the help text.
Tom Tromey [Fri, 7 Jun 2024 18:52:20 +0000 (12:52 -0600)]
Clean up opaque-type-resolution help
The opaque-type-resolution help says "if set before loading symbols",
but I don't think this is accurate. As far as I know, this resolution
can be done at any time.
This patch cleans up the help, also shortening it to less than 80
characters.
Tom Tromey [Mon, 3 Jun 2024 15:37:27 +0000 (09:37 -0600)]
Wrap help strings at 80 columns
This patch ensures that all ordinary help strings are wrapped at 80
columns. For the most part this consists of changing code like this
(note the embedded \n and the trailing backslash without a newline):
-Manage the space-separated list of debuginfod server URLs that GDB will query \
-when missing debuginfo, executables or source files.\nThe default value is \
-copied from the DEBUGINFOD_URLS environment variable."),
... to end each line with \n\, like:
+Manage the space-separated list of debuginfod server URLs that GDB will\n\
+query when missing debuginfo, executables or source files.\n\
+The default value is copied from the DEBUGINFOD_URLS environment variable."),
Tom Tromey [Fri, 31 May 2024 16:13:17 +0000 (10:13 -0600)]
Call gdbpy_fix_doc_string_indentation for function help
If you invoke "help function _caller_is", you'll see that the help
text is indented strangely. The fix for this is to add a call to
gdbpy_fix_doc_string_indentation in the appropriate spot, as is
already done for Python commands and parameters.
Tom Tromey [Fri, 1 Nov 2024 16:08:34 +0000 (10:08 -0600)]
Add setting to control frame language mismatch warning
A customer noted that there is no way to prevent the "current language
does not match this frame" warning. This patch adds a new setting to
allow this warning to be suppressed.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
H.J. Lu [Thu, 7 Nov 2024 04:39:19 +0000 (12:39 +0800)]
ld: Move note sections after .rodata section
Move note sections after .rodata section so that note sections are
placed in the same PT_LOAD segment together with .rodata section,
instead of a separate PT_LOAD segment.
PR ld/32341
* scripttempl/misc-sections.sc: Move note sections to ...
* scripttempl/elf.sc: Here, after .rodata section.
* testsuite/ld-elf/pr32341.d: New file.
* testsuite/ld-elf/pr32341.s: Likewise.
Co-Authored-By: Nick Clifton <nickc@redhat.com> Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Lancelot SIX [Tue, 5 Nov 2024 11:07:00 +0000 (11:07 +0000)]
gdb/dwarf2/read.c: Handle empty CU name
I recently came across a case where a compiler would emit a CU with an
empty name. In such case, the attribute object constructed by GDB will
return nullptr when as_string is called. One place is not checking for
this possibility. As a result, loading such binary results in a GDB
crash:
$ gdb -q a.out
Reading symbols from a.out...
Fatal signal: Segmentation fault
----- Backtrace -----
[...]
0x742f4dd8afab __strcmp_avx2
../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
0x58593704a0bc prepare_one_comp_unit
../../gdb/dwarf2/read.c:21842
0x585937053fd9 process_psymtab_comp_unit
../../gdb/dwarf2/read.c:4633
0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_
../../gdb/dwarf2/read.c:4943
[...]
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
This seems to be a regression introduced by the following commit:
Implement extension_language_ops::find_objfile_from_buildid within
GDB's Python API. Doing this allows users to write Python extensions
that can help locate missing objfiles when GDB opens a core file. A
handler might perform some project- or site-specific actions to find a
missing objfile. Or might provide some project- or site-specific
advice to the user on how they can obtain the missing objfile.
The implementation is very similar to the approach taken in:
gdb: implement missing debug handler hook for Python
The following new commands are added as commands implemented in
Python, this is similar to how the Python missing debug and unwinder
commands are implemented:
info missing-objfile-handlers
enable missing-objfile-handler LOCUS HANDLER
disable missing-objfile-handler LOCUS HANDLER
To make use of this extension hook a user will create missing objfile
handler objects, and registers these handlers with GDB. When GDB
opens a core file and encounters a missing objfile each handler is
called in turn until one is able to help. Here is a minimal handler
that does nothing useful:
import gdb
import gdb.missing_objfile
class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, pspace, build_id, filename):
# This handler does nothing useful.
return None
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing objfile, and GDB should ask any other
registered handlers.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the objfile couldn't
be found. GDB will not call any other handlers, and will
continue without the objfile.
- True: The handler has installed the objfile into a location where
GDB would normally expect to find it. GDB should repeat its
normal lookup process and the objfile should now be found.
- A string: The handler can return a filename, which is the missing
objfile. GDB will load this file.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the missing objfile, at which point GDB continues.
The implementation of this feature is mostly straight forward. I have
reworked some of the missing debug file related code so that it can be
shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is
mostly content moved from gdb/python/lib/gdb/missing_debug.py, but
updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py
and the new file gdb/python/lib/gdb/missing_objfile.py both call into
the missing_files.py file.
For gdb/python/lib/gdb/command/missing_files.py this is even more
extreme, gdb/python/lib/gdb/command/missing_debug.py is completely
gone now and gdb/python/lib/gdb/command/missing_files.py provides all
of the new commands in a generic way.
I have made one change to the existing Python API, I renamed the
attribute Progspace.missing_debug_handlers to
Progspace.missing_file_handlers. I don't see this as too
problematic. This attribute was only used to implement the missing
debug feature and was never documented beyond the fact that it
existed. There was no reason for users to be touching this attribute.
Add a new ext_lang_find_objfile_from_buildid function which is called
from find_objfile_by_build_id and gives extension languages a chance
to find missing objfiles.
This commit adds the ext_lang_find_objfile_from_buildid function and
the extension_language_ops::find_objfile_from_buildid() hook, but does
not implement the hook for any extension languages, that will come in
the next commit.
This commit does rewrite find_objfile_by_build_id (build-id.c) to call
the new hook though. The basic steps of find_objfile_by_build_id are
now this:
1. Try to find the missing objfile using the build-id by looking in
the debug-file-directory's .build-id/ sub-directory. If we find the
file then we're done.
2. Ask debuginfod to download the missing file for us. If we
download the file successfully then we're done.
3. Ask the extension language hook to find the file for us. If the
extension language asks us to try again then we repeat step (1) only
and if we still don't have the file, we move to step (4). If the
extension language told us where the file is then we use that file
and we're done.
4. We didn't find the file. Carry on without it.
Only step (3) is new in this logic, everything else was already done.
There are no tests added here as we can't currently write an extension
language callback. The next commit will add the tests.
Andrew Burgess [Wed, 31 Jul 2024 14:50:50 +0000 (15:50 +0100)]
gdb: use mapped file information to improve debuginfod text
When opening a core-file GDB is able to use debuginfod to download the
executable that matches the core-file if GDB can find a build-id for
the executable in the core-file.
In this case GDB calls debuginfod_exec_query to download the
executable and GDB prints a message like:
Downloading executable for /path/to/core-file...
which makes sense in that case.
For a long time GDB has also had the ability to download memory-mapped
files and shared libraries when opening a core-file. However, recent
commits have made these cases more likely to trigger, which is a good
thing, but the messaging from GDB in these cases is not ideal. When
downloading a memory-mapped file GDB prints:
Downloading executable for /path/to/memory-mapped-file
And for a shared library:
Downloading executable for /path/to/libfoo.so
These last two messages could, I think, be improved.
I propose making two changes. First, I suggest instead of using
/path/to/core-file in the first case, we use the name of the
executable that GDB is fetching. This makes the messaging consistent
in that we print the name of the file we're fetching rather than the
name of the file we're fetching something for.
I further propose that we replace 'executable for' with the more
generic word 'file'. The messages will then become:
I think these messages are clearer than what we used to have, and they
are consistent in that we name the thing being downloaded in all
cases.
There is one tiny problem. The first case relies on GDB knowing the
name of the executable it wants to download. The only place we can
currently get that from is, I think, the memory-mapped file list.
[ ASIDE: There is `bfd_core_file_failing_command` which reports the
executable and argument list from the core file, but this
information is not ideal for this task. First, the executable and
arguments are merged into a single string, and second, the string is
a relatively short, fixed length string, so the executable name is
often truncated. For these reasons I don't consider fetching the
executable name using this bfd function as a solution. ]
We do have to consider the case that the core file does not have any
mapped file information. This shouldn't ever be the case for a Linux
target, but it's worth considering.
[ ASIDE: I mention Linux specifically because this only becomes a
problem if we try to do a lookup via debuginfod, which requires that
we have build-ids available. Linux has special support for
embedding build-ids into the core file, but I'm not sure if other
kernels do this. ]
For the unlikely edge case of a core-file that has build-ids, but
doesn't have any mapped file information then I propose that we
synthesis a filename like: 'with build-id xxxxxx'. We would then see
a message like:
Downloading file with build-id xxxxxx...
Where 'xxxxxx' would be replaced by the actual build-id.
This isn't ideal, but I think is good enough, and, as I said, I think
this case is not going to be hit very often, or maybe at all.
We already had some tests that emitted two of the above messages,
which I've updated, these cover the mapped-file and shared library
case.
The message about downloading the exec for the core-file is actually
really hard to trigger now as usually the exec will also appear in the
memory-mapped file list and GDB will download the file at this stage.
Then when GDB needs the executable for loading the symbols it'll ask
debuginfod, and debuginfod will find the file in its cache, and so no
message will be printed.
If anyone has any ideas about how to trigger this case then I'm happy
to add additional tests.
This test checks that GDB is able to load DWARF information when
.debug_aranges has a section address size that is set to 0.
This test was originally written by Jan Kratochvil to test commit 927aa2e778d from 2017, titled "DWARF-5: .debug_names index consumer".
This test was originally written using a static .S file and has
been present in the Fedora tree for a long time.
If dwarf2/aranges.c is modified to turn off the address_size check,
GDB will crash with SIGFPE when loading the executable with address
size set to zero.
I modified the DWARF assembler to make it possible to set the address
size to zero in a .debug_aranges section and used the DWARF assembler
to produce the assembly file.
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Wed, 6 Nov 2024 18:39:48 +0000 (13:39 -0500)]
gdbserver: remove for_each_thread(pid, func)
Remove this overload, prefer to use `process_info::for_each_thread`. In
many instances, the `process_info` is already available, so this saves a
map lookup. In other instances, add the `process_info` lookup at the
call site.
In `linux-arm-low.cc` and `win32-i386-low.cc`, use `current_process ()`
instead of `current_thread->id.pid ()`. I presume that if
`current_process ()` and `current_thread` don't match, it's a bug
orthogonal to this change.
Change-Id: I751ed497cb1f313cf937b35125151bee9316fc51 Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
gdb: make the error message for unreadable objfiles more informative
When GDB is unable to read an objfile, it prints the error message "I'm
sorry Dave, I can't do that. Symbol format `%s' unknown.". While it is a
great reference, an end user won't have much information about the
problem.
So far this wasn't much of a problem, as it is very uncommon for GDB to
be unable to read an objfile. However, a future patch will allow users
to selectively disable support to some formats, making it somewhat
expected that the message will be seen by end users.
This commit makes the end message more informative and direct.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13299 Approved-By: Tom Tromey <tom@tromey.com>
Matthieu Longo [Fri, 7 Jun 2024 15:59:58 +0000 (16:59 +0100)]
aarch64: add flag OPD_F_UNSIGNED to distinguish signedness of immediate operands
This patch introduces a new operand flag OPD_F_UNSIGNED to signal that
the immediate value should be treated as an unsigned value. The default
signedness of immediate operands is signed.
Matthieu Longo [Fri, 7 Jun 2024 15:59:57 +0000 (16:59 +0100)]
aarch64: improve debuggability on array of enum
The current space optmization on enum aarch64_opn_qualifier forced its
encoding using an unsigned char. This "hard-coded" optimization has the
bad consequence of making the array of such enums being completely
unreadable when debugging with GDB because the enum type is lost along
the way.
Keeping this space optimization, and the enum type as well, is possible
when the declaration of the enum is tagged with attribute((packed)).
attribute((packed)) is a GNU extension, and is wrapped in the macro
ATTRIBUTE_PACKED (defined in ansidecl.h), and should be used instead.
Matthieu Longo [Fri, 7 Jun 2024 15:59:57 +0000 (16:59 +0100)]
aarch64: make comment clearer about the location
The enum aarch64_opnd_qualifiers in include/opcode/aarch64.h needs to
stay in sync with the array of struct operand_qualifier_data which
defines various properties for the different type of operands. For
instance, for:
- registers: the size of the register, the number of elements.
- immediates: lower and upper bits to determine the range of values.
the new gdb.base/basic-edit-cmd.exp was added. The Linaro CI
highlighted an issue with the test which I failed to address before
pushing the above commit.
Part of the test loads a file into GDB and then uses the 'edit'
command with no arguments to edit the default location. This default
location is expected to be the 'main' function.
On my local machine the line reported is the opening '{' of main, and
that is what the test checks for.
The Linaro CI though appears to see the first code line of main.
I think either result is fine as far as this test is concerned, so
I've expanded the test regexp to check for either line number. This
should make the CI testing happy again.
When reviewing that patch, the first thing I wanted to do was add some
tests for the 'edit' command because, as far as I can tell, there are
no real tests right now.
The approach I've taken for testing is to override the EDITOR
environment variable, setting this to just 'echo'. Now when the
'edit' command is run, instead of entering an interactive editor, the
shell instead echos back the arguments that GDB is trying to pass to
the editor. The output might look like this:
We can then test this like any other normal command. I then wrote
some basic tests covering a few situations like, using 'edit' before
the inferior is started. Using 'edit' without any arguments, and
using 'edit' with a line number argument.
There are plenty of cases that are still not tested, for example, the
test program only has a single source file for example. But we can
always add more tests later.
I then used these tests to validate the fix proposed in the above
patch.
The patch above does indeed fix some cases, specifically, when GDB
stops at a location (e.g. a breakpoint location) and then the 'edit'
command without any arguments is fixed. But using the 'list' command
to show some other location, and then 'edit' to edit the just listed
location broken before and after the above patch.
I am instead proposing this alternative patch which I think fixes more
cases. When GDB stops at a location then 'edit' with no arguments
should correctly edit the current line. And using 'list XX' to list a
specific location, followed by 'edit' should also now edit the just
listed location.
Mark Wielaard [Thu, 7 Nov 2024 17:40:03 +0000 (18:40 +0100)]
bfd: Remove unused static find function from doc/chew.c
After commit 2e60790cf7c27d79f90f2dcb81e1930dc980bc1c "Remove the
paramstuff word" there is no caller left of the static find function
in doc/chew.c, so it should be removed.
Andre Vieira [Fri, 8 Nov 2024 10:06:26 +0000 (10:06 +0000)]
arm, objdump: Make objdump use bfd's machine detection to drive disassembly
For any arm elf target, disable an old piece of code that forced disassembly to
disassemble for 'unknown architecture' which once upon a time meant it would
disassemble ANY arm instruction. This is no longer true with the addition of
Armv8.1-M Mainline, as there are conflicting encodings for different thumb
instructions.
BFD however can detect what architecture the object file was assembled for
using information in the notes section. So if available, we use that,
otherwise we default to the old 'unknown' behaviour.
With the changes above code, a mode changing 'bx lr' assembled for armv4 with
the option --fix-v4bx will result in an object file that is recognized by bfd
as one for the armv4 architecture. The disassembler now disassembles this
encoding as a BX even for Armv4 architectures, but warns the user when
disassembling for Armv4 that this instruction is only valid from Armv4T
onwards.
Remove the unused and wrongfully defined ARM_ARCH_V8A_CRC, and
define and use a ARM_ARCH_V8R_CRC to make sure instructions enabled by
-march=armv8-r+crc are disassembled correctly.
Patch up some of the tests cases, see a brief explanation for each below.
inst.d:
This test checks the assembly & disassembly of basic instructions in armv3m. I
changed the expected behaviour for teqp, cmnp cmpp and testp instructions to
properly print p when disassembling, whereas before, in the 'unknown' case it
would disassemble these as UNPREDICTABLE as they were changed in later
architectures.
nops.d:
Was missing an -march, added one to make sure we were testing the right
behavior of NOP<c> instructions.
unpredictable.d:
Was missing an -march, added armv6 as that reproduced the behaviour being
tested.
Nick Clifton [Thu, 7 Nov 2024 14:53:26 +0000 (14:53 +0000)]
Deprecate the ARM simulator.
The ARM simulator is no longer able to simulator modern ARM cores, so it
is being deprecated. Once this change has been active for a while - and
assuming that no problems have been found - the ARm simulator codebase
will be removed.
Stephan Rohr [Tue, 22 Oct 2024 14:01:19 +0000 (07:01 -0700)]
gdbserver: add process specific thread list and map
Replace the servers global thread list with a process specific thread
list and a ptid -> thread map similar to 'inferior::ptid_thread_map' on
GDB side. Optimize the 'find_thread' and 'find_thread_ptid' functions
to use std::unordered_map::find for faster lookup of threads without
iterating over all processes and threads, if applicable. This becomes
important when debugging applications with a large thread count, e.g.,
in the context of GPU debugging.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Peter Bergner [Wed, 6 Nov 2024 19:37:10 +0000 (13:37 -0600)]
PowerPC: Merge rfc2655 and rfc2656 test cases into one future test case
gas/
* testsuite/gas/ppc/rfc02655.[ds]: Rename from this...
* testsuite/gas/ppc/future.[ds]: ... to this.
* testsuite/gas/ppc/rfc02656.[ds]: Delete. Move tests to future.[ds].
* testsuite/gas/ppc/ppc.exp: Update for file name changes.
The last parameter is bool* that when set will receive information
if the match was exact. This parameter is never used by any callsite
and can therefore be removed.
This will become:
symtab *find_line_symtab (symtab *sym_tab, int line, int *index);
projects / thirdparty / binutils-gdb.git / log
