jarin added a comment. In D110571#3033481 <https://reviews.llvm.org/D110571#3033481>, @labath wrote:
> In D110571#3033282 <https://reviews.llvm.org/D110571#3033282>, @jarin wrote: > >> In D110571#3033078 <https://reviews.llvm.org/D110571#3033078>, @labath wrote: >> >>> Here's one more question. AIUI, lldb relies on the order of formal >>> parameter declarations in dwarf to establish the the function signature >>> (dwarf doesn't leave us much choice. This then affects how the function is >>> printed in the backtrace, for instance. What will be the resulting order of >>> arguments for these functions? I'm wondering if we don't need a two-pass >>> algorithm, which first parses the arguments in the function declaration (to >>> establish their order), and then do another pass over the concrete instance >>> to fill in the missing information. (I'm sorry if you're doing this >>> already, but I'm still too scared of the code to figure it out myself :P ). >> >> The code already does the merging. For DW_TAG_inlined_subroutine, it first >> collects the formal_parameter list from from its abstract_origin and then it >> will parse/insert all the missing one while parsing the concrete instance. >> This will preserve the order of formal parameters. Now that I think about >> this, it might add some formal parameters after local variables, but I hope >> this is not a real problem for LLDB. If this is a problem, we could perhaps >> flush the abstract formal parameters whenever we encounter DW_TAG_variable. > > Cool. I see you're way ahead of me. If you're not careful you may end up as > the dwarf maintainer. :P Pavel, it is unfortunately really the case that with the current patch, the parameters might get interleaved with locals: #include <stdio.h> void f(int used, int unused) { int local = 1 + used; printf("Hello %i", local); // break here } int main() { f(4, 3); return 0; } Here is the LLDB session: $ bin/lldb a.out ... (lldb) b f Breakpoint 1: 2 locations. (lldb) r ... * thread #1, name = 'a.out', stop reason = breakpoint 1.2 frame #0: 0x0000000000401151 a.out`main [inlined] f(used=4, unused=<unavailable>) at a.cc:5:3 (lldb) frame var (int) used = 4 (int) local = 5 <--- HERE, a local variables got between the parameters because we append unused parameters at the end. (int) unused = <no location, value may have been optimized out> Let me try to rewrite the code so that the trailing unused parameters are inserted after the last concrete parameter (or at the beginning of variable list if there are no concrete parameters). Let me know if you think it is unnecessary. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110571/new/ https://reviews.llvm.org/D110571 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
