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

[via llvm-dev]

> $ ~/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