From a25198bba24b3443d2e3d72300c3308ccc742325 Mon Sep 17 00:00:00 2001 From: Bernd Edlinger Date: Thu, 9 Apr 2020 03:18:23 +0200 Subject: Partially revert my UB fix in record_line This reverts the following commit partially: commit 64dc2d4bd24ff7119c913fff91184414f09b8042 Author: Bernd Edlinger Date: Thu Mar 12 11:52:34 2020 +0100 Fix an undefined behavior in record_line Additionally do not completely remove symbols at the same PC than the end marker, instead make them non-is-stmt breakpoints. We keep the undefined behavoir fix, but have to restore the original behavior regarding deletion of the line entries. 2020-04-09 Bernd Edlinger revert partially: 2020-04-01 Bernd Edlinger * buildsym.c (record_line): Fix undefined behavior and preserve lines at eof. --- gdb/ChangeLog | 8 ++++++++ gdb/buildsym.c | 37 ++++++++++++++++++------------------- 2 files changed, 26 insertions(+), 19 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 56dd4b3..e9579b1 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,11 @@ +2020-04-09 Bernd Edlinger + + revert partially: + 2020-04-01 Bernd Edlinger + + * buildsym.c (record_line): Fix undefined behavior and preserve + lines at eof. + 2020-04-09 Kamil Rytarowski * auxv.h (svr4_auxv_parse): New. diff --git a/gdb/buildsym.c b/gdb/buildsym.c index fe07103..c08c476 100644 --- a/gdb/buildsym.c +++ b/gdb/buildsym.c @@ -691,29 +691,28 @@ buildsym_compunit::record_line (struct subfile *subfile, int line, * sizeof (struct linetable_entry)))); } - /* The end of sequence marker is special. We need to reset the - is_stmt flag on 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. A similar problem appears if a label is at the - same address where an inline function ends we cannot reliably tell - if this is considered part of the inline function or the calling - program or even the next inline function, so stack traces may - give surprising results. Expect gdb.cp/step-and-next-inline.exp - to fail if these lines are not modified here. */ - if (line == 0 && subfile->line_vector->nitems > 0) + /* 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. */ + if (line == 0) { - e = subfile->line_vector->item + subfile->line_vector->nitems; - do + while (subfile->line_vector->nitems > 0) { - e--; - if (e->pc != pc || e->line == 0) + e = subfile->line_vector->item + subfile->line_vector->nitems - 1; + if (e->pc != pc) break; - e->is_stmt = 0; + subfile->line_vector->nitems--; } - while (e > subfile->line_vector->item); } e = subfile->line_vector->item + subfile->line_vector->nitems++; -- cgit v1.1