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

Hi,

Sorry for the late reply, this is my first day back after a long
holiday weekend. The gist of your reply seems to be that it's a little
hard to determine what might be going wrong because there is no debug
information in the IR I shared. There was debug information in my
original IR, it's true, but I was still able to reproduce the issue I
was encountering whether or not the debug information was present, so
it got removed during the process of minimization. The reason I
considered this normal is because LLC still generates CFI/CFA
directives in the assembly even when no debug information is present
in the IR, and my understanding was that this was the information that
the debugger used in order to unwind the stack.

If my understanding is incorrect, and the debugger actually relies on
information provided via the IR debug metadata in order to unwind the
stack, it's possible that the issue I encountered might simply be as a
result of my not having provided the correct metadata in the IR, since
the code that generated that metadata was something I wrote myself. If
that is the case, can you help me understand what metadata in the IR
might be used by the debugger in order to unwind the stack, so that I
can test some more on my end before getting back to you? I don't want
to waste your time if it turns out that I simply was providing the
wrong IR to LLC.

Thanks,
Dwight

On Wed, Nov 24, 2021 at 4:48 PM <paul.robinson at sony.com>
wrote:
>
> > 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
>

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

Email: dwight.guth at runtimeverification.com

> Sorry for the late reply, this is my first day back after a long
> holiday weekend. The gist of your reply seems to be that it's a little
> hard to determine what might be going wrong because there is no debug
> information in the IR I shared. There was debug information in my
> original IR, it's true, but I was still able to reproduce the issue I
> was encountering whether or not the debug information was present, so
> it got removed during the process of minimization. The reason I
> considered this normal is because LLC still generates CFI/CFA
> directives in the assembly even when no debug information is present
> in the IR, and my understanding was that this was the information that
> the debugger used in order to unwind the stack.
Ah, okay, I misunderstood.  The CFI/CFA directives are not what I
normally think of as debug information, although of course they are
used to build the unwind tables in the .debug_frame section (or in
the .eh_frame section, if you're not producing debug info).

I suspect you are not targeting an X86-family architecture?  I was
not able to persuade llc for x86_64 Ubuntu to emit the tail calls
that you describe.  Could you provide a complete llc command line
(including triple) that demonstrates the problem for you?

Thanks,
--paulr