via llvm-dev
2022-Jan-06 22:26 UTC
[llvm-dev] Question regarding correctness of debug information generated by LLC
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
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>