Page MenuHomePhabricator

jarin (Jaroslav Sevcik)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 27 2019, 4:27 AM (20 w, 3 d)

Recent Activity

Wed, Feb 12

jarin added a comment to D74398: [lldb-server] jThreadsInfo returns stack memory.

Thank you for the feedback! I am a bit busy with other things ATM, but I should be able to get back to this next week.

Wed, Feb 12, 11:30 PM · Restricted Project

Tue, Feb 11

jarin created D74398: [lldb-server] jThreadsInfo returns stack memory.
Tue, Feb 11, 5:34 AM · Restricted Project

Fri, Feb 7

jarin added inline comments to D74217: Add target.xml support for qXfer request..
Fri, Feb 7, 6:47 AM · Restricted Project

Tue, Jan 28

jarin added a comment to rGd8de349951c2: Revert "[lldb/DWARF] Only match mangled name in full-name function lookup (with….

Right, this is pretty clearly my commit. This is a pretty crazy week here, so I am not quite sure when I have time to investigate.

Tue, Jan 28, 7:27 AM

Mon, Jan 27

jarin added a comment to D73191: Only match mangled name in full-name function lookup (with accelerators).

(I mean, if there is a real benefit to having some queries return only non-methods, then we can certainly do something like that as well, but that should be handled differently -- either we can create a new query mode, or change the behavior (and name?) of eFunctionNameTypeFull across the board).

Mon, Jan 27, 2:06 AM · Restricted Project
jarin added a comment to D73191: Only match mangled name in full-name function lookup (with accelerators).

Pavel, could you take another look, please?

Mon, Jan 27, 12:38 AM · Restricted Project
jarin updated the diff for D73191: Only match mangled name in full-name function lookup (with accelerators).

Only matching the mangled name now.

Mon, Jan 27, 12:38 AM · Restricted Project
jarin added inline comments to D73191: Only match mangled name in full-name function lookup (with accelerators).
Mon, Jan 27, 12:02 AM · Restricted Project

Fri, Jan 24

jarin added inline comments to D73191: Only match mangled name in full-name function lookup (with accelerators).
Fri, Jan 24, 6:22 AM · Restricted Project
jarin set the repository for D73191: Only match mangled name in full-name function lookup (with accelerators) to rG LLVM Github Monorepo.
Fri, Jan 24, 3:49 AM · Restricted Project
jarin added a comment to D73191: Only match mangled name in full-name function lookup (with accelerators).

Pavel, does the latest patch address (and test) what you were worried about?

Fri, Jan 24, 3:31 AM · Restricted Project
jarin updated the diff for D73191: Only match mangled name in full-name function lookup (with accelerators).

Updated to include all methods/non-methods with matching mangled name.

Fri, Jan 24, 3:31 AM · Restricted Project

Thu, Jan 23

jarin abandoned D69843: Expression eval lookup - prune methods without parsing.
Thu, Jan 23, 2:09 AM · Restricted Project
jarin added a comment to D69309: Support template instantiation in the expression evaluator.

FWIW, the Sony debugger throws away the <type> part of the DW_AT_name and reconstructs it from the template_parameter children. The presence of typedefs and/or enums can make the <type> text inconsistent, especially across enums. Our debugger reconstructs the type-parameters because it's more consistent that way.

Thu, Jan 23, 2:03 AM · Restricted Project

Wed, Jan 22

jarin created D73191: Only match mangled name in full-name function lookup (with accelerators).
Wed, Jan 22, 6:53 AM · Restricted Project
jarin added a comment to D73166: [ASTImporter] Properly delete decls from SavedImportPaths.

Thanks for the review!

Wed, Jan 22, 6:05 AM · Restricted Project
jarin created D73166: [ASTImporter] Properly delete decls from SavedImportPaths.
Wed, Jan 22, 2:36 AM · Restricted Project

Tue, Jan 21

jarin updated the diff for D69933: [ASTImporter] Limit imports of structs.

I changed the diff so that it does not touch Clang's AST importer, instead it patches LLDB's wrapper of the AST importer.

Tue, Jan 21, 12:40 AM · Restricted Project, Restricted Project

Jan 10 2020

jarin added a comment to D72133: Data formatters: Look through array element typedefs.

Raphael, could you possibly land the patch for me? Thanks!

Jan 10 2020, 1:59 AM · Restricted Project

Jan 7 2020

jarin added a comment to D72133: Data formatters: Look through array element typedefs.

So as long as the following are true from this patch I am ok:

  • if I ask for the array element type of "str" in the test that was added, it should return "MCHAR". We shouldn't be removing any typedefs from the type. The user can call SBType::GetCanonicalType() if they need to (or equivalent with internal APIs)
Jan 7 2020, 4:28 AM · Restricted Project
jarin added inline comments to D72133: Data formatters: Look through array element typedefs.
Jan 7 2020, 1:50 AM · Restricted Project

Jan 3 2020

jarin added a comment to D72133: Data formatters: Look through array element typedefs.

Actually, there is something unusually flaky in my current checkout, so you might be right that not canonicalizing is harmless. It still makes more sense to land that separately.

Jan 3 2020, 8:21 AM · Restricted Project
jarin added a comment to D72133: Data formatters: Look through array element typedefs.

Also do you need someone to commit this for you?

Jan 3 2020, 5:01 AM · Restricted Project
jarin added a comment to D72133: Data formatters: Look through array element typedefs.

I have addressed the comments, thanks for the quick review.

Jan 3 2020, 5:01 AM · Restricted Project
jarin updated the diff for D72133: Data formatters: Look through array element typedefs.
Jan 3 2020, 4:42 AM · Restricted Project
jarin created D72133: Data formatters: Look through array element typedefs.
Jan 3 2020, 2:36 AM · Restricted Project

Dec 17 2019

jarin added a comment to D69309: Support template instantiation in the expression evaluator.

What Fred proposes makes a lot of sense to me, although the lookup of instantiations might be slow because there would be no accelerator for that (but we could build one).

Do we ever lookup instantiations through this API? Seems pretty fragile, due to all the template brackets and all kinds of whitespace one could insert between them...

Dec 17 2019, 2:04 AM · Restricted Project
jarin added a comment to D69309: Support template instantiation in the expression evaluator.

Basically, today the debug info will describe an entity named "Foo<int>". The accelerator tables all reference this name. So when Clang asks us if we know "Foo" (which is what happens when instantiating), we fail to find the right instantiations. The consensus of the above discussion was that we should change the debug info to have "Foo" as the name of any instantiation, with a child DIE describing the template arguments. Just doing this in the compiler causes test failures in LLDB, so there's some work to do in LLDB to support this.

Frederic, you say that "doing this in the compiler causes test failures in LLDB", which implies you have tried adding the template in the compiler. Do you have that compiler patch lying around so that we could have a look at what can be done on the lldb side?

I agree that a good long term fix is to have "Foo" as an entity in DWARF, although for backwards compatibility it might be better if the "Foo" template just contained references to the instantiations rather than having them as children.

I am afraid you're overestimating the scope of that idea. I *think* that Fred was referring to simply changing the string that gets put into the DW_AT_name field of the /instantation/ (and, by extension, the accelerator table). The debug info would still describe instantiations only.

I don't believe anyone here was proposing to have DWARF actually describe templates themselves -- that might be possible, but you'd have to get pretty creative with dwarf attributes (and convince a bunch of people that this is actually a good idea).

Dec 17 2019, 1:45 AM · Restricted Project

Dec 16 2019

jarin added a comment to D69309: Support template instantiation in the expression evaluator.

Basically, today the debug info will describe an entity named "Foo<int>". The accelerator tables all reference this name. So when Clang asks us if we know "Foo" (which is what happens when instantiating), we fail to find the right instantiations. The consensus of the above discussion was that we should change the debug info to have "Foo" as the name of any instantiation, with a child DIE describing the template arguments. Just doing this in the compiler causes test failures in LLDB, so there's some work to do in LLDB to support this.

Dec 16 2019, 11:12 PM · Restricted Project
jarin added a comment to D69309: Support template instantiation in the expression evaluator.

https://reviews.llvm.org/D41416 could be relevant. I am not an expert but I think when reading the DWARF you could only register 'lazy' specializations which will be imported only when really required.

Dec 16 2019, 11:03 PM · Restricted Project

Nov 21 2019

jarin added a comment to D69309: Support template instantiation in the expression evaluator.

Sorry that I haven't reviewed the patch, but there's something I'd like to point out before anyone invests a lot of time into plugin holes in our current template support code.

It would be great to fix the way templates are represented, because currently the debug info doesn't allow us to answer Clang's requests correctly. There is the beginning of a discussion here: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180507/040689.html

Basically, today the debug info will describe an entity named "Foo<int>". The accelerator tables all reference this name. So when Clang asks us if we know "Foo" (which is what happens when instantiating), we fail to find the right instantiations. The consensus of the above discussion was that we should change the debug info to have "Foo" as the name of any instantiation, with a child DIE describing the template arguments. Just doing this in the compiler causes test failures in LLDB, so there's some work to do in LLDB to support this.

Nov 21 2019, 12:56 AM · Restricted Project

Nov 19 2019

jarin updated the diff for D69309: Support template instantiation in the expression evaluator.

This update introduces a callback from clang for template specialization. The callback allows lldb to construct instantiations on demand, rather than having to create the instantiation eagerly.

Nov 19 2019, 7:26 AM · Restricted Project

Nov 7 2019

jarin created D69933: [ASTImporter] Limit imports of structs.
Nov 7 2019, 12:13 AM · Restricted Project, Restricted Project
jarin updated the summary of D69933: [ASTImporter] Limit imports of structs.
Nov 7 2019, 12:13 AM · Restricted Project, Restricted Project

Nov 6 2019

jarin added a comment to D69843: Expression eval lookup - prune methods without parsing.

Thanks for the feedback! We will experiment with filtering in GetFunctions sometime next week.

Nov 6 2019, 4:51 AM · Restricted Project

Nov 5 2019

jarin created D69843: Expression eval lookup - prune methods without parsing.
Nov 5 2019, 6:46 AM · Restricted Project

Oct 22 2019

jarin created D69309: Support template instantiation in the expression evaluator.
Oct 22 2019, 8:55 AM · Restricted Project

Oct 10 2019

jarin added a comment to D68454: Fix the unwinding plan augmentation from x86 assembly.

Thank you for the review! Could you also possibly commit the change for me?

Oct 10 2019, 1:34 AM · Restricted Project

Oct 9 2019

jarin added a reviewer for D68454: Fix the unwinding plan augmentation from x86 assembly: labath.

Pavel, could you possibly take a look? It looks like Jason is busy with something else...

Oct 9 2019, 2:38 AM · Restricted Project

Oct 4 2019

jarin updated the summary of D68454: Fix the unwinding plan augmentation from x86 assembly.
Oct 4 2019, 5:14 AM · Restricted Project
jarin created D68454: Fix the unwinding plan augmentation from x86 assembly.
Oct 4 2019, 3:45 AM · Restricted Project

Oct 2 2019

jarin added inline comments to D68278: Fix evaluation of nested classes with parent from other CU.
Oct 2 2019, 5:11 AM · Restricted Project, Restricted Project
jarin updated the diff for D68278: Fix evaluation of nested classes with parent from other CU.

Fixed the nits, thanks for the careful review!

Oct 2 2019, 5:11 AM · Restricted Project, Restricted Project

Oct 1 2019

jarin updated the diff for D68278: Fix evaluation of nested classes with parent from other CU.

Fixed a typo.

Oct 1 2019, 10:55 PM · Restricted Project, Restricted Project
jarin updated the diff for D68278: Fix evaluation of nested classes with parent from other CU.

I have added some comments to the test (I hope it is not too overboard), removed the LEVEL stuff from the Makefile and fixed the formatting.

Oct 1 2019, 10:51 PM · Restricted Project, Restricted Project
jarin added a reviewer for D68278: Fix evaluation of nested classes with parent from other CU: labath.
Oct 1 2019, 8:39 AM · Restricted Project, Restricted Project
jarin created D68278: Fix evaluation of nested classes with parent from other CU.
Oct 1 2019, 8:37 AM · Restricted Project, Restricted Project