Page MenuHomePhabricator
Feed Advanced Search

Thu, Apr 8

clayborg accepted D100076: [lld-macho] Support -add_ast_path.

Thanks for checking. As long as ld64 allows multiple, I am good.

Thu, Apr 8, 10:56 AM · Restricted Project, Restricted Project

Wed, Apr 7

clayborg added a comment to D100076: [lld-macho] Support -add_ast_path.

The N_AST symbol is used to specify a file on disk that contains the one and only Swift AST blob. This blob of data will be given back to the Swift compiler that is built into LLDB. I don't think this can be specified multiple times. Inline comments ask if

Wed, Apr 7, 7:23 PM · Restricted Project, Restricted Project
clayborg accepted D96626: Support: mapped_file_region: Pass MAP_NORESERVE to mmap.

Since no one else is responding, lets try this out and see how things go.

Wed, Apr 7, 2:22 PM · Restricted Project
clayborg added inline comments to D99974: [lldb-vscode] redirect stderr/stdout to the IDE's console.
Wed, Apr 7, 2:10 PM
clayborg requested changes to D99974: [lldb-vscode] redirect stderr/stdout to the IDE's console.
Wed, Apr 7, 1:44 PM
clayborg requested changes to D99989: [lldb-vscode] Distinguish shadowed variables in the scopes request.
Wed, Apr 7, 1:37 PM

Tue, Apr 6

clayborg accepted D100003: [lld-macho] Sibling N_SO symbols must have the empty string.

LGTM

Tue, Apr 6, 8:57 PM · Restricted Project, Restricted Project
clayborg accepted D99907: [dsymutil] Don't emit .debug_pubnames and .debug_pubtypes unless asked for explicitly.

Nice! Do you have anymore patches that we can do to improve dsymutil now that we don't require byte-for-byte compatibility with dsymutil-classic?

Tue, Apr 6, 5:37 PM · Restricted Project
clayborg requested changes to D99989: [lldb-vscode] Distinguish shadowed variables in the scopes request.

I think this really should be fixed in the VS code variable view. It allows debugging of languages that support having multiple variables with the same name, so their debugger should support it.

Tue, Apr 6, 4:24 PM
clayborg requested changes to D99974: [lldb-vscode] redirect stderr/stdout to the IDE's console.

Just need to fix the default python arguments that were: "foo={}". This doesn't do what you think it will do. See https://docs.quantifiedcode.com/python-anti-patterns/correctness/mutable_default_value_as_argument.html

Tue, Apr 6, 4:05 PM

Thu, Apr 1

clayborg committed rG2d733923b8d3: Fix "image lookup --address" Summary results for inline functions. (authored by clayborg).
Fix "image lookup --address" Summary results for inline functions.
Thu, Apr 1, 11:37 AM
clayborg closed D98761: Fix "image lookup --address" Summary results for inline functions..
Thu, Apr 1, 11:36 AM · Restricted Project
clayborg added inline comments to D98289: [lldb] 2/2: Fix DW_AT_ranges DW_FORM_sec_offset not using DW_AT_rnglists_base (used by GCC).
Thu, Apr 1, 10:34 AM · Restricted Project
clayborg added a comment to D98761: Fix "image lookup --address" Summary results for inline functions..

Anyone else have any issue with this patch?

Thu, Apr 1, 10:06 AM · Restricted Project
clayborg added a comment to D98761: Fix "image lookup --address" Summary results for inline functions..

Anyone else have any issue with this patch?

Thu, Apr 1, 9:41 AM · Restricted Project
clayborg accepted D99653: [nfc] [lldb] 1/2: Fix DW_AT_ranges DW_FORM_sec_offset not using DW_AT_rnglists_base (used by GCC).
Thu, Apr 1, 9:41 AM · Restricted Project

Wed, Mar 31

clayborg requested changes to D99653: [nfc] [lldb] 1/2: Fix DW_AT_ranges DW_FORM_sec_offset not using DW_AT_rnglists_base (used by GCC).

Looks good as long as we fix to DWARFUnit::GetRnglist() to not return a full copy of the "llvm::Optional<llvm::DWARFDebugRnglistTable>" each time it is called.

Wed, Mar 31, 8:55 AM · Restricted Project

Tue, Mar 30

clayborg accepted D91679: [trace][intel-pt] Implement trace start and trace stop.

Sounds good. Lets gets this in then and start iterating on future patches!

Tue, Mar 30, 5:07 PM · Restricted Project
clayborg added a comment to D91679: [trace][intel-pt] Implement trace start and trace stop.

Looking really good.

Tue, Mar 30, 5:02 PM · Restricted Project
clayborg updated the diff for D98761: Fix "image lookup --address" Summary results for inline functions..

Remove show_inline_callsite_line_info setting from SymbolContext dumping function as it isn't needed, show_inlined_frames controls this.

Tue, Mar 30, 2:43 PM · Restricted Project
clayborg added a comment to D96626: Support: mapped_file_region: Pass MAP_NORESERVE to mmap.

I am fine with always adding MAP_NORESERVE unless anyone can think of a reason not to add it. Or we can modify this patch to add the MAP_NORESERVE only when PROT_WRITE isn't specified if that is worrying anyone.

Tue, Mar 30, 1:20 PM · Restricted Project

Mon, Mar 29

clayborg added inline comments to D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.
Mon, Mar 29, 4:11 PM · Restricted Project
clayborg committed rGeee309068e6e: Fix .debug_aranges parsing issues. (authored by clayborg).
Fix .debug_aranges parsing issues.
Mon, Mar 29, 3:35 PM
clayborg closed D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.
Mon, Mar 29, 3:34 PM · Restricted Project
clayborg added a comment to D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.

I'd love to get this in as this affects many of our clients. Does anyone else have an issues with this?

Mon, Mar 29, 3:31 PM · Restricted Project
clayborg requested changes to D91679: [trace][intel-pt] Implement trace start and trace stop.
Mon, Mar 29, 3:00 PM · Restricted Project
clayborg added a comment to D99497: [LLDB] Fix sync issue in TestVSCode_launch.test_progress_events.

Isn't there a better way to ensure synchronization here? Maybe, executing some command (setting a breakpoint, for instance), that will ensure that all symbols have been parsed?

Mon, Mar 29, 11:53 AM · Restricted Project
clayborg accepted D99497: [LLDB] Fix sync issue in TestVSCode_launch.test_progress_events.

lgtm!

Mon, Mar 29, 10:56 AM · Restricted Project
clayborg accepted D99491: [LLDB] Fix cleanup error in TestVSCode_disconnect.test_launch.

Thanks for looking into this!

Mon, Mar 29, 10:55 AM · Restricted Project

Fri, Mar 26

clayborg updated the diff for D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.

Simplify expression for calculating the m_next_offset.

Fri, Mar 26, 3:10 PM · Restricted Project
clayborg added inline comments to D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.
Fri, Mar 26, 3:08 PM · Restricted Project
clayborg updated the diff for D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.

Fix issues found by JDevlieghere.

Fri, Mar 26, 3:06 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

I built on mac with ASAN and ran the tests and they passed just fine. I was also able to compile on Debian linux and the tests ran ok for me. Can anyone else reproduce this failure?

Fri, Mar 26, 3:04 PM · Restricted Project
clayborg added a comment to D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.

(generally makes sense to me - but I'll leave it to some more lldb-focussed reviewers to do more review/approval)

Usual caveat/question: Does this take us closer or further away from unifying this code with LLVM's libDebugInfoDWARF? (or neutral)

Fri, Mar 26, 11:04 AM · Restricted Project
clayborg updated subscribers of D97739: Add a progress class that can track and report long running operations that happen in LLDB..

I will take a look and apply this patch on my linux server and enable ASAN. Looks like lldb-vscode must be crashing from what the errors look like.

Fri, Mar 26, 9:48 AM · Restricted Project
clayborg retitled D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB from Fix .debug_aranges parsing issues. to Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.
Fri, Mar 26, 1:14 AM · Restricted Project
clayborg requested review of D99401: Fix .debug_aranges parsing issues introduced with llvm error handling in LLDB.
Fri, Mar 26, 1:11 AM · Restricted Project

Wed, Mar 24

clayborg committed rGe122877f1098: Add a progress class that can track long running operations in LLDB. (authored by clayborg).
Add a progress class that can track long running operations in LLDB.
Wed, Mar 24, 12:58 PM
clayborg closed D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Wed, Mar 24, 12:58 PM · Restricted Project

Mon, Mar 22

clayborg updated the diff for D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Don't store a debugger pointer in the lldb_private::Progress class, store a debugger ID as an optional value. Then use this value in the debugger report progress function to do the right thing.

Mon, Mar 22, 9:57 PM · Restricted Project
clayborg added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mon, Mar 22, 9:11 PM · Restricted Project
clayborg added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mon, Mar 22, 5:49 PM · Restricted Project
clayborg updated the diff for D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Added the option for people to add a debugger to a lldb_private::Progress instance. This allows progress to be reported only to specific debuggers.

Mon, Mar 22, 5:41 PM · Restricted Project
clayborg added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mon, Mar 22, 3:37 PM · Restricted Project
clayborg updated the diff for D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Removed all callback related code and now only use events.

Mon, Mar 22, 11:53 AM · Restricted Project

Fri, Mar 19

clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Thanks for doing this! The event version looks pretty clean to me. I think we should go that way. I don't think we should have two ways, that seems confusing and still leaves us calling unknown user code in the middle of symbol updates...

Fri, Mar 19, 10:43 AM · Restricted Project

Thu, Mar 18

clayborg updated the diff for D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Added support for getting progress events via SBEvent delivery.

Thu, Mar 18, 6:25 PM · Restricted Project

Wed, Mar 17

clayborg added a comment to D98761: Fix "image lookup --address" Summary results for inline functions..

If anyone wants to try this out, you can yaml2obj the yaml file and then do manual lookups. If you are on a mac, you can also debug any binary with inline function calls and stop anywhere and compare "bt" to the "image lookup --address $pc" to verify this works as expected.

Wed, Mar 17, 4:06 PM · Restricted Project
clayborg updated the diff for D98761: Fix "image lookup --address" Summary results for inline functions..

Remove extra parameter call to SymbolContext::DumpStopContext() recrusive call that was left over from iterating on my patch.

Wed, Mar 17, 4:02 PM · Restricted Project
clayborg added reviewers for D98761: Fix "image lookup --address" Summary results for inline functions.: jingham, jasonmolenda.
Wed, Mar 17, 11:38 AM · Restricted Project

Mar 16 2021

clayborg requested review of D98761: Fix "image lookup --address" Summary results for inline functions..
Mar 16 2021, 10:14 PM · Restricted Project

Mar 15 2021

clayborg accepted D98656: [lldb-vscode] Handle request_evaluate's context attribute.

I agree that we the hover happens way too often and it actually happens with any text you hover over including comments, so this is a good change.

Mar 15 2021, 2:46 PM · Restricted Project

Mar 11 2021

clayborg added a comment to D98400: [Test][DebugInfo] Check for backend object emission support..

Looks good to me, probably best to get an ok from someone else as well.

Mar 11 2021, 11:41 AM · Restricted Project

Mar 7 2021

clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

This way of doing progress is going to look odd in anything that uses multiple debuggers. If I'm reading the code aright, if I have two debuggers, and a target in Debugger A starts doing something that would cause progress traffic, both debuggers will show activity.

that is true, but it is a global module repository that benefits both debuggers. And I very rarely debug two things at the same time, so most of the time for most people this will be beneficial and shouldn't cause too much confusion.

Just one tidbit here. Most users are actually routinely running tens of debuggers at the same time, because tests run in parallel and they have a debugger attached by default. Now if you have a long running operation kick in in your unit tests, you might already have a different kind of issue, but I’d like to avoid a world where the IDE displays spurious and wrong information because of this.

Mar 7 2021, 11:29 PM · Restricted Project

Mar 5 2021

clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

I agree that we should avoid SBEvent after thinking about it.

First off, doing long running operations on a thread that is the one handling the major lldb events is obviously a bad idea. The driver doesn't do it this way. Commands get run on the main thread, and events get processed on the event-handler thread.

Mar 5 2021, 4:29 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

I agree that we should avoid SBEvent after thinking about it.

Mar 5 2021, 3:09 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

One serious vote against the SBEvent way of doing things is that it might stop progress notification from appearing in the UI immediately if someone is currently calling something that causes a long running operation from the main thread that is running the SBEvent loop...

Mar 5 2021, 3:03 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

SBDebugger currently doesn't vend any events so that would need to be added.

Mar 5 2021, 3:01 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

This way of doing progress is going to look odd in anything that uses multiple debuggers. If I'm reading the code aright, if I have two debuggers, and a target in Debugger A starts doing something that would cause progress traffic, both debuggers will show activity.

Mar 5 2021, 2:56 PM · Restricted Project
clayborg accepted D98073: [lld-macho] Skip over symbols in un-parsed debug info sections.

yes, anything in the debug_aranges are safe to ignore as dsymutil will create a new debug_aranges and doesn't end up using any of the debug_aranges sections from the .o files and nothing from debug_aranges ends up in the debug map.

Mar 5 2021, 2:13 PM · Restricted Project, Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

So we have had a vote for allowing multiple callbacks. Any other main issues with the approach in this patch? If everyone is mostly happy, please chime in and I will make unit tests and vscode tests.

Mar 5 2021, 10:42 AM · Restricted Project

Mar 3 2021

clayborg added inline comments to D97644: Allow RegisterContext to track if behaves-like-frame-0, allow LanguageRuntime for above frame 0.
Mar 3 2021, 4:00 PM · Restricted Project
clayborg updated the diff for D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Fix typo in headerdoc comment.

Mar 3 2021, 3:28 PM · Restricted Project
clayborg requested changes to D97644: Allow RegisterContext to track if behaves-like-frame-0, allow LanguageRuntime for above frame 0.
Mar 3 2021, 3:01 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

This version should address all comments and issue that I am aware of. Now the callbacks are registered with each debugger and the Progress class no longer has any global state. The Progress class calls a static method on the debugger which allows the Debugger class to iterate over the global debugger list and report progress to any debuggers that have callbacks. This also means that later we can modify the Progress class to allow debugger specific progress notifications by modifying the Progress class to take a debugger ID or pointer as an optional constructor argument and then that progress can be reported to only that debugger instance. I don't have any places I need this yet, so I haven't added support for it.

Mar 3 2021, 11:48 AM · Restricted Project
clayborg updated the diff for D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Update fixes:

  • make progress callback and baton members of a lldb_private::Debugger object to allow each debugger to have their own callbacks.
  • switch to have std::string title and clients use llvm::formatv() to create the title to avoid printf variadic args in progress constructor
  • make the progress class thread safe using a mutex
  • verified that lldb-vscode callback is threadsafe
Mar 3 2021, 11:43 AM · Restricted Project
clayborg added a comment to D96626: Support: mapped_file_region: Pass MAP_NORESERVE to mmap.

I would mark as accepted but I am not the code owner for llvm/lib/Support/Unix.

Mar 3 2021, 11:02 AM · Restricted Project
clayborg added a comment to D96626: Support: mapped_file_region: Pass MAP_NORESERVE to mmap.

From my brief reading of the man pages on linux I don't see any issue with adding this flag.

Mar 3 2021, 11:01 AM · Restricted Project

Mar 2 2021

clayborg added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mar 2 2021, 4:02 PM · Restricted Project
clayborg accepted D97769: [lldb] Apply gdb-remote timeout to platform connections as well.

LGTM

Mar 2 2021, 10:18 AM · Restricted Project

Mar 1 2021

clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

This is fully hooked up and working in Visual Studio Code now! Works well. The Visual Studio Code shows any progress that takes more than 0.5 seconds down in the bottom toolbar for me. We can and should discuss these changes now that they are working.

Mar 1 2021, 10:01 PM · Restricted Project
clayborg updated the diff for D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Added a more granular progress when manaully indexing the DWARF where we report on unit of progress for parsing all dies in a unit, and one unit of progress for indexing each compile unit, and one unit of work when merging the IndexSets.

Mar 1 2021, 10:00 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Forgot to mention I added a lldb-vscode implementation after someone told me they now support progress reporting in Visual Studio Code. See https://microsoft.github.io/debug-adapter-protocol/specification#Events_ProgressStart

Mar 1 2021, 6:36 PM · Restricted Project
clayborg updated the diff for D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Added a "uint64_t progress_id;" as a member variable of the lldb_private::Progress class to help users track individual progress dialogs without conflict. Prior to this the message was assumed to be unique.

Mar 1 2021, 6:34 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

I haven't thought about the details of this implementation closely yet. How will this handled nested progress bars? For instance, if I'm Indexing (maybe even on multiple threads) and then one of the threads results in a debug symbols fetch request (e.g. dsymForUUID). Is the consumer just supposed to check the string that comes into the progress callback to match the now two simultaneous progress elements?

Mar 1 2021, 6:29 PM · Restricted Project
clayborg added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mar 1 2021, 5:35 PM · Restricted Project
clayborg added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mar 1 2021, 5:34 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

Another thing to clarify: The current design of the Progress objects, when destructed, will report progress with the stored "m_total" value to indicate that the progress is complete. Even if exceptions are thrown, the destructor will still be called. So all current uses of the "Progress" objects, will currently report progress when constructed with a "completed" value of zero:

ProgressCallback(message = "Indexing DWARF for /tmp/a.out", completed = 0, total = UINT64_MAX, baton = <baton>);

Then when the Progress object is destroyed, we will report a completed value that is equal to the "Progress::m_total" to indicate things are done:

ProgressCallback(message = "Indexing DWARF for /tmp/a.out", completed = UINT64_MAX, total = UINT64_MAX, baton = <baton>);

The idea is when the code that installs the progress callback gets its callback called, and if the "completed == total" then the UI can remove the progress indicator for "<message>". The message string is a const string and will be unique and the same pointer value for the message will always be used, so the progress is keyed off of the message pointer value.

Mar 1 2021, 3:56 PM · Restricted Project
clayborg added inline comments to D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mar 1 2021, 3:49 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

The current Progress class allows users to specify how many items are to be done when they construct a lldb_private::Progress object, but this part is not used right now for anything yet because it is often hard to know how many items of work there are. For symbol tables in ELF, we have two of them, but we might also create new symbols from EH frame or other sources when there are no symbols, so it was hard to pre-determine a full number of symbols for a given executable. Same goes for mach-o files with the normal symbol table, then new symbols are created from the LC_FUNCTION_STARTS load command that has start addresses for all functions, many of which have symbols. For DWARF, we have 3 ways to index the DWARF: Apple tables, .debug_names, and manually. I will comment inline where we could specify a valid number of work items for DWARF to improve the feedback. The other reason the progress objects don't report immediate feedback is the frequency of the progress callbacks could slow things down if they are called too often with too little work. I am happy to talk about any of these issues if anyone has any questions.

Mar 1 2021, 3:45 PM · Restricted Project
clayborg retitled D97739: Add a progress class that can track and report long running operations that happen in LLDB. from Add a progress class that can track long running operations in LLDB. to Add a progress class that can track and report long running operations that happen in LLDB..
Mar 1 2021, 3:37 PM · Restricted Project
clayborg added a comment to D97739: Add a progress class that can track and report long running operations that happen in LLDB..

So this is a first pass on adding progress notifications to the LLDB public API, and to see how it would be used internally. If we can agree on the implementation, then I will add full tests and documentation to this diff. We used a similar patch to this in an older internal version of lldb-vscode before lldb-vscode was fully open sourced, so we know it works at a base level.

Mar 1 2021, 3:35 PM · Restricted Project
clayborg requested review of D97739: Add a progress class that can track and report long running operations that happen in LLDB..
Mar 1 2021, 3:32 PM · Restricted Project
clayborg added a comment to D97644: Allow RegisterContext to track if behaves-like-frame-0, allow LanguageRuntime for above frame 0.

Another alternative to RegisterContext::BehavesLikeZerothFrame that I've thought of is RegisterContext::GetPCForSymbolication, similar to GetPC() today. I think everyone who is decrementing $pc is doing it for symbolication, so having this hint and then leaving it to everyone to decrement-or-not may not be a great choice. It may be easier for higher-levels if RegisterContext can provide an Address suitable for symbolication directly.

Mar 1 2021, 10:53 AM · Restricted Project

Feb 24 2021

clayborg added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..
In D96035#2585324, @avl wrote:

How would you guarantee that the artificial CU is always emitted in the same order? It seems like you need to stash the types somewhere, then create a deterministic ordering and then emit it, but I don't remember whether that's doable with LLVM's DIEs (It's been a while since I touched this code).

We might sort types on name basis inside that artificial CU. In this case it would always be emitted in the same order.

I don't think finding how to sort them is the complicated part. In my mind the issue is keeping them around until you can sort them as I'm not sure DIEs can exist not attached to a CU. Also, it's not just the one type, but the transitive closure of all its dependencies that you need to consider which makes things (much) more complicated. As I said before, I haven't worked on this in a long time, so feel free to shoot my concerns down!

Feb 24 2021, 1:43 PM · Restricted Project

Feb 23 2021

clayborg added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

One idea is for each type we want to unique, each CU as it is being parsed on its own thread creates a type map that maps "type compile unit path" (which is DW_AT_decl_file of that type) to a list of uniqued types with decl context info. This would allow all types with the same DW_AT_decl_file to be stored in the same type compile unit. As we emit the debug info for a normal compile unit, any type references are changed to be DW_AT_ref_addr references with values that will need to be fixed up. After all normal CUs have been emitted, combine all of the CU specific type maps together, and now emit the type compile units (carefully to include all needed children in each type to make the most complete version of the type possible and emit them) in a sorted order to allow determinism. Then we fix up all DW_AT_ref_addr references in the normal CUs to point to the one type definition from the type compile units.

Feb 23 2021, 6:17 PM · Restricted Project

Feb 22 2021

clayborg added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..
In D96035#2579263, @avl wrote:

@JDevlieghere @aprantl @echristo @dblaikie @clayborg

What do you think of this patch? Is it OK in general and Is it worth to divide it into smaller patches and integrate?

Feb 22 2021, 11:50 AM · Restricted Project

Feb 19 2021

clayborg added inline comments to D96637: Make sure the interpreter module was loaded before making checks against it.
Feb 19 2021, 5:07 PM · Restricted Project
clayborg accepted D96680: [lldb-vscode] Emit the breakpoint changed event on location resolved.
Feb 19 2021, 5:02 PM · Restricted Project
clayborg added a comment to D96637: Make sure the interpreter module was loaded before making checks against it.

I don't think this does what you think it does. The $() doesn't give you the process id of anything -- it substitutes a string by the result of running that string as a shell command. So, the PID variable would get the (entire) stdout of %s.out

I'm confused here, "the PID variable would get the (entire) stdout of %s.out" is exactly what I'm expecting to happen, the stdout of the program is its pid.

I was finally able to figure out what the issue was. I thought pause() would continue once the debugger attached because it sends a signal, but that doesn't seem to be the case?

Feb 19 2021, 11:28 AM · Restricted Project

Feb 17 2021

clayborg requested changes to D96680: [lldb-vscode] Emit the breakpoint changed event on location resolved.

needs a test. Just make a test app with a shared library that gets dlopen'ed in the main function. At first the breakpoint in the shared library will be unresolved, then after stepping over the dlopen call, it should get resolved.

Feb 17 2021, 3:16 PM · Restricted Project
clayborg added a comment to D96817: Fix deep copying for OptionValue classes.

CRTP was my first implementation, however, I discarded it as more bug-prone. Virtual Clone function at the interface is so common that, I believe, everyone knows it must be overridden by a new derived class. The necessity of inheriting from base_clone_helper is not so obvious.

I would've thought it'd be pretty easy to accidentally miss either of these - I think the CRTP helper ensures consistency of implementation (harder to accidentally slice/copy the wrong type/etc. But I'm not a code owner/major contributor to lldb specifically, so probably more up to other developers who are.

Feb 17 2021, 3:04 PM · Restricted Project
clayborg added a comment to D96637: Make sure the interpreter module was loaded before making checks against it.

We should have a test for this.

how do you recommend doing this? I spent a couple of hours on this but got no where. From what I understood we should prefer lit tests, so I was thinking of creating a binary that dlopens a module. However, I wasn't able to create a binary that I can start and capture its pid address so that I can attach to. Here's what I've tried so far:

// RUN: cp %s %s.cpp
// RUN: %clang -g -O0 --target=x86_64-linux-gnu %s.cpp -o %s.out
// RUN: PID=$(%s.out)
// RUN: %lldb -p $PID -b -o 'target list' | FileCheck %s
// RUN: kill -9 $PID
// CHECK: foo

#include <stdio.h>
#include <unistd.h>

int main() {
    pid_t pid = fork();
    if (pid > 0) {
        // parent process, print child pid
        printf("%d", pid);
        return 0;
    } else if (pid < 0) {
        printf("Unable to fork\n");
        return -1;
    }
    // child process
    pause();
}

The lit test get stuck on // RUN: PID=$(%s.out). Not sure why, the parent process shouldn't wait on its children..

Feb 17 2021, 2:31 PM · Restricted Project
clayborg added a comment to D96839: Add a callout to the LanguageRuntime to override the normal UnwindPlan used for a frame.

Can each real stack frame inject N frames in the middle of a stack frame for these asynchronous functions? Or is this like the libdispatch stuff that show more frames at the end of a normal stack trace? Can you attach some sample backtraces with some annotations?

Feb 17 2021, 1:15 PM · Restricted Project

Feb 16 2021

clayborg added a comment to D96829: Add "Undeclared registers are marked as Undefined" to UnwindPlan, adopt it in arch default unwind plans.

Makes sense, LGTM.

Feb 16 2021, 10:26 PM · Restricted Project
clayborg added a comment to D96623: [lldb-vscode] Fix lldb init file stdout issue.

I added Jim and Pavel to get some more feedback.

Feb 16 2021, 4:09 PM · Restricted Project
clayborg added reviewers for D96623: [lldb-vscode] Fix lldb init file stdout issue: jingham, labath.
Feb 16 2021, 4:03 PM · Restricted Project
clayborg added a comment to D96623: [lldb-vscode] Fix lldb init file stdout issue.

After thinking about this a bit more, it seems a mistake that we can't change the file handles _prior_ to sourcing the init files. I have proposed one solution in the inline comments to create a new SBDebugger::Create() method that takes the input output and error file handles as arguments. The other way to do this is to make it so that we _can_ run the init files later. Currently if we say "false" to "bool source_init_files", then the command interpreter marks the init files as not being able to be run again later if you call the SBCommandInterpreter::SourceInitFileInHomeDirectory(...). So we need to either be able to either specify the file handles at debugger creation time, or run them one time later. The current "run them once" means "you can only do this at debugger creation time, but never again if you specify false for source_init_files. We can change this to be "only run the init files once. so if we already run them in SBDebugger::Create(), then don't run them again if you call SBCommandInterpreter::SourceInitFileInHomeDirectory()

Feb 16 2021, 3:01 PM · Restricted Project

Feb 5 2021

clayborg added a comment to D96176: Implement jAttachWait.

See inlined comment about the packet name issue and let me know what you think

Feb 5 2021, 4:30 PM · Restricted Project

Feb 4 2021

clayborg added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

Handling inter-CU references: inter-CU references are hard to process using only one pass. f.e. if CU1 references CU100 and CU100 references CU1, we could not finish handling of CU1 until we finished CU100. Thus we either need to load all CUs into the memory, either load CUs several times.

Feb 4 2021, 2:44 PM · Restricted Project