From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: Andrew Burgess <andrew.burgess@embecosm.com>,
Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org, Alexandre Oliva <oliva@gnu.org>
Subject: Re: [PATCH 2/2] gdb: Preserve is-stmt lines when switch between files
Date: Fri, 15 May 2020 05:35:43 +0200 [thread overview]
Message-ID: <AM6PR03MB5170A9649195EB956B21E521E4BD0@AM6PR03MB5170.eurprd03.prod.outlook.com> (raw)
In-Reply-To: <20200514223925.GS3522@embecosm.com>
[-- Attachment #1: Type: text/plain, Size: 7491 bytes --]
Hi Andrew, and Tom
I'll try to help, if I can.
I must admit I was busy with other things, so I have
not much new info, but I can add my view.
First I want to make you aware, of my last e-mails
on this issue, I wonder if you got them.
I added Alexandre Oliva who maintains the debug info
in GCC to CC then, and unfortunately although I was
hoping that he gives his view on this matter, I think
I have not received any response from him so far.
https://sourceware.org/pipermail/gdb-patches/2020-April/167933.html
https://sourceware.org/pipermail/gdb-patches/2020-April/167932.html
I must note that it is impossible to find out the
e-mail addresses which were in CC on the mailing list
archives since the unfortunate move to the new
maling list archive format. But I added oliva@gnu.org
in CC, probably you should do that as well, since
I think we cannot get anything changed in the gcc
debug output unless we can convince him about it.
Andrew, as far as I remember the range info of the
inlined subroutines were not correct, in your patch.
GCC tells us where the code originating from the
inlined code starts and ends. The byte addresses.
These must be the same addresses where the line numbers
switch from the calling procedure to the inlined procedure
but the range info in your dwarf code is artificially
and it is having start and end addresses where they
should be.
Can you please fix the range infos in your patch
and re-post it, before we decide how to proceed?
I will probably not have time to do much today,
since this is my son's birthday, and I will probably
bake a birthday cake instead :-)
But I would say that I see a way how I can adjust my
patch to fix the issues which were raised by your test
case (I added the test case from your patch to mine,
and most of it seems to be fine with my latest patch,
one remaining issue is a bit nasty but fixable).
I'll attach the patch file where I am at here, so
you can see what I have now.
It fails only one test case in dw2-inline-header-3.exp
but I would like how it compares to your patch
when Tom would like to try it out on the
internal test cases, he mentioned.
And, yes, of course my approach is that the debug info
is not optimal at all as it is emitted by gcc, but
gdb can probably work around it until it is fixed
which should happen when a new updated dwarf extension
is invented which tells us the view number where
the inlined subroutine ends. The line table program
has view numbers, but not the range info of the
subroutine. That is the deficiency in the dwarf
format I think causes the trouble, apart from the
fact that dwarf is already too complicate to understand.
I must also say, that since if I remember correctly
Andrew's patch makes
gdb.cp/step-and-next-inline.exp
fail, I consider my attempt to make gdb work around
the debug info of inlined subroutines a failure.
While my patch did make
gdb.cp/step-and-next-inline.exp
succeed completely, also the case where the inline
function is not in a header file.
I must also say, and that is not because I have
emotions about it, but just because I consider it
the only possible option when we consider gcc's
debug output format completely broken, then
I will probably just send a one-line patch to
gcc-patches, which reverts the default of
-gstatement-frontiers, that would be safe for
backporting to all active branches.
And it would prevent the !is_stmt line infos
completely, the debug format will then
probably work as before gcc-8 implemented
that for the first time.
So I attached my latest patch version, together
with the Test case from Andrews patch.
On 5/15/20 12:39 AM, Andrew Burgess wrote:
> * Tom Tromey <tom@tromey.com> [2020-05-14 14:18:44 -0600]:
>
>>>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
>>
>> Resurrecting this again ... we have some internal tests that have been
>> failing, and I want to land at least one of these patches to resolve
>> this.
>>
>> Andrew> After reading[2] I'd also be interest to understand what flaw in
>> Andrew> DWARF you feel makes a difference in this case.
>>
>> I also don't understand this.
>>
When you only know where an inline function ends at the byte address.
You can habe line table entries at the same address from the inline
funcion and from the calling function. It is impossible to distinguish
between those, however there is a view number which would be different,
and as Alexandre explains it, these can be consider an extension to the
byte addresses, so if a range info would add a view number we would
know which line infos are from the subroutine and which are not, even
if the byte addresses are identical.
>> Andrew> I think it is great Bernd, that you are reaching out from the GCC
>> Andrew> community to engage with GDB, this is certainly the best way to ensure
>> Andrew> that we can work together as communities to give the best possible
>> Andrew> debug experience, and I'm sorry you feel that I have not been clear
>> Andrew> enough about the issues I'm seeing here.
>>
>> +1
>>
I still think this is possible, I think we need to understand each other
better. Of course stress from release cycles might this even harder.
Are we (gdb maintainers) already under stress to reach the next release version?
>> Andrew> I don't know how we address this without merging your patch,
>> Andrew> releasing GDB and seeing how it works in the wild. However, if we
>> Andrew> did decide to "just try it", I would still prefer we staged things
>> Andrew> as:
>> Andrew> (a) Merge my patch, targeted regression fix, then
>> Andrew> (b) Your patch, new functionality GCC/DWARF ranges work around.
>> Andrew> In this way, if we end up backing out some or all of (b) we still
>> Andrew> have (a) in place that fixes the regression. I'm more than happy
>> Andrew> for a rebase of (b) in include full removal of (a).
>>
>> I think landing your patch is safe to do while we discuss part (b).
>> How about we move forward with that part? Then if we come to agreement
>> on where the bug lies we can decide about that.
>
> I agree. I already rebased this and retested it. Unless someone
> shouts out between now and tomorrow I plan to merge my patch.
>
> Bernd (or anyone else) - I'm more than happy that if a better patch is
> put forward it can revert some or all of my patch, as needed. Like
> Tom, I'd like to see the regressions squashed.
>
No, I am not able to do this once we decide that gcc's debug info
is impossible to implement, I will send a patch to the gcc-patches
which restores the gcc-7 debug info. My patch was based on the
assumption that there is a way to work around the issues, but if
that turns out to be a failure, I will not go back and revert
your patch again, since it seems to revert my work on that issue
completely (see how this patch breaks the step-and-next-inline.exp
test case). And once again, I feel not at all emotional, just that
I want the issue fixed, and next time I will try a completely
different approach which is gcc was wrong, and therefore we will
revert Alexandre Oliva's patch, since it is the least effort and
Alexandre already signaled he also had considered that already.
Alexandre Oliva wrote on 11/19/19:
https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534845.html
> Perhaps we should change our defaults, if the situation with GDB does
> not change :-(
Andrew:
Have you attached your *latest* patch?
Have you done the changes I requested?
Thanks
Bernd.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-range-end-handling-of-inlined-subroutines.patch --]
[-- Type: text/x-patch; name="0001-Fix-range-end-handling-of-inlined-subroutines.patch", Size: 14360 bytes --]
From 1ae05f16f284d2367fcb233070b8664913a3b086 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date: Sun, 9 Feb 2020 21:13:17 +0100
Subject: [PATCH 1/2] Fix range end handling of inlined subroutines
Since the is_stmt is now handled, it becomes
possible to locate dubious is_stmt line entries
at the end of an inlined function, even if the
called inline function is in the same subfile.
When there is a sequence of line entries at the
same address where an inline range ends, and the
last item has is_stmt = 0, we force all previous
items to have is_stmt = 0 as well.
If the last line at that address has is_stmt = 1,
there is no need to change anything, since a step
over will always stop at that last line from the
same address, which is fine, since it is outside
the subroutine.
With this change we lose the ability to set
breakpoints on some lines using file:line syntax,
but the data is not completely lost, as the
line table is still holding those lines, just
with the is_stmt flag reset.
This is necessary as breakpoints on these lines
are problematic, as the call stack is often
wrong. From the block info they appear to be
located in the caller, but they are actually meant
to be part of the subroutine, therefore usually one
frame is missing from the callstack when the
execution stops there.
This is about the best we can do at the moment,
unless location view information are added to the
block ranges debug info structure, and location
views are implemented in gdb in general.
This restores the previous behavior of
record_line that deletes lines at the end of
a function.
gdb:
2020-04-05 Bernd Edlinger <bernd.edlinger@hotmail.de>
* buildsym.c (buildsym_compunit::record_line): Delete
previous lines at the same PC as the end sequence marker,
but don't do that for a fake end sequence marker.
(buildsym_compunit::record_inline_range_end,
patch_inline_end_pos): New helper functions.
(buildsym_compunit::end_symtab_with_blockvector): Patch line table.
(buildsym_compunit::~buildsym_compunit): Cleanup m_inline_end_vector.
* buildsym.h (buildsym_compunit::record_inline_range_end): Declare.
(buildsym_compunit::m_inline_end_vector,
buildsym_compunit::m_inline_end_vector_length,
buildsym_compunit::m_inline_end_vector_nitems): New data items.
* dwarf2/read.c (dwarf2_rnglists_process,
dwarf2_ranges_process): Don't ignore empty ranges here.
(dwarf2_ranges_read): Ignore empty ranges here.
(dwarf2_record_block_ranges): Pass end of range PC to
record_inline_range_end for inline functions.
(dwarf_finish_line): Add new parameter end_sequence.
(lnp_state_machine::record_line): Pass end_sequence to
dwarf_finish_line.
gdb/testsuite:
2020-04-05 Bernd Edlinger <bernd.edlinger@hotmail.de>
* gdb.cp/step-and-next-inline.exp: Adjust test.
---
gdb/buildsym.c | 115 +++++++++++++++++++++++---
gdb/buildsym.h | 11 +++
gdb/dwarf2/read.c | 30 ++++---
gdb/testsuite/gdb.cp/step-and-next-inline.exp | 17 ----
4 files changed, 131 insertions(+), 42 deletions(-)
diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index b9bcc33..ae90175 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -113,6 +113,8 @@ struct pending_block
next1 = next->next;
xfree ((void *) next);
}
+
+ xfree (m_inline_end_vector);
}
struct macro_table *
@@ -691,19 +693,16 @@ struct blockvector *
* sizeof (struct linetable_entry))));
}
- /* Normally, we treat lines as unsorted. But the end of sequence
- marker is special. We sort line markers at the same PC by line
- number, so end of sequence markers (which have line == 0) appear
- first. This is right if the marker ends the previous function,
- and there is no padding before the next function. But it is
- wrong if the previous line was empty and we are now marking a
- switch to a different subfile. We must leave the end of sequence
- marker at the end of this group of lines, not sort the empty line
- to after the marker. The easiest way to accomplish this is to
- delete any empty lines from our table, if they are followed by
- end of sequence markers. All we lose is the ability to set
- breakpoints at some lines which contain no instructions
- anyway. */
+ /* The end of sequence marker is special. We need to delete any
+ previous lines at the same PC, otherwise these lines may cause
+ problems since they might be at the same address as the following
+ function. For instance suppose a function calls abort there is no
+ reason to emit a ret after that point (no joke).
+ So the label may be at the same address where the following
+ function begins. There is also a fake end of sequence marker (-1)
+ that we emit internally when switching between different CUs
+ In this case, duplicate line table entries shall not be deleted.
+ But the line table entry looks the same in both cases. */
if (line == 0)
{
while (subfile->line_vector->nitems > 0)
@@ -714,6 +713,8 @@ struct blockvector *
subfile->line_vector->nitems--;
}
}
+ else if (line == -1)
+ line = 0;
e = subfile->line_vector->item + subfile->line_vector->nitems++;
e->line = line;
@@ -722,6 +723,90 @@ struct blockvector *
}
\f
+/* Record a PC where a inlined subroutine ends. */
+
+void
+buildsym_compunit::record_inline_range_end (CORE_ADDR end)
+{
+ /* The performance of this function is very important,
+ it shall be O(n*log(n)) therefore we do not use std::vector
+ here since some compilers, e.g. visual studio, do not
+ guarantee that for vector::push_back. */
+ if (m_inline_end_vector == nullptr)
+ {
+ m_inline_end_vector_length = INITIAL_LINE_VECTOR_LENGTH;
+ m_inline_end_vector = (CORE_ADDR *)
+ xmalloc (sizeof (CORE_ADDR) * m_inline_end_vector_length);
+ m_inline_end_vector_nitems = 0;
+ }
+ else if (m_inline_end_vector_nitems == m_inline_end_vector_length)
+ {
+ m_inline_end_vector_length *= 2;
+ m_inline_end_vector = (CORE_ADDR *)
+ xrealloc ((char *) m_inline_end_vector,
+ sizeof (CORE_ADDR) * m_inline_end_vector_length);
+ }
+
+ m_inline_end_vector[m_inline_end_vector_nitems++] = end;
+}
+
+\f
+/* Patch the is_stmt bits at the given inline end address.
+ The line table has to be already sorted. */
+
+static void
+patch_inline_end_pos (struct linetable *table, CORE_ADDR end)
+{
+ int a = 2, b = table->nitems - 1;
+ struct linetable_entry *items = table->item;
+
+ /* We need at least two items with pc = end in the table.
+ The lowest usable items are at pos 0 and 1, the highest
+ usable items are at pos b - 2 and b - 1. */
+ if (a > b || end < items[1].pc || end > items[b - 2].pc)
+ return;
+
+ /* Look for the first item with pc > end in the range [a,b].
+ The previous element has pc = end or there is no match.
+ We set a = 2, since we need at least two consecutive elements
+ with pc = end to do anything useful.
+ We set b = nitems - 1, since we are not interested in the last
+ element which should be an end of sequence marker with line = 0
+ and is_stmt = 1. */
+ while (a < b)
+ {
+ int c = (a + b) / 2;
+
+ if (end < items[c].pc)
+ b = c;
+ else
+ a = c + 1;
+ }
+
+ a--;
+ if (items[a].pc != end || items[a].is_stmt)
+ return;
+
+ /* When there is a sequence of line entries at the same address
+ where an inline range ends, and the last item has is_stmt = 0,
+ we force all previous items to have is_stmt = 0 as well.
+ Setting breakpoints at those addresses is currently not
+ supported, since it is unclear if the previous addresses are
+ part of the subroutine or the calling program. */
+ do
+ {
+ /* We stop at the first line entry with a different address,
+ or when we see an end of sequence marker. */
+ a--;
+ if (items[a].pc != end || items[a].line == 0)
+ break;
+
+ items[a].is_stmt = 0;
+ }
+ while (a > 0);
+}
+
+\f
/* Subroutine of end_symtab to simplify it. Look for a subfile that
matches the main source file's basename. If there is only one, and
if the main source file doesn't have any symbol or line number
@@ -955,6 +1040,10 @@ struct compunit_symtab *
subfile->line_vector->item
+ subfile->line_vector->nitems,
lte_is_less_than);
+
+ for (int i = 0; i < m_inline_end_vector_nitems; i++)
+ patch_inline_end_pos (subfile->line_vector,
+ m_inline_end_vector[i]);
}
/* Allocate a symbol table if necessary. */
diff --git a/gdb/buildsym.h b/gdb/buildsym.h
index c768a4c..2845789 100644
--- a/gdb/buildsym.h
+++ b/gdb/buildsym.h
@@ -190,6 +190,8 @@ struct buildsym_compunit
void record_line (struct subfile *subfile, int line, CORE_ADDR pc,
bool is_stmt);
+ void record_inline_range_end (CORE_ADDR end);
+
struct compunit_symtab *get_compunit_symtab ()
{
return m_compunit_symtab;
@@ -397,6 +399,15 @@ struct buildsym_compunit
/* Pending symbols that are local to the lexical context. */
struct pending *m_local_symbols = nullptr;
+
+ /* Pending inline end range addresses. */
+ CORE_ADDR * m_inline_end_vector = nullptr;
+
+ /* Number of allocated inline end range addresses. */
+ int m_inline_end_vector_length = 0;
+
+ /* Number of pending inline end range addresses. */
+ int m_inline_end_vector_nitems = 0;
};
\f
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index ab21ab0..3c54a83 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -13703,10 +13703,6 @@ class process_die_scope
return false;
}
- /* Empty range entries have no effect. */
- if (range_beginning == range_end)
- continue;
-
range_beginning += *base;
range_end += *base;
@@ -13814,10 +13810,6 @@ class process_die_scope
return 0;
}
- /* Empty range entries have no effect. */
- if (range_beginning == range_end)
- continue;
-
range_beginning += *base;
range_end += *base;
@@ -13857,6 +13849,10 @@ class process_die_scope
retval = dwarf2_ranges_process (offset, cu,
[&] (CORE_ADDR range_beginning, CORE_ADDR range_end)
{
+ /* Empty range entries have no effect. */
+ if (range_beginning == range_end)
+ return;
+
if (ranges_pst != NULL)
{
CORE_ADDR lowpc;
@@ -14094,6 +14090,7 @@ class process_die_scope
struct gdbarch *gdbarch = objfile->arch ();
struct attribute *attr;
struct attribute *attr_high;
+ bool inlined_subroutine = (die->tag == DW_TAG_inlined_subroutine);
attr_high = dwarf2_attr (die, DW_AT_high_pc, cu);
if (attr_high)
@@ -14109,7 +14106,10 @@ class process_die_scope
low = gdbarch_adjust_dwarf2_addr (gdbarch, low + baseaddr);
high = gdbarch_adjust_dwarf2_addr (gdbarch, high + baseaddr);
- cu->get_builder ()->record_block_range (block, low, high - 1);
+ if (inlined_subroutine)
+ cu->get_builder ()->record_inline_range_end (high);
+ if (low < high)
+ cu->get_builder ()->record_block_range (block, low, high - 1);
}
}
@@ -14134,6 +14134,10 @@ class process_die_scope
end += baseaddr;
start = gdbarch_adjust_dwarf2_addr (gdbarch, start);
end = gdbarch_adjust_dwarf2_addr (gdbarch, end);
+ if (inlined_subroutine)
+ cu->get_builder ()->record_inline_range_end (end);
+ if (start == end)
+ return;
cu->get_builder ()->record_block_range (block, start, end - 1);
blockvec.emplace_back (start, end);
});
@@ -20031,7 +20035,7 @@ class lnp_state_machine
static void
dwarf_finish_line (struct gdbarch *gdbarch, struct subfile *subfile,
- CORE_ADDR address, struct dwarf2_cu *cu)
+ CORE_ADDR address, struct dwarf2_cu *cu, bool end_sequence)
{
if (subfile == NULL)
return;
@@ -20044,7 +20048,8 @@ class lnp_state_machine
paddress (gdbarch, address));
}
- dwarf_record_line_1 (gdbarch, subfile, 0, address, true, cu);
+ dwarf_record_line_1 (gdbarch, subfile, end_sequence ? 0 : -1, address,
+ true, cu);
}
void
@@ -20077,7 +20082,8 @@ class lnp_state_machine
|| end_sequence)
{
dwarf_finish_line (m_gdbarch, m_last_subfile, m_address,
- m_currently_recording_lines ? m_cu : nullptr);
+ m_currently_recording_lines ? m_cu : nullptr,
+ end_sequence);
}
if (!end_sequence)
diff --git a/gdb/testsuite/gdb.cp/step-and-next-inline.exp b/gdb/testsuite/gdb.cp/step-and-next-inline.exp
index 3733fa7..e3a5793 100644
--- a/gdb/testsuite/gdb.cp/step-and-next-inline.exp
+++ b/gdb/testsuite/gdb.cp/step-and-next-inline.exp
@@ -52,37 +52,20 @@ proc do_test { use_header } {
gdb_test "step" ".*" "step into get_alias_set"
gdb_test "bt" "\\s*\\#0\\s+get_alias_set\[^\r\]*${srcfile}:.*" \
"not in inline 1"
- # It's possible that this first failure (when not using a header
- # file) is GCC's fault, though the remaining failures would best
- # be fixed by adding location views support (though it could be
- # that some easier heuristic could be figured out). Still, it is
- # not certain that the first failure wouldn't also be fixed by
- # having location view support, so for now it is tagged as such.
- if {!$use_header} { setup_kfail "*-*-*" symtab/25507 }
gdb_test "next" ".*TREE_TYPE.*" "next step 1"
gdb_test "bt" "\\s*\\#0\\s+get_alias_set\[^\r\]*${srcfile}:.*" \
"not in inline 2"
gdb_test "next" ".*TREE_TYPE.*" "next step 2"
gdb_test "bt" "\\s*\\#0\\s+get_alias_set\[^\r\]*${srcfile}:.*" \
"not in inline 3"
- if {!$use_header} { setup_kfail "*-*-*" symtab/25507 }
gdb_test "next" ".*TREE_TYPE.*" "next step 3"
gdb_test "bt" "\\s*\\#0\\s+get_alias_set\[^\r\]*${srcfile}:.*" \
"not in inline 4"
- if {!$use_header} { setup_kfail "*-*-*" symtab/25507 }
gdb_test "next" "return 0.*" "next step 4"
gdb_test "bt" \
"\\s*\\#0\\s+(main|get_alias_set)\[^\r\]*${srcfile}:.*" \
"not in inline 5"
- if {!$use_header} {
- # With the debug from GCC 10.x (and earlier) GDB is currently
- # unable to successfully complete the following tests when we
- # are not using a header file.
- kfail symtab/25507 "stepping tests"
- return
- }
-
clean_restart ${executable}
if ![runto_main] {
--
1.9.1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-gdb-Preserve-is-stmt-lines-when-switch-between-files.patch --]
[-- Type: text/x-patch; name="0002-gdb-Preserve-is-stmt-lines-when-switch-between-files.patch", Size: 25012 bytes --]
From 804bd32133d585d3dd3d707baf7d14ab1ea659d1 Mon Sep 17 00:00:00 2001
From: Andrew Burgess <andrew.burgess@embecosm.com>
Date: Fri, 3 Apr 2020 23:21:04 +0100
Subject: [PATCH 2/2] gdb: Preserve is-stmt lines when switch between 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/testsuite/ChangeLog:
* 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.
---
| 156 ++++++++++++++++++
| 179 ++++++++++++++++++++
| 192 ++++++++++++++++++++++
| 46 ++++++
| 24 +++
| 24 +++
6 files changed, 621 insertions(+)
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-inline-header-1.exp
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-inline-header-2.exp
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-inline-header-3.exp
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-inline-header-lbls.c
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-inline-header.c
create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-inline-header.h
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-1.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-1.exp
new file mode 100644
index 0000000..6a1e990
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-1.exp
@@ -0,0 +1,156 @@
+# Copyright 2020 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Setup a line table where:
+#
+# | 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 |
+# |------|------|------|------|
+#
+# Places a brekpoint at file 2, line 22. Previously GDB would discrad
+# the line table entry for this line due to switching files for the
+# file 1, line 18 non-statement line. After patching however, GDB now
+# discards the file 1, line 18 entry instead, and the breakpoint at
+# line 22 should succeed.
+
+load_lib dwarf.exp
+
+# This test can only be run on targets which support DWARF-2 and use gas.
+if {![dwarf2_support]} {
+ return 0
+}
+
+# The .c files use __attribute__.
+if [get_compiler_info] {
+ return -1
+}
+if !$gcc_compiled {
+ return 0
+}
+
+standard_testfile dw2-inline-header-lbls.c dw2-inline-header.S \
+ dw2-inline-header.c dw2-inline-header.h
+
+set asm_file [standard_output_file $srcfile2]
+Dwarf::assemble $asm_file {
+ global srcdir subdir srcfile srcfile3 srcfile4
+ declare_labels lines_label callee_subprog_label
+
+ get_func_info main
+
+ cu {} {
+ compile_unit {
+ {producer "gcc" }
+ {language @DW_LANG_C}
+ {name ${srcfile3}}
+ {low_pc 0 addr}
+ {stmt_list ${lines_label} DW_FORM_sec_offset}
+ } {
+ callee_subprog_label: subprogram {
+ {external 1 flag}
+ {name callee}
+ {inline 3 data1}
+ }
+ subprogram {
+ {external 1 flag}
+ {name main}
+ {low_pc $main_start addr}
+ {high_pc "$main_start + $main_len" addr}
+ } {
+ inlined_subroutine {
+ {abstract_origin %$callee_subprog_label}
+ {low_pc line_label_1 addr}
+ {high_pc line_label_7 addr}
+ {call_file 1 data1}
+ {call_line 18 data1}
+ }
+ }
+ }
+ }
+
+ lines {version 2 default_is_stmt 1} lines_label {
+ include_dir "${srcdir}/${subdir}"
+ file_name "$srcfile3" 1
+ file_name "$srcfile4" 1
+
+ program {
+ {DW_LNE_set_address line_label_1}
+ {DW_LNS_advance_line 15}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_2}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNS_set_file 2}
+ {DW_LNE_set_address line_label_3}
+ {DW_LNS_advance_line 4}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_4}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNS_advance_line -4}
+ {DW_LNS_set_file 1}
+ {DW_LNS_negate_stmt}
+ {DW_LNS_copy}
+
+ {DW_LNS_set_file 2}
+ {DW_LNE_set_address line_label_5}
+ {DW_LNS_advance_line 5}
+ {DW_LNS_copy}
+
+ {DW_LNS_negate_stmt}
+ {DW_LNS_set_file 1}
+ {DW_LNE_set_address line_label_6}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_7}
+ {DW_LNE_end_sequence}
+ }
+ }
+}
+
+if { [prepare_for_testing "failed to prepare" ${testfile} \
+ [list $srcfile $asm_file] {nodebug optimize=-O1}] } {
+ return -1
+}
+
+if ![runto_main] {
+ return -1
+}
+
+# Delete all breakpoints so that the output of "info breakpoints"
+# below will only contain a single breakpoint.
+delete_breakpoints
+
+# Place a breakpoint within the function in the header file.
+gdb_breakpoint "${srcfile4}:22"
+
+# Check that the breakpoint was placed where we expected. It should
+# appear at the requested line. When the bug in GDB was present the
+# breakpoint would be placed on one of the following lines instead.
+gdb_test "info breakpoints" \
+ ".* in callee at \[^\r\n\]+${srcfile4}:22\\y.*"
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-2.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-2.exp
new file mode 100644
index 0000000..4649991
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-2.exp
@@ -0,0 +1,179 @@
+# Copyright 2020 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Setup a line table where:
+#
+# | 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 | 1 | 19 | Y |
+# | 6 | 1 | 20 | Y |
+# | 7 | 1 | END | Y |
+# |------|------|------|------|
+#
+#
+# Place the first brekpoint at file 2, line 22 and a second breakpoint
+# at file 1, line 19. A third breakpoint is placed at file 1, line
+# 18, but as this line table entry will have been discarded[1] the
+# third breakpoint will actually be placed at the same location as the
+# second breakpoint.
+#
+# [1] The entry for file 1, line 18 is discarded because it is at the
+# same address as the previous entry, but the previous entry is-stmt,
+# while line 18 is a non-stmt.
+
+load_lib dwarf.exp
+
+# This test can only be run on targets which support DWARF-2 and use gas.
+if {![dwarf2_support]} {
+ return 0
+}
+
+# The .c files use __attribute__.
+if [get_compiler_info] {
+ return -1
+}
+if !$gcc_compiled {
+ return 0
+}
+
+standard_testfile dw2-inline-header-lbls.c dw2-inline-header.S \
+ dw2-inline-header.c dw2-inline-header.h
+
+set asm_file [standard_output_file $srcfile2]
+Dwarf::assemble $asm_file {
+ global srcdir subdir srcfile srcfile3 srcfile4
+ declare_labels lines_label callee_subprog_label
+
+ get_func_info main
+
+ cu {} {
+ compile_unit {
+ {producer "gcc" }
+ {language @DW_LANG_C}
+ {name ${srcfile3}}
+ {low_pc 0 addr}
+ {stmt_list ${lines_label} DW_FORM_sec_offset}
+ } {
+ callee_subprog_label: subprogram {
+ {external 1 flag}
+ {name callee}
+ {inline 3 data1}
+ }
+ subprogram {
+ {external 1 flag}
+ {name main}
+ {low_pc $main_start addr}
+ {high_pc "$main_start + $main_len" addr}
+ } {
+ inlined_subroutine {
+ {abstract_origin %$callee_subprog_label}
+ {low_pc line_label_1 addr}
+ {high_pc line_label_7 addr}
+ {call_file 1 data1}
+ {call_line 18 data1}
+ }
+ }
+ }
+ }
+
+ lines {version 2 default_is_stmt 1} lines_label {
+ include_dir "${srcdir}/${subdir}"
+ file_name "$srcfile3" 1
+ file_name "$srcfile4" 1
+
+ program {
+ {DW_LNE_set_address line_label_1}
+ {DW_LNS_advance_line 15}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_2}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNS_set_file 2}
+ {DW_LNE_set_address line_label_3}
+ {DW_LNS_advance_line 4}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_4}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNS_advance_line -4}
+ {DW_LNS_set_file 1}
+ {DW_LNS_negate_stmt}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_5}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_negate_stmt}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_6}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_7}
+ {DW_LNE_end_sequence}
+ }
+ }
+}
+
+if { [prepare_for_testing "failed to prepare" ${testfile} \
+ [list $srcfile $asm_file] {nodebug optimize=-O1}] } {
+ return -1
+}
+
+if ![runto_main] {
+ return -1
+}
+
+# Delete all breakpoints so that the output of "info breakpoints"
+# below will only contain a single breakpoint.
+delete_breakpoints
+
+# Place a breakpoint within the function in the header file.
+gdb_breakpoint "${srcfile4}:22"
+
+# Check that the breakpoint was placed where we expected. It should
+# appear at the requested line. When the bug in GDB was present the
+# breakpoint would be placed on one of the following lines instead.
+gdb_test "info breakpoints" \
+ ".* in callee at \[^\r\n\]+${srcfile4}:22\\y.*" \
+ "check for breakpoint at ${srcfile4}"
+
+# Delete all breakpoints so that the output of "info breakpoints"
+# below will only contain a single breakpoint.
+delete_breakpoints
+
+# Place a breakpoint within the function in the header file.
+gdb_breakpoint "${srcfile3}:19"
+
+# Check that the breakpoint was placed where we expected. It should
+# appear at the requested line. When the bug in GDB was present the
+# breakpoint would be placed on one of the following lines instead.
+gdb_test "info breakpoints" \
+ ".* in callee at \[^\r\n\]+${srcfile3}:19\\y.*" \
+ "check for breakpoint at ${srcfile3}"
+
+# Line table entry for line 18 will have been discarded, so this
+# brekpoint will be at the same location as line 19.
+gdb_test "break ${srcfile3}:18" \
+ "Note: breakpoint $decimal also set at pc $hex.*"
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-3.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-3.exp
new file mode 100644
index 0000000..c683dc4
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-3.exp
@@ -0,0 +1,192 @@
+# Copyright 2020 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Setup a line table where:
+#
+# | 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 | 1 | 19 | N |
+# | 6 | 1 | 20 | Y |
+# | 7 | 1 | END | Y |
+# |------|------|------|------|
+#
+# Break at file 2, line 22, then single instruction step forward. We
+# should pass through line 19 and then encounter line 20.
+#
+# Currently we don't expect GDB to see file 1, line 18, as this is a
+# non-stmt line in a different file at the same address as the
+# previous is-stmt line.
+
+load_lib dwarf.exp
+
+# This test can only be run on targets which support DWARF-2 and use gas.
+if {![dwarf2_support]} {
+ return 0
+}
+
+# The .c files use __attribute__.
+if [get_compiler_info] {
+ return -1
+}
+if !$gcc_compiled {
+ return 0
+}
+
+standard_testfile dw2-inline-header-lbls.c dw2-inline-header.S \
+ dw2-inline-header.c dw2-inline-header.h
+
+set asm_file [standard_output_file $srcfile2]
+Dwarf::assemble $asm_file {
+ global srcdir subdir srcfile srcfile3 srcfile4
+ declare_labels lines_label callee_subprog_label
+
+ get_func_info main
+
+ cu {} {
+ compile_unit {
+ {producer "gcc" }
+ {language @DW_LANG_C}
+ {name ${srcfile3}}
+ {low_pc 0 addr}
+ {stmt_list ${lines_label} DW_FORM_sec_offset}
+ } {
+ callee_subprog_label: subprogram {
+ {external 1 flag}
+ {name callee}
+ {inline 3 data1}
+ }
+ subprogram {
+ {external 1 flag}
+ {name main}
+ {low_pc $main_start addr}
+ {high_pc "$main_start + $main_len" addr}
+ } {
+ inlined_subroutine {
+ {abstract_origin %$callee_subprog_label}
+ {low_pc line_label_1 addr}
+ {high_pc line_label_7 addr}
+ {call_file 1 data1}
+ {call_line 18 data1}
+ }
+ }
+ }
+ }
+
+ lines {version 2 default_is_stmt 1} lines_label {
+ include_dir "${srcdir}/${subdir}"
+ file_name "$srcfile3" 1
+ file_name "$srcfile4" 1
+
+ program {
+ {DW_LNE_set_address line_label_1}
+ {DW_LNS_advance_line 15}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_2}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNS_set_file 2}
+ {DW_LNE_set_address line_label_3}
+ {DW_LNS_advance_line 4}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_4}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNS_advance_line -4}
+ {DW_LNS_set_file 1}
+ {DW_LNS_negate_stmt}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_5}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_6}
+ {DW_LNS_advance_line 1}
+ {DW_LNS_negate_stmt}
+ {DW_LNS_copy}
+
+ {DW_LNE_set_address line_label_7}
+ {DW_LNE_end_sequence}
+ }
+ }
+}
+
+if { [prepare_for_testing "failed to prepare" ${testfile} \
+ [list $srcfile $asm_file] {nodebug optimize=-O1}] } {
+ return -1
+}
+
+if ![runto_main] {
+ return -1
+}
+
+# Delete all breakpoints so that the output of "info breakpoints"
+# below will only contain a single breakpoint.
+delete_breakpoints
+
+# Place a breakpoint within the function in the header file.
+gdb_breakpoint "${srcfile4}:22"
+
+# Check that the breakpoint was placed where we expected. It should
+# appear at the requested line. When the bug in GDB was present the
+# breakpoint would be placed on one of the following lines instead.
+gdb_test "info breakpoints" \
+ ".* in callee at \[^\r\n\]+${srcfile4}:22\\y.*"
+
+gdb_continue_to_breakpoint "${srcfile4}:22" \
+ ".* ${srcfile4} : 22 .*"
+
+# Now single instruction step forward. Eventually we should hit
+# ${srcfile3}:20, but before we do we should hit the non-statement
+# line ${srcfile3}:19.
+#
+# We don't know how many instructions we'll need to step, but 100
+# should be enough for everyone (surely), and this stops us looping
+# forever if something goes wrong.
+set found_line_19 0
+set found_line_20 0
+set keep_going 1
+for { set i 0 } { $i < 100 && $keep_going } { incr i } {
+ set keep_going 0
+ gdb_test_multiple "stepi" "stepi ${i}" {
+ -re "${srcfile3} : 19 .*${gdb_prompt} " {
+ set found_line_19 1
+ set keep_going 1
+ }
+
+ -re "${srcfile3} : 20 .*${gdb_prompt} " {
+ set found_line_20 1
+ }
+
+ -re "${srcfile4} : 22 .*${gdb_prompt} " {
+ # Not left line 22 yet.
+ set keep_going 1
+ }
+ }
+}
+
+gdb_assert { $found_line_19 && $found_line_20 } \
+ "found line 19 and 20"
+
+
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-lbls.c b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-lbls.c
new file mode 100644
index 0000000..a1b7b17
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-lbls.c
@@ -0,0 +1,46 @@
+/* Copyright 2020 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+/* Used to insert labels with which we can build a fake line table. */
+#define LL(N) asm ("line_label_" #N ": .globl line_label_" #N)
+
+volatile int var;
+volatile int bar;
+
+/* Generate some code to take up some space. */
+#define FILLER do { \
+ var = 99; \
+} while (0)
+
+int
+main ()
+{ /* main prologue */
+ asm ("main_label: .globl main_label");
+ LL (1); // F1, Ln 16
+ FILLER;
+ LL (2); // F1, Ln 17
+ FILLER;
+ LL (3); // F2, Ln 21
+ FILLER;
+ LL (4); // F2, Ln 22 // F1, Ln 18, !S
+ FILLER;
+ LL (5); // F1, Ln 19 !S
+ FILLER;
+ LL (6); // F1, Ln 20
+ FILLER;
+ LL (7);
+ FILLER;
+ return 0; /* main end */
+}
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header.c b/gdb/testsuite/gdb.dwarf2/dw2-inline-header.c
new file mode 100644
index 0000000..a833126
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header.c
@@ -0,0 +1,24 @@
+/* Copyright 2020 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+/* dw2-inline-header.c : 16 */
+/* dw2-inline-header.c : 17 */
+/* dw2-inline-header.c : 18 */
+/* dw2-inline-header.c : 19 */
+/* dw2-inline-header.c : 20 */
+/* dw2-inline-header.c : 21 */
+/* dw2-inline-header.c : 22 */
+/* dw2-inline-header.c : 23 */
+/* dw2-inline-header.c : 24 */
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header.h b/gdb/testsuite/gdb.dwarf2/dw2-inline-header.h
new file mode 100644
index 0000000..7233acb
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header.h
@@ -0,0 +1,24 @@
+/* Copyright 2020 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+/* dw2-inline-header.h : 16 */
+/* dw2-inline-header.h : 17 */
+/* dw2-inline-header.h : 18 */
+/* dw2-inline-header.h : 19 */
+/* dw2-inline-header.h : 20 */
+/* dw2-inline-header.h : 21 */
+/* dw2-inline-header.h : 22 */
+/* dw2-inline-header.h : 23 */
+/* dw2-inline-header.h : 24 */
--
1.9.1
next prev parent reply other threads:[~2020-05-15 3:35 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-05 11:37 [PATCH 0/2] Line table is_stmt support Andrew Burgess
2020-02-05 11:37 ` [PATCH 1/2] gdb/testsuite: Add is-stmt support to the DWARF compiler Andrew Burgess
2020-02-05 11:37 ` [PATCH 2/2] gdb: Add support for tracking the DWARF line table is-stmt field Andrew Burgess
2020-02-05 17:55 ` Bernd Edlinger
2020-02-10 18:30 ` Bernd Edlinger
2020-02-11 13:57 ` Andrew Burgess
2020-02-14 20:05 ` Bernd Edlinger
2020-03-05 18:01 ` Bernd Edlinger
2020-03-08 12:50 ` [PATCHv2 0/2] Line table is_stmt support Andrew Burgess
2020-03-08 14:39 ` Bernd Edlinger
2020-03-10 23:01 ` Andrew Burgess
2020-03-11 6:50 ` Simon Marchi
2020-03-11 11:28 ` Andrew Burgess
2020-03-11 13:27 ` Simon Marchi
2020-04-03 22:21 ` [PATCH 0/2] More regression fixing from is-stmt patches Andrew Burgess
2020-04-03 22:21 ` [PATCH 1/2] gdb/testsuite: Move helper function into lib/dwarf.exp Andrew Burgess
2020-04-06 20:18 ` Tom Tromey
2020-04-14 11:18 ` Andrew Burgess
2020-04-03 22:21 ` [PATCH 2/2] gdb: Preserve is-stmt lines when switch between files Andrew Burgess
2020-04-04 18:07 ` Bernd Edlinger
2020-04-04 19:59 ` Bernd Edlinger
2020-04-04 22:23 ` Andrew Burgess
2020-04-05 0:04 ` Bernd Edlinger
2020-04-05 0:47 ` Bernd Edlinger
2020-04-05 8:55 ` Bernd Edlinger
2020-04-11 3:52 ` Bernd Edlinger
2020-04-12 17:13 ` Bernd Edlinger
2020-04-14 11:28 ` Andrew Burgess
2020-04-14 11:37 ` Bernd Edlinger
2020-04-14 11:41 ` Bernd Edlinger
2020-04-14 13:08 ` Andrew Burgess
2020-04-16 17:18 ` Andrew Burgess
2020-04-22 21:13 ` Tom Tromey
2020-04-25 7:06 ` Bernd Edlinger
2020-04-27 10:34 ` Andrew Burgess
2020-05-14 20:18 ` Tom Tromey
2020-05-14 22:39 ` Andrew Burgess
2020-05-15 3:35 ` Bernd Edlinger [this message]
2020-05-15 14:46 ` Andrew Burgess
2020-05-16 8:12 ` Bernd Edlinger
2020-05-17 17:26 ` Bernd Edlinger
2020-05-20 18:26 ` Andrew Burgess
2020-05-27 13:10 ` Andrew Burgess
2020-06-01 9:05 ` Andrew Burgess
2020-03-08 12:50 ` [PATCHv2 1/2] gdb/testsuite: Add is-stmt support to the DWARF compiler Andrew Burgess
2020-03-08 12:50 ` [PATCHv2 2/2] gdb: Add support for tracking the DWARF line table is-stmt field Andrew Burgess
2020-03-16 20:57 ` Tom Tromey
2020-03-16 22:37 ` Bernd Edlinger
2020-03-17 12:47 ` Tom Tromey
2020-03-17 18:23 ` Tom Tromey
2020-03-17 18:51 ` Bernd Edlinger
2020-03-17 18:56 ` Andrew Burgess
2020-03-17 20:18 ` Tom Tromey
2020-03-17 22:21 ` Andrew Burgess
2020-03-23 17:30 ` [PATCH 0/3] Keep duplicate line table entries Andrew Burgess
2020-03-23 17:30 ` [PATCH 1/3] gdb/testsuite: Add compiler options parameter to function_range helper Andrew Burgess
2020-04-01 18:31 ` Tom Tromey
2020-03-23 17:30 ` [PATCH 2/3] gdb/testsuite: Add support for DW_LNS_set_file to DWARF compiler Andrew Burgess
2020-04-01 18:32 ` Tom Tromey
2020-03-23 17:30 ` [PATCH 3/3] gdb: Don't remove duplicate entries from the line table Andrew Burgess
2020-04-01 18:34 ` Tom Tromey
2020-06-01 13:26 ` [PATCH 2/2] gdb: Add support for tracking the DWARF line table is-stmt field Pedro Alves
2020-02-06 9:01 ` Luis Machado
2020-02-11 15:39 ` Andrew Burgess
2020-02-09 21:07 ` [PATCH] Fix range end handling of inlined subroutines Bernd Edlinger
2020-02-10 21:48 ` Andrew Burgess
2020-02-22 6:39 ` [PATCHv2] " Bernd Edlinger
2020-03-08 14:57 ` [PATCHv3] " Bernd Edlinger
2020-03-11 22:02 ` Andrew Burgess
2020-03-12 18:21 ` Bernd Edlinger
2020-03-12 18:27 ` Christian Biesinger
2020-03-13 8:03 ` Bernd Edlinger
2020-03-17 22:27 ` Andrew Burgess
2020-03-19 1:33 ` Bernd Edlinger
2020-03-21 20:31 ` Bernd Edlinger
2020-03-23 17:53 ` Andrew Burgess
2020-03-23 20:58 ` Bernd Edlinger
2020-06-01 14:28 ` Pedro Alves
2020-03-13 12:47 ` [PATCHv4] " Bernd Edlinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM6PR03MB5170A9649195EB956B21E521E4BD0@AM6PR03MB5170.eurprd03.prod.outlook.com \
--to=bernd.edlinger@hotmail.de \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=oliva@gnu.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox