| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This changes 'require' to accept a list of simple predicates. For
now, each predicate is just the name of a proc, optionally prefixed
with "!" to indicate that the result should be inverted.
It's possible to make this fancier, but so far I haven't done so. One
idea I had is to allow a predicate to have associated text to display
on failure. Another is to convert the predicates that need a running
gdb (e.g., skip_python_tests) to start their own gdb, and then
'require' could enforce the rule that gdb not be running when it is
called.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
DWARF 5
To support DWARF 5 in the DWARF assembler line tables, we currently copy
the first user-provided directory and the first user-provided files and
make them elements at indices 0 in the directory and file name tables.
That was a sufficient behavior at the time (see commit 44fda089397a
("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in
the following patches, I would need to have finer grained control on
what is generated exactly. For example, I'd like to generate a DWARF 5 line
table with just a single file and a single directory.
Get rid of this behavior, and implement what is suggested in
44fda089397a: make include_dir return the directory index that can be
used to refer to that directory entry (based on the DWARF version), and
use it afterwards.
Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly. Their produced
DWARF5 binaries will change a bit, in that they will now have a single
directory and file, where they had two before. But it doesn't change
the expected GDB behavior.
Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b
|
|
As reported in PR29043, when running test-case gdb.dwarf2/dw2-lines.exp with
target board unix/-m32/-fPIE/-pie, we run into:
...
Breakpoint 2, 0x56555540 in bar ()^M
(gdb) PASS: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
continue to breakpoint: foo \(1\)
next^M
Single stepping until exit from function bar,^M
which has no line number information.^M
0x56555587 in main ()^M
(gdb) FAIL: gdb.dwarf2/dw2-lines.exp: cv=2: cdw=32: lv=2: ldw=32: \
next to foo (2)
...
The problem is that the bar breakpoint ends up at an unexpected location
because:
- the synthetic debug info is incomplete and doesn't provide line info
for the prologue part of the function, so consequently gdb uses the i386
port prologue skipper to get past the prologue
- the i386 port prologue skipper doesn't get past a get_pc_thunk call.
Work around this in the test-case by breaking on bar_label instead.
Tested on x86_64-linux with target boards unix, unix/-m32, unix/-fPIE/-pie and
unix/-m32/-fPIE/-pie.
|
|
By calling `uplevel $body` in the program proc (a pattern we use at many
places), we can get rid of curly braces around each line number program
directive. That seems like a nice small improvement to me.
Change-Id: Ib327edcbffbd4c23a08614adee56c12ea25ebc0b
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
While debugging a problem in gdb.dwarf2/dw2-lines.exp, I realized that the
test-case generates all executables and associated temporary files using the
same filenames.
Fix this by adding a new proc prefix_id in lib/gdb.exp, and using it in the
test-case.
Tested on x86_64-linux.
|
|
I noticed a new gcc option -gdwarf64 and tried it out (using gcc 11.2.1).
With a test-case hello.c:
...
int
main (void)
{
printf ("hello\n");
return 0;
}
...
compiled like this:
...
$ gcc -g -gdwarf64 ~/hello.c
...
I ran into:
...
$ gdb -q -batch a.out
DW_FORM_line_strp pointing outside of .debug_line_str section \
[in module a.out]
...
Debugging gdb revealed that the string offset is:
...
(gdb) up
objfile=0x182ab70, str_offset=1378684502312,
form_name=0xeae9b5 "DW_FORM_line_strp")
at src/gdb/dwarf2/section.c:208
208 error (_("%s pointing outside of %s section [in module %s]"),
(gdb) p /x str_offset
$1 = 0x14100000128
(gdb)
...
which is read when parsing a .debug_line entry at 0x1e0.
Looking with readelf at the 0x1e0 entry, we have:
...
The Directory Table (offset 0x202, lines 2, columns 1):
Entry Name
0 (indirect line string, offset: 0x128): /data/gdb_versions/devel
1 (indirect line string, offset: 0x141): /home/vries
...
which in a hexdump looks like:
...
0x00000200 1f022801 00004101 00000201 1f020f02
...
What happens is the following:
- readelf interprets the DW_FORM_line_strp reference to .debug_line_str as
a 4 byte value, and sees entries 0x00000128 and 0x00000141.
- gdb instead interprets it as an 8 byte value, and sees as first entry
0x0000014100000128, which is too big so it bails out.
AFAIU, gdb is wrong. It assumes DW_FORM_line_strp is 8 bytes on the basis
that the corresponding CU is 64-bit DWARF. However, the .debug_line
contribution has it's own initial_length field, and encodes there that it's
32-bit DWARF.
Fix this by using the correct offset size for DW_FORM_line_strp references
in .debug_line.
Note: the described test-case does trigger this complaint (both with and
without this patch):
...
$ gdb -q -batch -iex "set complaints 10" a.out
During symbol reading: intermixed 32-bit and 64-bit DWARF sections
...
The reason that the CU has 64-bit dwarf is because -gdwarf64 was passed to
gcc. The reason that the .debug_line entry has 32-bit dwarf is because that's
what gas generates. Perhaps this is complaint-worthy, but I don't think it
is wrong.
Tested on x86_64-linux, using native and target board dwarf64.exp.
|
|
The v5 section version for .debug_line has:
- two new fields address_size and segment_selector_size
- a different way to encode the directory and filename tables.
Add support for this in the dwarf assembler.
For now, make the v5 directory and filename tables work with the v4 type of
specification in the test-cases by adding duplicate entries at position 0.
This will need to be properly fixed with an intrusive fix that changes how
directory and filename entries are specified in the test-cases, f.i:
...
set diridx [include_dir "${srcdir}/${subdir}"]
set fileidx [file_name "$srcfile" $diridx]
...
Tested on x86_64-linux.
|
|
The .debug_line header got a new field in v4:
maximum_operations_per_instruction.
Generate this field in the dwarf assembler, for now hardcoding the value to 1,
meaning non-VLIW.
Tested on x86_64-linux.
|
|
Add a new test-case gdb.dwarf2/dw2-lines.exp that tests various .debug_line
sections.
Tested on x86_64-linux.
|
