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

Sun Jan 9 18:45:52 PST 2022

We don't have a formal process for that - people do it when they get to it.

On Sun, Jan 9, 2022 at 6:43 PM Dwight Guth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Whose responsibility is it to triage new bugs? Most people submitting
> bugs, myself included, aren't going to have permission to do that, with the
> way it's currently set up on GitHub.
>
> On Sun, Jan 9, 2022, 6:31 AM Anton Korobeynikov <anton at korobeynikov.info>
> wrote:
>
>> Well, noone triaged the bug and assigned the tags here.
>>
>> On Sun, Jan 9, 2022 at 5:01 AM Dwight Guth via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >
>> > 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
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> --
>> With best regards, Anton Korobeynikov
>> Department of Statistical Modelling, Saint Petersburg State University
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220109/ed77b58c/attachment.html>