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

[Dwight Guth via llvm-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220108/4200bfab/attachment-0001.html>