From 64dc2d4bd24ff7119c913fff91184414f09b8042 Mon Sep 17 00:00:00 2001 From: Bernd Edlinger Date: Thu, 12 Mar 2020 11:52:34 +0100 Subject: [PATCH] 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. 2020-04-01 Bernd Edlinger * buildsym.c (record_line): Fix undefined behavior and preserve lines at eof. --- gdb/ChangeLog | 5 +++++ gdb/buildsym.c | 34 ++++++++++++++++++---------------- 2 files changed, 23 insertions(+), 16 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index b94acffed66..d5715a8fa00 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2020-04-01 Bernd Edlinger + + * buildsym.c (record_line): Fix undefined behavior and preserve + lines at eof. + 2020-04-01 Bernd Edlinger * buildsym.c (record_line): Fix the resizing condition. diff --git a/gdb/buildsym.c b/gdb/buildsym.c index 2d1e4419d83..46c5bb1477b 100644 --- a/gdb/buildsym.c +++ b/gdb/buildsym.c @@ -705,27 +705,29 @@ buildsym_compunit::record_line (struct subfile *subfile, int line, * 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 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) { - e = subfile->line_vector->item + subfile->line_vector->nitems - 1; - while (subfile->line_vector->nitems > 0 && e->pc == pc) + e = subfile->line_vector->item + subfile->line_vector->nitems; + do { e--; - subfile->line_vector->nitems--; + if (e->pc != pc || e->line == 0) + break; + e->is_stmt = 0; } + while (e > subfile->line_vector->item); } e = subfile->line_vector->item + subfile->line_vector->nitems++; -- 2.30.2