| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The DWARF assembler treats the 'children' of a DIE as plain Tcl code,
evaluating it in the parent context.
I don't recall why, but when I wrote this code, I didn't do the same
thing for the attributes. Instead, there I implemented a special
syntax. I was looking at this today and wondered why I didn't just
use ordinary evaluation as well.
This patch implements this idea. Attributes are now evaluated as
plain code. This is a bit less "magical", is slightly shorter due to
lack of braces, and most importantly now allows comments in the
attributes section.
Note that some [subst {}] calls had to be added. This could be fixed
by changing DWARF expressions to also be plain Tcl code. I think that
would be a good idea, but I didn't want to tack it on here.
This patch requires the full ("DW_AT_...") name for attributes. I did
this to avoid any possibility of name clashes. I've long considered
that my original decision to allow short names for tags and attributes
was a mistake. It's worth noting that many existing tests already
used the long names here.
Most of this patch was written by script. The main changes are in
dwarf.exp, but as noted, there were some minor fixups needed in some
tests.
Also, after committing, 'git show' indicated some whitespace issues,
so I've gone through and "tabified" some things, which is why the
patch might be otherwise larger than it should be. (This was
discussed a bit during the v1 submission.)
v1 was here:
https://inbox.sourceware.org/gdb-patches/20250530183845.2179955-1-tromey@adacore.com/
In v2 I've rebased and fixed up various tests that either changed or
were added since v1.
Regression tested on x86-64 Fedora 41.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This patch removes a lot of uses of the Tcl "eval" proc from the gdb
test suite. In most cases the {*} "splat" expansion is used instead.
A few uses of eval remain, primarily ones that were more complicated
to untangle.
In a couple of tests I also replaced some ad hoc code with
string_to_regexp.
Tested on x86-64 Fedora 40.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.reverse.
Tested on:
- x86_64-linux, target boards unix and unix/-m32
- aarch64-linux
- ppc64le-linux
- s390x-linux
|
|
Running the standalone test `gdb.reverse` with the target board configuration `unix/-fPIE/-pie` leads to the following failure:
'''
FAIL: gdb.reverse/i386-avx-reverse.exp: verify ymm15 before vbroadcastsd
'''
This happens because the test expects values stored in `dyn_buf0`, but instead (in the test source) the address of the buffer itself
got broadcast to xmm15 (and thus to ymm15).
This happened because the pointer to the start of `dyn_buf0` wasn't dereferenced (see 'vpbroadcast_test' in 'i386-avx-reverse.c'):
'''
asm volatile ("vbroadcastss %0, %%xmm15": : "m" (dyn_buf0));
^
'''
and this consequently lead to the test failing for the next instruction (`vbroadcastsd`), which depended on the correct value being broadcast to the register.
Also, updated the corresponding expected output (gdb.reverse/i386-avx-reverse.exp) to match.
Tested on x86-64 Linux.
Signed-off-by: Shiven Kashyap <shivenkashyap24@gmail.com>
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit adds support for a few more vmov instructions:
* VMOV[LH|HL]PS
* VMOVLPD
* VMOVHP[S|D]
* VMOVDDUP
And associated tests. The testsuite had some minor re-working, adding a
function to zero buffers, to make later tests less fragile.
|
|
WIP
This commit adds support for instructions to convert from one type to
another, which are in the form:
* VCVTDQ2[PS|PD]
* VCVTPS2[DQ|PD]
* VCVTPD2[PS|DQ]
* VCVTSD2[SI|SS]
* VCVTSI2[SS|SD]
* VCVTSS2[SD|SI]
* VCVTTP[S|D]2DQ
* VCVTTS[S|D]2SI
It also adds support to vpsadbw, since it was trivial and only one
instruction. Finally, I have slightly reorder the case statements to
keep them in numerical order.
|
|
This commit adds support for the following instructions VPACK[S|U]S[WB|DW] and associated tests.
|
|
This commit adds support for the following instructions:
* VCOMIS[S|D]
* VUCOMIS[S|D]
And associanted tests.
|
|
This commit supports for the following instructions:
* VBLENDP[S|D]
* VBLENDVP[S|D]
* VPBLEND[D|W|VB]
and test them.
|
|
This patch adds support for the following instructions:
* VEXTRACT[F128|I128|PS]
* VINSERT[F128|I128|PS]
* VPEXTR[B|W|D|Q]
And associated test. For some reason, it seems that the extract
instructions deal with the output register as though it was the first
source register, so they use ModRM.r/m and VEX.B, instead of the usual
ModRM.reg and VEX.R. This meant that the opcode collision with
vbroadcastsd wasn't trivial. It can be easily solved by checking the
VEX.map_select field, so soslving it was very easy.
The VPEXTR instructions had several complicated collisions, and notably,
vpextrw to a register works completely different to any other
instruction in the family, so the code is messy, but it should be
correct.
|
|
This commit adds support for 3 instructions:
* VBROADCASTSS
* VBROADCASTSD
* VBROADCASTF128
and extends the function vpbroadcast_test to include these.
|
|
This commit adds recording support for the following instructions:
* VPERM2[I|F]128
* VPERM[D|Q|PD|PS]
* VPERMILP[S|D]
And associated tests.
|
|
This commit adds support for the following instructions:
* VPSHUF[B|D|HW|LW]
* VSHUFP[S|D]
and the associated test.
|
|
This commit adds record-full support to the following instructions:
* VPSLL[W|D|Q|DQ]
* VPSRL[W|D|Q|DQ]
* VPSRA[W|D]
With both dynamic and constant shifts, and the associated tests.
Notably, vpsraq is not available for AVX or AVX2 instruction sets, only
AVX512. vpsradq does not seem to be available with any instruction set.
|
|
This commit adds support to the following AVX/AVX2 instructions:
* VPADD[B|W|D|Q]
* VPMUL[LW|LD|HW|HUW|UDQ]
* VXORP[S|D]
* VPAND[|N]
This required some reworking on the loop that processes instruction
prefixes, because the opcode for VPMULLD overlapped with a valid
instruction prefix. To fix that, rather than using "goto out_prefixes",
this commit changes the infinite loop to only run while we don't find
another VEX prefix. That should be OK, as the intel manual (page 526 on
the March 2024 edition) says that the VEX prefix is always the last one.
|
|
add support to recording 2 missing AVX instructions: vaddsubps and vaddsubpd, and add associated tests.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Make gdb.reverse codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
After building gdb with "-O0 -g -fsanitize=thread" on aarch64-linux, with
test-case gdb.reverse/time-reverse.exp I run into:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: mode=c: continue to breakpoint: marker2 (timeout)
...
The problem is that instruction stepping gets stuck in a loop with this call
stack: time -> __GI___clock_gettime -> __kernel_clock_gettime ->
__cvdso_clock_gettime.
This is not specific to fsanitize=thread, it just makes gdb slow, which makes
instruction stepping slow, which results in the application getting stuck.
I ran into this as well with a regular gdb build on a 32-bit i686 laptop with
1GB of memory, an inherently slow setup. In that instance, I was able to
observe that the loop we're stuck in is the outer loop in do_coarse in linux
kernel source lib/vdso/gettimeofday.c.
Fix this by setting "record full insn-number-max" to 2000, and handling
running into the limit.
Initially I tried the approach of using "stepi 2000" instead of continue, but
that made the issue more likely to show up (for instance, I observed it after
building gdb with -O0 on aarch64-linux).
Tested on aarch64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
PR testsuite/32678
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32678
|
|
I noticed that test-case gdb.reverse/time-reverse.exp contains:
...
if [supports_process_record] {
# Activate process record/replay
gdb_test_no_output "record" "turn on process record"
...
So I tried out forcing supports_process_record to 0, and got:
...
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: info record
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: reverse to marker1
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: check time record
FAIL: gdb.reverse/time-reverse.exp: mode=c: info record
FAIL: gdb.reverse/time-reverse.exp: mode=c: reverse to marker1
FAIL: gdb.reverse/time-reverse.exp: mode=c: check time record
...
Fix this by requiring supports_process_record alongside supports_reverse.
I also noticed when running make-check-all.sh that there were a lot of failures
with target board dwarf5-fission-debug-types.
Fix this by not ignoring the result of "runto marker1".
Then I noticed that $srcfile is used as a regexp. Fix this by applying
string_to_regexp.
Tested on x86_64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
While stepping through gdb.reverse/time-reverse.exp I realized that we're
recording the instructions for resolving the PLT entries for functions time
and syscall, while that's not really the focus of the test-case.
Limit the scope of the test, by calling the functions once before starting
to record.
Also call "info record" after recording to make it clear how many
instructions were recorded.
On x86_64-linux, before this patch (but with info record added), we have:
...
$ grep "Log contains" gdb.log
Log contains 750 instructions.
Log contains 1218 instructions.
...
and with this patch we have:
...
$ grep "Log contains" gdb.log
Log contains 24 instructions.
Log contains 19 instructions.
...
Tested on x86_64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were
failing. In my machine xmm3 was consistently set to 0x54, but apparently
that is different depending on the system. This commit zeroes out xmm3
at the start of the test instead.
While debugging the test failures, I also noticed an issue where the
recording wasn't saving all the required memory. That happened because
vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to
share code paths, but the latter encodes memory modification size on
VEX.L whereas the former encodes in VEX.pp. So this commit fixed that,
and made the relevant tests more robust and complete.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
The test gdb.reverse/i386-avx-reverse.exp requires CPU to have AVX
instructions but it actually also uses AVX2 instructions (like
vpcmpeqd). This caused the test to fail on CPUs that have AVX but not
AVX2.
This commit adds check for AVX2.
Tested on Intel Xeon CPU E3-1265L (no AVX2) and Intel Core i7-1355U
(has AVX2).
|
|
This commit adds support for the following types of instructions
relating to floating poitn values: add, mul, sub, min, div, max.
These are supported with packed or single values, and single or double
precision.
Some of the instructions had opcode clashes, however, considering the
mechanics of recording the registers is the same on both instructions,
this is just marked with a comment.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit adds support for the AVX instructions vunpck[l|h][ps|pd]
instructions, which was pretty straightforward.
This commit also fixes a mistake in the test, where "record stop" was
used after the recording was already stopped, if it failed during
vpunpck_test recording. It also improved the documentation at the start
of the relevant .c function.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit updates GDB's record-full to be able to record vmov[ss|sd]
and vmov [u|a] [ps|pd] AVX instructions, and tests for them.
Unlike the vmovdq[u|a] instructions, the aligned and unalgined versions
of vmov?[ps|pd] have different opcodes. The mechanics of recording them
is the same, but the aligned version has opcodes 0x28 and 0x29, while
the unaligned has the same opcode as vmov[ss|sd] instruction, 0x10 and
0x11.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
gdb.reverse/test_ioctl_TCSETSW.exp
I ran test-case gdb.reverse/test_ioctl_TCSETSW.exp on riscv64-linux, and got:
...
(gdb) record full^M
Process record: the current architecture doesn't support record function.^M
(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: record full
...
Fix this by requiring supports_process_record.
Tested on riscv64-linux and x86_64-linux.
|
|
The test gdb.reverse/i386-avx-reverse.exp was assuming that if the CPU
was like x86, it would have AVX instructions because I didn't know how
to check for AVX instruction support explicitly. This commit updates
that to use the pre-existing TCL proc have_avx.
Also update the comment at the top of the test, since it was a copy of a
different test.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This commit adds recording support for the AVX instruction vpor, and the
AVX2 extension. Since the encoding of vpor and vpxor are the same, and
their semantics are basically the same, modulo the mathematical
operation, they are handled by the same switch case block.
This also updates the vpxor function, to test vpor and vpxor, and
updates the name to vpor_xor_test to better reflect what it does.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds support for recording the AVX instruction vpmovmskb,
and tests to the relevant file. The test didn't really support checking
general purpose registers, so this commit also adds a proc to
gdb.reverse/i386-avx-reverse.exp, which can be used to test them
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds support to recording instructions of the form
VPCMPEQ[B|W|D]. They are all encoded in the same way and only
differentiated by the opcode, so they are all processed together. This
commit also updates the test to (quite exhaustively) test the new
instruction.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds support for recording the instruction vpxor,
introduced in the AVX extension, and extended in AVX2 to use 256 bit
registers. The test gdb.reverse/i386-avx-reverse.exp has been extended
to test this instruction as well.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Currently, text adjacent to parentheses is not spell-checked:
...
$ cat tmp.txt
(upto)
$ ./gdb/contrib/spellcheck.sh tmp.txt
$
...
Add handling of parentheses, such that we get:
...
$ ./gdb/contrib/spellcheck.sh tmp.txt
upto -> up to
$
...
Rerun spellcheck.sh, resulting in a few "thru->through" replacements.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
The test gdb.reverse/i386-avx-reverse.exp was changed by the recent
commit:
commit 5bf288d5a88ab6d3fa9bd7bd070e624afd264dc6
Author: Guinevere Larsen <guinevere@redhat.com>
Date: Fri Jul 26 17:31:14 2024 -0300
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds recording support for the AVX instruction vzeroupper,
which zeroes the high bits of ymm registers 0..15. In the programmer's
manual, it is explicitly states that ymm registers 16..31 won't be
affected if present, so we only need to record the first 16 registers.
We record ymm_h registers since only the higher bits are touched, and
that reduces the memory footprint of the instruction.
This instruction is tested differently as we want to confirm we're only
saving the relevant registers, and we want to ensure we're saving
all of them, so it makes use of "maint print record-instruction" to see
exactly what was recorded.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds support for the instructions VMOVDQU and VMOVDQA, used
to move values to/from 256 bit registers. Unfortunately, the
programmer's manual is very incomplete (if not wrong) about these
instructions, so the logic had to be reverse engineered from how gcc
actually encodes the instruction.
This commit also changes the memory regions from the test to store 256
bits, so its easier to test the instructions and that we're recording
ymm registers correctly.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds recording support to all AVX and AVX2 instructions
of the form vpbroadcast. GDB is not yet concerned about AVX512 in
recording mode, so for now we only support the AVX2 registers and
instructions.
This commit also updates the gdb.reverse/i386-avx-reverse.exp to test
broadcast instructions.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds support to recording instructions to unpack high
or low data from XMM registers, identified by the mnemonics in the
form: VPUNPCK [L|H] [BW|WD|DQ|QDQ].
All these instructions are encoded the exact same way, and only affect
the destination register, making them trivial to implement together.
It also updates the test gdb.reverse/i386-avx-reverse.exp to test these
new instructions. The test always uses ymm because the vpunpck
instructions overwrite the high bits, so we have to be able to record
the full ymm register, not just the output size.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit adds support to the x86_64 AVX instructions vmovd and vmovq.
The programmers manuals for Intel and AMD describe these 2 instructions
as being almost the same, but my local testing, using gcc 13.2 on Fedora
39, showed several differences and inconsistencies.
The instruction is supposed to always use the 3-byte VEX prefix, but I
could only find 2-byte versions. The instructions aren't differentiated
by the VEX.w bit, but by opcodes and VEX.pp.
This patch adds a test with many different uses for both vmovd and
vmovq. It also updates the test gdb.reverse/step-precsave.exp to
reference the generic "missing avx support" bug open in the bug tracker
(17346), instead of pointing to one that specifically calls out to
vmovd instructions.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch introduces the information needed to properly identify the
VEX prefix, used to signal an AVX and AVX2 instruction, and introduces
a helper function to handle all AVX instruction, instead of adding to
the 3000 line long recording function.
This new function will temporarily set the current thread as "not
executing" so that it can read from pseudo registers as we record, since
most AVX/AVX2 instructions would benefit from recording ymm registers.
The new helper also handles unsupported instructions so that the largest
part of the i386_process_record doesn't have to be shifted by 2 spaces,
which made an unreadably big patch file.
The only expected difference to the end user added by this patch is a
small change to the unsupported message. This patch also updates the
test gdb.reverse/step-precsave.exp, by recognizing the new output.
As a note for the future, we don't handle xmm16-31 and ymm16-31 because
those require the EVEX prefix, meaning avx512 support.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using gdb_test_lines, as well as related gdb_get_lines.
Tested on x86_64-linux.
|
|
Fix the following common misspellings:
...
accidently -> accidentally
additonal -> additional
addresing -> addressing
adress -> address
agaisnt -> against
albiet -> albeit
arbitary -> arbitrary
artifical -> artificial
auxillary -> auxiliary
auxilliary -> auxiliary
bcak -> back
begining -> beginning
cannonical -> canonical
compatiblity -> compatibility
completetion -> completion
diferent -> different
emited -> emitted
emiting -> emitting
emmitted -> emitted
everytime -> every time
excercise -> exercise
existance -> existence
fucntion -> function
funtion -> function
guarentee -> guarantee
htis -> this
immediatly -> immediately
layed -> laid
noone -> no one
occurances -> occurrences
occured -> occurred
originaly -> originally
preceeded -> preceded
preceeds -> precedes
propogate -> propagate
publically -> publicly
refering -> referring
substract -> subtract
substracting -> subtracting
substraction -> subtraction
taht -> that
targetting -> targeting
teh -> the
thier -> their
thru -> through
transfered -> transferred
transfering -> transferring
upto -> up to
vincinity -> vicinity
whcih -> which
whereever -> wherever
wierd -> weird
withing -> within
writen -> written
wtih -> with
doesnt -> doesn't
...
Tested on x86_64-linux.
|
|
Fix a few typos.
unconditionaly -> unconditionally
gratuitiously -> gratuitously
configureable -> configurable
represention -> representation
distiguished -> distinguished
breakpointer -> breakpoint
asssignments -> assignments
architectual -> architectural
compatibity -> compatibility
adjustement -> adjustment
unexcepted -> unexpected
propogated -> propagated
consistant -> consistent
succeding -> succeeding
higlight -> highlight
detachs -> detach
Tested by rebuilding on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
In a record session, when we move backward, GDB switches from normal
execution to simulation. Moving forward again, the emulation continues
until the end of the reverse history. When the end is reached, the
execution stops, and a warning message is shown. This message has been
modified to indicate that the forward emulation has reached the end, but
the execution can continue as normal, and the recording will also continue.
Before this patch, the warning message shown in that case was the same as
in the reverse case. This meant that when the end of history was reached in
either backward or forward emulation, the same message was displayed:
"No more reverse-execution history."
This message has changed for these two cases. Backward emulation:
"Reached end of recorded history; stopping.
Backward execution from here not possible."
Forward emulation:
"Reached end of recorded history; stopping.
Following forward execution will be added to history."
The reason for this change is that the initial message was deceiving, for
the forward case, making the user believe that forward debugging could not
continue.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31224
Reviewed-By: Markus T. Metzger <markus.t.metzger@intel.com> (btrace)
Approved-By: Guinevere Larsen <blarsen@redhat.com>
|
|
Currently you get this assertion failure if you try to execute the
inferior after loading a saved recording, when no recording was done
earlier in the same gdb session:
```
$ gdb -q c -ex "record restore test.rec"
Reading symbols from c...
[New LWP 26428]
Core was generated by `/tmp/c'.
Restored records from core file /tmp/test.rec.
(gdb) c
Continuing.
../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
```
The change in step-precsave.exp triggers this bug, since now the
recording is loaded in a new gdb session, where
record_full_resume_ptid was never set.
The fix is to simply set record_full_resume_ptid when resuming a loaded
recording.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31971
Approved-By: Guinevere Larsen <blarsen@redhat.com>
|
|
There are two kinds of MOPS instructions: set instructions and copy
instructions. Within each group there are variants with minor
differences in how they read or write to memory — e.g., non-temporal
read and/or write, unprivileged read and/or write and permutations of
those — but they work in the same way in terms of the registers and
regions of memory that they modify.
The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS
instructions are recorded and correctly reversed. Not all variants of the
copy and set instructions are tested, since there are many and the record
and replay target processes them in the same way.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
This is similar to the previous patch, but for gdb_protocol_is_remote.
gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint
print target-stack", which is unnecessary when checking whether
gdb_protocol is "remote" or "extended-remote" would do. Checking
gdb_protocol is more efficient, and can be done before starting GDB
and running to main, unlike gdb_is_target_remote/mi_is_target_remote.
This adds a new gdb_protocol_is_remote procedure, and uses it in place
of gdb_is_target_remote/mi_is_target_remote throughout.
There are no uses of gdb_is_target_remote/mi_is_target_remote left
after this. Those will be eliminated in a following patch.
In some spots, we no longer need to defer the check until after
starting GDB, so the patch adjusts accordingly.
Change-Id: I90267c132f942f63426f46dbca0b77dbfdf9d2ef
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main:
...
00000000004102c4 <end_of_sequence>:
4102c4: 52800000 mov w0, #0x0 // #0
4102c8: 9100c3ff add sp, sp, #0x30
4102cc: d65f03c0 ret
...
is not described by the line table:
...
File name Line number Starting address View Stmt
...
map-to-same-line.c 54 0x4102ac x
map-to-same-line.c - 0x4102c4
...
Fix this by ending the line table at $main_end.
Likewise in a few other test-cases, found using:
...
$ find gdb/testsuite/ -type f \
| xargs grep -B1 DW_LNE_end_sequence \
| grep set_address \
| egrep -v "_end|_len"
...
Tested on aarch64-linux.
|
|
The output of "info breakpoints" includes breakpoint, watchpoint,
tracepoint, and catchpoint if they are created, so it should show
all the four types are deleted in the output of "info breakpoints"
to report empty list after "delete breakpoints".
It should also change the output of "delete breakpoints" to make it
clear that watchpoints, tracepoints, and catchpoints are also being
deleted. This is suggested by Guinevere Larsen, thank you.
$ make check-gdb TESTS="gdb.base/access-mem-running.exp"
$ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running
[...]
(gdb) break main
Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32.
(gdb) watch global_counter
Hardware watchpoint 2: global_counter
(gdb) trace maybe_stop_here
Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27.
(gdb) catch fork
Catchpoint 4 (fork)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32
2 hw watchpoint keep y global_counter
3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27
not installed on target
4 catchpoint keep y fork
Without this patch:
(gdb) delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) info breakpoints 3
No breakpoint or watchpoint matching '3'.
With this patch:
(gdb) delete breakpoints
Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y
(gdb) info breakpoints
No breakpoints, watchpoints, tracepoints, or catchpoints.
(gdb) info breakpoints 3
No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Approved-by: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
I noticed in gdb.reverse/map-to-same-line.{c,exp} that the license urls are
using some kind of indirection via urldefense.proofpoint.com.
Fix this by removing this indirection.
Tested on x86_64-linux.
PR testsuite/31358
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31358
|
