- User Since
- Jun 4 2018, 3:35 AM (19 w, 6 d)
Fri, Oct 19
Thu, Oct 18
Wed, Oct 17
Tue, Oct 16
Yes, it's simpler to move it to the CPlusPlusLanguage::MethodName (or CPlusPlusNameParser?) I think. The only question left is how to differentiate MSVC demangled names from others? May be it would be ok to treat name as an MSVC name if it contains a grave accent? Because we probably already can parse MSVC names without grave accents with CPlusPlusLanguage::MethodName.
Yes, I mean exactly the same case. For sequences like you've written yes, the unwind should work, but there must be some problems with saved registers. x86AssemblyInspectionEngine doesn't handle instructions like and %-8, %esp, so the register save would work only if this instruction hadn't changed the esp value (e.g. esp was already aligned). Otherwise, if esp was changed, the offset to CFA in RegisterLocation of some register will be invalid, because it will not take the alignment into account.
Mon, Oct 15
I just have tried to patch CPlusPlusNameParser in the way to support MSVC demangled names, but there is a problem. CPlusPlusNameParser splits an incoming name in tokens with clang::Lexer. I've lexed the next name:
The lexer treats the first character (a grave accent) as an unknown token, and it's ok for our purposes. Then it sees an identifier (anonymous), a keyword (namespace), and it's ok too. But the problem is with the last part of the string. The lexer sees an apostrophe and supposes that it's a character constant, it looks for a closing apostrophe, don't find it and treats all the line ending ('::foo) as a single unknown token.
Fri, Oct 12
Thu, Oct 11
LGTM after D53094 will be done!
As for aligned stack cross-platform problems, I mean also problems with stack unwinding. They seem to appear on non-Windows too. It's because x86AssemblyInspectionEngine doesn't support stack alignment now. I've made some changes locally to fix it, but they are still raw to publish. The main idea is to save one more frame address (along with CFA) for every row of an unwind plan (I've called this AFA - aligned frame address), and add an analysis for and esp, ... etc. to x86AssemblyInspectionEngine. What do you think about a such approach?
Thanks a lot for so detailed answer, it helps!
Wed, Oct 10
Tue, Oct 9
It's great! Especially thanks for comments!
Mon, Oct 8
Unfortunately, I'm not looking at this exactly now due to some work with a higher priority. But I'm keeping it in mind.
Yes, you are right, it's more simple! I've updated the patch.
Sun, Sep 30
I've tried to parse with it a name like
and it can't parse it correctly. May be it just can't parse MSVC demangled names?
Ok, I'll look at this, thank you!
Fri, Sep 28
Yes, you are right, both clang and MinGW align both S0 and S1 (x86 MinGW aligns the stack on 16 byte in the main function, so foo0 and foo1 become identical). I've updated the diff, thanks.
Thanks for explanations!
Yes, sure! Thanks all!
Thu, Sep 27
I didn't know about such a priority, thanks... But in this case lldb-server also must be able to allocate, read and write in a debuggee. Doesn't it use the process plugin for that? Or somehow duplicates this functionality?
Wed, Sep 26
I just have extracted the test cases in a separate test and have specified -m32 key, so the test can run also on 64-bit machines.
Tue, Sep 25
Ok, I'll look into that, thanks!
Sep 14 2018
That would be great, thank you!
Sep 13 2018
Apply recommended fixes.
Sep 12 2018
Sep 11 2018
Sep 10 2018
Sorry, I've missed this. I'll fix it tomorrow. Thank you!
Sep 7 2018
If I understand correctly, you have shown the case that is not relating to this patch? This patch is about returning structures, not about passing them by value. I think that it would be better to create separate patch for fixing that?
Sep 5 2018
- Fix a typo bug in AddRecordMethods (use continue instead of break);
- Do not search function declarations by name during getting of a declaration for a symbol, it may lead to ambiguity.
Sep 3 2018
Added the dumping AST ability to lldb-test; adding a corresponding test for the patch.
Aug 31 2018
Yes, I'll try to implement that, thanks for the idea!
Thanks :) Let's also wait for what Aaron will say? Because the patch is big enough.
Drop a scope part of a class member function name.
Aug 30 2018
Can you review this, please?
Aug 29 2018
Aug 28 2018
Yes, I meant 32-bit of course.
Aug 27 2018
If I understand right, the fail becomes not because of the sret argument is not the same, but because in the C calling convention sret argument is cleaned up by a callee, while a non-sret pointer to a struct is cleaned up by a caller. Or maybe I am missing something?..
This patch fails in the @t22_non_sret_to_sret X86 case (as we can see, a stack becomes corrupted after the patch in this case). Thanks to @efriedma for pointing that. So I just abandon the revision. Thanks all for your help!
Fixed with rL340735, thanks!