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

[via llvm-dev]

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