Dwight Guth via llvm-dev
2022-Jan-09 02:01 UTC
[llvm-dev] Question regarding correctness of debug information generated by LLC
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220108/4200bfab/attachment-0001.html>
Anton Korobeynikov via llvm-dev
2022-Jan-09 12:31 UTC
[llvm-dev] Question regarding correctness of debug information generated by LLC
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