Hi Bernd, I messed it up, sorry. Here's the line table information again. Regards, Luis On 4/4/20 1:06 PM, Bernd Edlinger wrote: > Hi Luis, > > the attachments seem to be twice the lo-cold.c linetables, > I wonder if the hi-cold.c linetable are missing, to somehow > make the picture complete? > > Thanks > Bernd. > > On 4/4/20 3:56 PM, Luis Machado wrote: >> Hi Bernd, >> >> On 4/4/20 4:06 AM, Bernd Edlinger wrote: >>> On 4/4/20 6:21 AM, Bernd Edlinger wrote: >>>> >>>> >>>> On 4/4/20 12:53 AM, Luis Machado wrote: >>>>> Hi, >>>>> >>>>> This seems to have caused a few regressions for aarch64-linux. I'm seeing the following: >>>>> >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into foo from main >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into bar from foo >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of bar to foo >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into foo_cold from foo >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into baz from foo_cold >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of baz to foo_cold >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of foo_cold to foo >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of foo to main >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into foo from main >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into bar from foo >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of bar to foo >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into foo_cold from foo >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into baz from foo_cold >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of baz to foo_cold >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of foo_cold to foo >>>>> FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of foo to main >>>>> >>>>> git bisect pointed at this commit: >>>>> >>> >>> Louis, >>> >>> So, I cannot do much, to debug aarch64 here. >>> I would however like to know what the output of the test result is, >>> when it fails, that is where the step does stop when it is not where it should. >> >> On a quick look, we're stopping at the wrong location during an attempt to break at "main". I think things just derail from there. >> >> For now, please find attached a couple logs, one without regressions and one with the failing tests. >> >> Also, I've attached the decoded/raw line information for both binaries from this testcase. I can play with it further to get more information if you need. Hopefully this data is useful for now. >> >> Let me know otherwise. >> >>> >>> And how the line table looks in the test case when it is compiled on aarch64, >>> btw. which gcc version do you use? >> >> The compiler version is gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1). >> >>> >>> Thanks >>> Bernd. >>> >>>> >>>> Oh, dear. >>>> >>>> Andrew, please watch out, >>>> >>>> your other patch is also about to >>>> change something in this area. >>>> >>>> I tested on x86_64 where everything looked good, >>>> (at least for me, but sime test cases are always faling >>>> or are unstable ...) >>>> >>>> It could be that your patch >>>> >>>> PATCH 2/2] gdb: Preserve is-stmt lines when switch between files >>>> >>>> I just saw in my inbox is also trying to address the same issue. >>>> >>>> I was not aware that you were working on the same issue. >>>> >>>> >>>> Thanks >>>> Bernd. >>>> >>>>> --- >>>>> >>>>> 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. >>>>> >>>>>      2020-04-01  Bernd Edlinger  >>>>> >>>>>              * buildsym.c (record_line): Fix undefined behavior and preserve lines at eof. >>>>> >>>>> --- >>>>> >>>>> What i see in the log is stepping through lines not working as expected. >>>>> >>>>> >>>>> On 3/27/20 12:50 AM, Bernd Edlinger wrote: >>>>>> Additionally do not completely remove symbols >>>>>> at the same PC than the end marker, instead >>>>>> make them non-is-stmt breakpoints. >>>>>> >>>>>> 2020-03-27  Bernd Edlinger  >>>>>>      * buildsym.c (record_line): Fix undefined behavior and preserve >>>>>>      lines at eof. >>>>>> --- >>>>>>    gdb/buildsym.c | 34 ++++++++++++++++++---------------- >>>>>>    1 file changed, 18 insertions(+), 16 deletions(-) >>>>>> >>>>>> diff --git a/gdb/buildsym.c b/gdb/buildsym.c >>>>>> index 2d1e441..46c5bb1 100644 >>>>>> --- a/gdb/buildsym.c >>>>>> +++ b/gdb/buildsym.c >>>>>> @@ -705,27 +705,29 @@ 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 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++; >>>>>>