[llvm-dev] Question regarding correctness of debug information generated by LLC

[Anton Korobeynikov via llvm-dev]

Well, noone triaged the bug and assigned the tags here.

On Sun, Jan 9, 2022 at 5:01 AM Dwight Guth via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> It got filed (https://github.com/llvm/llvm-project/issues/52758), but it looks like it's still got the "new issue" tag. There are actually a sizeable number of issues with this tag sitting around that were created since the migration, some of which are definitely not that recent. Have you guys not sorted out a policy for assigning the appropriate tags or people to issues on GitHub yet?
>
> On Thu, Jan 6, 2022, 4:26 PM <paul.robinson at sony.com> wrote:
>>
>> Quick ping to make sure this got filed...
>> Thanks,
>> --0paulr
>>
>> > -----Original Message-----
>> > From: Dwight Guth <dwight.guth at runtimeverification.com>
>> > Sent: Wednesday, December 1, 2021 1:40 PM
>> > To: Robinson, Paul <paul.robinson at sony.com>
>> > Cc: llvm-dev <llvm-dev at lists.llvm.org>
>> > Subject: Re: [llvm-dev] Question regarding correctness of debug
>> > information generated by LLC
>> >
>> > Thanks for the info! This definitely tells me what I need to know. I
>> > will watch for when the Github issues starts allowing bugs to be
>> > reported and file the bug there under "unwind info" as you requested.
>> > As an aside, yes, those three call sites are the three call sites I
>> > expect to see a tail call at.
>> >
>> > Dwight
>> >
>> > On Wed, Dec 1, 2021 at 12:18 PM <paul.robinson at sony.com> wrote:
>> > >
>> > > > $ ~/llvm-project/build/bin/llc -mtriple=x86_64-unknown-linux-gnu -O0
>> > > > debug.ll
>> > >
>> > > Thanks!  That is very helpful.
>> > >
>> > > I see a `jmp` from sender12 to apply_rule_6300, from apply_rule_6300
>> > > to sender4, and from apply_rule_6299 to sender1.  Does that match
>> > > your expectations?  I want to make sure I'm looking at what you're
>> > > looking at.
>> > >
>> > > > > The issue I am having is that it would appear that the debug
>> > > > > information generated for my program indicates a different value for
>> > > > > the $rsp register within the `apply_rule_6870` call frame at each of
>> > > > > the two different call sites of `scanStackRoots`. The value seems
>> > > > > correct at the first call site. However, at the second call site,
>> > the
>> > > > > value appears incorrect and gdb actually cannot find the `main`
>> > stack
>> > > > > frame when it tries to do a backtrace.
>> > >
>> > > Looking at the paths to scanStackRoots, the call sequence and
>> > > my take on where you're having the problem look like this:
>> > >
>> > > main
>> > >   apply_rule_6870
>> > >     sender12
>> > >       scanStackRoots // here, gdb can find apply_rule_6870 fine
>> > >       (jmp) apply_rule_6300
>> > >         (jmp) sender4
>> > >           apply_rule_6299
>> > >             (jmp) sender1
>> > >               apply_rule_6297
>> > >                 koreAllocAndCollect_p1s_blocks
>> > >                   koreCollect
>> > >                     scanStackRoots // here, there's a problem
>> > >
>> > > I'm not as fluent in x86 as perhaps I should be, but I do see
>> > > one thing that makes me wonder if it's entirely correct.  The
>> > > end of apply_rule_6300 looks like this:
>> > >
>> > >     popq %rax
>> > >     .cfi_def_cfa_offset 8 # so far so good
>> > >     addq $48, %rsp
>> > >     jmp sender4
>> > >
>> > > My guess is that the code generator is adjusting the stack
>> > > frame size because sender4 has a much shorter argument list
>> > > than apply_rule_6300, and it's possible that the .cfi directives
>> > > aren't describing that correctly.  Truthfully, I don't know
>> > > enough about .cfi directives to say whether they *can* describe
>> > > that correctly.
>> > >
>> > > You could work around this by making sender4 not be tail-callable,
>> > > perhaps?
>> > >
>> > > This is definitely worth filing a bug; unfortunately, the project
>> > > is transitioning from Bugzilla to github issues, and the transition
>> > > is not complete, which means there is literally no way to file a
>> > > bug at the moment.  When that opens up, though, if you could file it
>> > > (calling it "unwind info" rather than "debug info" to avoid confusion)
>> > > that would be very much appreciated!  I'll leave a note to myself to
>> > > ping this thread when the transition is done.
>> > >
>> > > Thanks,
>> > > --paulr
>> > >
>> >
>> >
>> > --
>> > Dwight Guth
>> > Chief Information Officer
>> > Runtime Verification, Inc.
>> >
>> > Email: dwight.guth at runtimeverification.com
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University