llvm dev - Nov 2021 - Question regarding correctness of debug information generated by LLC

I have a program I am developing that is exhibiting some undesirable
behavior, and I'm not entirely sure whether this constitutes a bug in
LLVM or not, so I wanted to ask.

I have managed to construct a minimized program that exhibits the same
issue I am dealing with; it can be found at
https://gist.github.com/dwightguth/75988aa998471a83d5dd198fac5ef02a

For a little background of what I am working on, I am developing a
garbage collector for a language that compiles down to LLVM IR, making
use of the garbage collection safepoints infrastructure in LLVM in
order to find references to heap objects on the stack. The language is
a functional language that relies on tail call optimizations to avoid
unbounded stack growth, so it makes use of the tailcc calling
convention (which is in turn based on the older fastcc calling
convention with -tailcallopt passed to llc).

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.

This is actually a matter of correctness for me because I use
libunwind to find the stack pointer at each call frame in order to be
able to interpret the stack map generated by the LLVM GC safepoints.
When run in the full example, the code sees an incorrect address for
one or more local variables, attempts to read memory incorrectly, and
eventually segfaults as a result.

My question is: is this a bug in LLVM? My gut feeling is yes, because
the compiler ought to generate the necessary cfi declarations in order
to be able to correctly unwind the stack. But I'm not entirely sure
because I'm not completely clear on what guarantees LLVM provides with
respect to debug information on non-standard calling conventions.

So, my question to the list is, should I report this program as a bug
in LLVM? Or do I need to find another means by which to reconstruct
the canonical frame address when looking for garbage collection roots
on the stack. And if so, what means might be available?

Thanks,

-- 
Dwight Guth
Chief Information Officer
Runtime Verification, Inc.

Email: dwight.guth at runtimeverification.com

> I have a program I am developing that is exhibiting some undesirable
> behavior, and I'm not entirely sure whether this constitutes a bug in
> LLVM or not, so I wanted to ask.
> 
> I have managed to construct a minimized program that exhibits the same
> issue I am dealing with; it can be found at
> https://gist.github.com/dwightguth/75988aa998471a83d5dd198fac5ef02a
> 
> For a little background of what I am working on, I am developing a
> garbage collector for a language that compiles down to LLVM IR, making
> use of the garbage collection safepoints infrastructure in LLVM in
> order to find references to heap objects on the stack. The language is
> a functional language that relies on tail call optimizations to avoid
> unbounded stack growth, so it makes use of the tailcc calling
> convention (which is in turn based on the older fastcc calling
> convention with -tailcallopt passed to llc).
> 
> 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.
Hi Dwight,

I looked at your gist, and the IR has no debug info annotations, which
means your front end is not generating debug info... where is the
debug info coming from?  Or maybe you inadvertently generated the gist
without debug info?
> This is actually a matter of correctness for me because I use
> libunwind to find the stack pointer at each call frame in order to be
> able to interpret the stack map generated by the LLVM GC safepoints.
> When run in the full example, the code sees an incorrect address for
> one or more local variables, attempts to read memory incorrectly, and
> eventually segfaults as a result.
> 
> My question is: is this a bug in LLVM? My gut feeling is yes, because
> the compiler ought to generate the necessary cfi declarations in order
> to be able to correctly unwind the stack. But I'm not entirely sure
> because I'm not completely clear on what guarantees LLVM provides with
> respect to debug information on non-standard calling conventions.
Tail calls don't seem that far out of the ordinary; but without seeing
how you're generating debug info, it's a little hard to be helpful.
It might well be a bug in what LLVM is doing, but it might not, and
we'd need more complete instructions on how to reproduce the problem
before we can answer that fundamental question.
> So, my question to the list is, should I report this program as a bug
> in LLVM?
Right now is actually not a great time to report a new bug, because we
are transitioning from Bugzilla to github issues.  Let's see if we can
solve this via email (of course many in the U.S. are about to be on
holiday for a few days) and if not, we're hoping to be up and running
on github early next week.

Thanks,
--paulr