<div dir="auto">It got filed (<a href="https://github.com/llvm/llvm-project/issues/52758">https://github.com/llvm/llvm-project/issues/52758</a>), 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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 6, 2022, 4:26 PM <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quick ping to make sure this got filed...<br>
Thanks,<br>
--0paulr<br>
<br>
> -----Original Message-----<br>
> From: Dwight Guth <<a href="mailto:dwight.guth@runtimeverification.com" target="_blank" rel="noreferrer">dwight.guth@runtimeverification.com</a>><br>
> Sent: Wednesday, December 1, 2021 1:40 PM<br>
> To: Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank" rel="noreferrer">paul.robinson@sony.com</a>><br>
> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>><br>
> Subject: Re: [llvm-dev] Question regarding correctness of debug<br>
> information generated by LLC<br>
> <br>
> Thanks for the info! This definitely tells me what I need to know. I<br>
> will watch for when the Github issues starts allowing bugs to be<br>
> reported and file the bug there under "unwind info" as you requested.<br>
> As an aside, yes, those three call sites are the three call sites I<br>
> expect to see a tail call at.<br>
> <br>
> Dwight<br>
> <br>
> On Wed, Dec 1, 2021 at 12:18 PM <<a href="mailto:paul.robinson@sony.com" target="_blank" rel="noreferrer">paul.robinson@sony.com</a>> wrote:<br>
> ><br>
> > > $ ~/llvm-project/build/bin/llc -mtriple=x86_64-unknown-linux-gnu -O0<br>
> > > debug.ll<br>
> ><br>
> > Thanks! That is very helpful.<br>
> ><br>
> > I see a `jmp` from sender12 to apply_rule_6300, from apply_rule_6300<br>
> > to sender4, and from apply_rule_6299 to sender1. Does that match<br>
> > your expectations? I want to make sure I'm looking at what you're<br>
> > looking at.<br>
> ><br>
> > > > The issue I am having is that it would appear that the debug<br>
> > > > information generated for my program indicates a different value for<br>
> > > > the $rsp register within the `apply_rule_6870` call frame at each of<br>
> > > > the two different call sites of `scanStackRoots`. The value seems<br>
> > > > correct at the first call site. However, at the second call site,<br>
> the<br>
> > > > value appears incorrect and gdb actually cannot find the `main`<br>
> stack<br>
> > > > frame when it tries to do a backtrace.<br>
> ><br>
> > Looking at the paths to scanStackRoots, the call sequence and<br>
> > my take on where you're having the problem look like this:<br>
> ><br>
> > main<br>
> > apply_rule_6870<br>
> > sender12<br>
> > scanStackRoots // here, gdb can find apply_rule_6870 fine<br>
> > (jmp) apply_rule_6300<br>
> > (jmp) sender4<br>
> > apply_rule_6299<br>
> > (jmp) sender1<br>
> > apply_rule_6297<br>
> > koreAllocAndCollect_p1s_blocks<br>
> > koreCollect<br>
> > scanStackRoots // here, there's a problem<br>
> ><br>
> > I'm not as fluent in x86 as perhaps I should be, but I do see<br>
> > one thing that makes me wonder if it's entirely correct. The<br>
> > end of apply_rule_6300 looks like this:<br>
> ><br>
> > popq %rax<br>
> > .cfi_def_cfa_offset 8 # so far so good<br>
> > addq $48, %rsp<br>
> > jmp sender4<br>
> ><br>
> > My guess is that the code generator is adjusting the stack<br>
> > frame size because sender4 has a much shorter argument list<br>
> > than apply_rule_6300, and it's possible that the .cfi directives<br>
> > aren't describing that correctly. Truthfully, I don't know<br>
> > enough about .cfi directives to say whether they *can* describe<br>
> > that correctly.<br>
> ><br>
> > You could work around this by making sender4 not be tail-callable,<br>
> > perhaps?<br>
> ><br>
> > This is definitely worth filing a bug; unfortunately, the project<br>
> > is transitioning from Bugzilla to github issues, and the transition<br>
> > is not complete, which means there is literally no way to file a<br>
> > bug at the moment. When that opens up, though, if you could file it<br>
> > (calling it "unwind info" rather than "debug info" to avoid confusion)<br>
> > that would be very much appreciated! I'll leave a note to myself to<br>
> > ping this thread when the transition is done.<br>
> ><br>
> > Thanks,<br>
> > --paulr<br>
> ><br>
> <br>
> <br>
> --<br>
> Dwight Guth<br>
> Chief Information Officer<br>
> Runtime Verification, Inc.<br>
> <br>
> Email: <a href="mailto:dwight.guth@runtimeverification.com" target="_blank" rel="noreferrer">dwight.guth@runtimeverification.com</a><br>
</blockquote></div>