<div dir="ltr">We don't have a formal process for that - people do it when they get to it.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 9, 2022 at 6:43 PM Dwight Guth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 9, 2022, 6:31 AM Anton Korobeynikov <<a href="mailto:anton@korobeynikov.info" target="_blank">anton@korobeynikov.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Well, noone triaged the bug and assigned the tags here.<br>
<br>
On Sun, Jan 9, 2022 at 5:01 AM Dwight Guth via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> It got filed (<a href="https://github.com/llvm/llvm-project/issues/52758" rel="noreferrer noreferrer" target="_blank">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?<br>
><br>
> On Thu, Jan 6, 2022, 4:26 PM <<a href="mailto:paul.robinson@sony.com" rel="noreferrer" target="_blank">paul.robinson@sony.com</a>> wrote:<br>
>><br>
>> 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" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">paul.robinson@sony.com</a>><br>
>> > Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">dwight.guth@runtimeverification.com</a><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
<br>
<br>
-- <br>
With best regards, Anton Korobeynikov<br>
Department of Statistical Modelling, Saint Petersburg State University<br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>