Age | Commit message (Collapse) | Author | Files | Lines |
|
This changes some tests to use "require is_c_compiler_gcc".
|
|
This changes some tests to use "require dwarf2_support".
|
|
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.
|
|
After this commit the gcc_compiled global is no longer exported from
lib/gdb.exp. In theory we could switch over all uses of gcc_compiled
to instead call test_compiler_info directly, however, I have instead
added a new proc to gdb.exp: 'is_c_compiler_gcc'. I've then updated
the testsuite to call this proc instead of using the global.
Having a new proc specifically for this task means that we have a
single consistent pattern for detecting gcc. By wrapping this logic
within a proc that calls test_compiler_info, rather than using the
global, means that test scripts don't need to call get_compiler_info
before they read the global, simply calling the new proc does
everything in one go.
As a result I've been able to remove the get_compiler_info calls from
all the test scripts that I've touched in this commit.
In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was
being checked at the top of the script to decide if the whole script
should be skipped or not. In these cases I've called the new proc
directly and removed all uses of gcc_compiled.
In other cases, e.g. most of the gdb.base scripts, there were many
uses of gcc_compiled. In these cases I set a new global gcc_compiled
near the top of the script, and leave the rest of the script
unchanged.
There should be no changes in what is tested after this commit.
|
|
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.
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
After the is-stmt support commit:
commit 8c95582da858ac981f689a6f599acacb8c5c490f
Date: Mon Dec 30 21:04:51 2019 +0000
gdb: Add support for tracking the DWARF line table is-stmt field
A regression was observed where a breakpoint could no longer be placed
in some cases.
Consider a line table like this:
File 1: test.c
File 2: test.h
| Addr | File | Line | Stmt |
|------|------|------|------|
| 1 | 1 | 16 | Y |
| 2 | 1 | 17 | Y |
| 3 | 2 | 21 | Y |
| 4 | 2 | 22 | Y |
| 4 | 1 | 18 | N |
| 5 | 2 | 23 | N |
| 6 | 1 | 24 | Y |
| 7 | 1 | END | Y |
|------|------|------|------|
Before the is-stmt patch GDB would ignore any non-stmt lines, so GDB
built two line table structures:
File 1 File 2
------ ------
| Addr | Line | | Addr | Line |
|------|------| |------|------|
| 1 | 16 | | 3 | 21 |
| 2 | 17 | | 4 | 22 |
| 3 | END | | 6 | END |
| 6 | 24 | |------|------|
| 7 | END |
|------|------|
After the is-stmt patch GDB now records non-stmt lines, so the
generated line table structures look like this:
File 1 File 2
------ ------
| Addr | Line | Stmt | | Addr | Line | Stmt |
|------|------|------| |------|------|------|
| 1 | 16 | Y | | 3 | 21 | Y |
| 2 | 17 | Y | | 4 | 22 | Y |
| 3 | END | Y | | 4 | END | Y |
| 4 | 18 | N | | 5 | 23 | N |
| 5 | END | Y | | 6 | END | Y |
| 6 | 24 | Y | |------|------|------|
| 7 | END | Y |
|------|------|------|
The problem is that in 'File 2', end END marker at address 4 causes
the previous line table entry to be discarded, so we actually end up
with this:
File 2
------
| Addr | Line | Stmt |
|------|------|------|
| 3 | 21 | Y |
| 4 | END | Y |
| 5 | 23 | N |
| 6 | END | Y |
|------|------|------|
When a user tries to place a breakpoint in file 2 at line 22, this is
no longer possible.
The solution I propose here is that we ignore line table entries that
would trigger a change of file if:
1. The new line being added is at the same address as the previous
line, and
2. We have previously seen an is-stmt line at the current address.
The result of this is that GDB switches file, and knows that some line
entry (or entries) are going to be discarded, prefer to keep is-stmt
lines and discard non-stmt lines.
After this commit the lines tables are now:
File 1 File 2
------ ------
| Addr | Line | Stmt | | Addr | Line | Stmt |
|------|------|------| |------|------|------|
| 1 | 16 | Y | | 3 | 21 | Y |
| 2 | 17 | Y | | 4 | 22 | Y |
| 3 | END | Y | | 5 | 23 | N |
| 5 | END | Y | | 6 | END | Y |
| 6 | 24 | Y | |------|------|------|
| 7 | END | Y |
|------|------|------|
We've lost the non-stmt entry for file 1, line 18, but retained the
is-stmt entry for file 2, line 22. The user can now place a
breakpoint at that location.
One problem that came from this commit was the test
gdb.cp/step-and-next-inline.exp, which broke in several places. After
looking at this test again I think that in some cases this test was
only ever passing by pure luck. The debug GCC is producing for this
test is pretty broken. I raised this GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
for this and disabled one entire half of the test. There are still
some cases in here that do pass, and if/when GCC is fixed it would be
great to enable this test again.
gdb/ChangeLog:
* dwarf2/read.c (class lnp_state_machine) <m_last_address>: New
member variable.
<m_stmt_at_address>: New member variable.
(lnp_state_machine::record_line): Don't record some lines, update
tracking of is_stmt at the same address.
(lnp_state_machine::lnp_state_machine): Initialise new member
variables.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.exp (do_test): Skip all tests in the
use_header case.
* gdb.dwarf2/dw2-inline-header-1.exp: New file.
* gdb.dwarf2/dw2-inline-header-2.exp: New file.
* gdb.dwarf2/dw2-inline-header-3.exp: New file.
* gdb.dwarf2/dw2-inline-header-lbls.c: New file.
* gdb.dwarf2/dw2-inline-header.c: New file.
* gdb.dwarf2/dw2-inline-header.h: New file.
|