Page MenuHomePhabricator
Feed Advanced Search

Today

clayborg accepted D80569: [lldb-vscode] Make it possible to run vsce package .
Wed, May 27, 3:16 PM · Restricted Project
clayborg added a comment to D80569: [lldb-vscode] Make it possible to run vsce package .

LGTM.

Wed, May 27, 3:16 PM · Restricted Project
clayborg added a comment to D80576: [lldb-vscode] Reopen stderr as /dev/null.

So this brings up the question of what to do with any unsolicited STDOUT/STDERR. One idea that we floated around before was to immediately dup the original STDIN/OUT/ERR to new file descriptors, adopt the duped stdin/stdout using g_vsc.input and g_vsc.output, then close stdin, stdout, stderr and create make new file handles for stdout/stderr and listen to them with a thread and pass any output from these to the "output" console stream. This way any warnings or errors are not just dropped on the floor, and yet if we dupe the file descriptors for stdin/out, then we won't run into any stdout/stderr ruining out packet traffic. Pavel, thoughts on what the best approach is?

Wed, May 27, 1:36 PM · Restricted Project

Yesterday

clayborg updated subscribers of D80576: [lldb-vscode] Reopen stderr as /dev/null.
Tue, May 26, 6:00 PM · Restricted Project
clayborg added inline comments to D80569: [lldb-vscode] Make it possible to run vsce package .
Tue, May 26, 6:00 PM · Restricted Project

Fri, May 22

clayborg accepted D80254: Prevent GetNumChildren from transitively walking pointer chains.

Major changes not required. Thanks for finding and fixing this!

Fri, May 22, 10:28 PM · Restricted Project

Thu, May 21

clayborg added inline comments to D79962: Fix the verification of DIEs with DW_AT_ranges..
Thu, May 21, 11:53 AM · Restricted Project

Wed, May 20

clayborg added a comment to D80254: Prevent GetNumChildren from transitively walking pointer chains.

This looks good, thanks for subscribing me. We need to have GetNumChildren and GetChildAtIndex agreeing on things and we definitely shouldn't be walking more than on pointer recursively. My only question is do we need helper functions added to TypeSystemClang to avoid this issue since we have GetNumChildren and GetChildAtIndex doing things differently? Some function both could/should be calling so that things can't get out of sync?

Wed, May 20, 5:07 PM · Restricted Project

Tue, May 19

clayborg added a comment to D79962: Fix the verification of DIEs with DW_AT_ranges..

Ping in case anyone has time to help move this forward.

Tue, May 19, 11:28 AM · Restricted Project

Mon, May 18

clayborg accepted D80165: [lldb/Driver] Fix handling on positional arguments.

Much better!

Mon, May 18, 5:54 PM · Restricted Project
clayborg added a comment to D80165: [lldb/Driver] Fix handling on positional arguments.

So when talking about "prior to libOption", are we talking getopt()? I believe that getopt would have an issue with:

Mon, May 18, 4:17 PM · Restricted Project

Thu, May 14

clayborg added inline comments to D79726: Add terminateCommands to lldb-vscode protocol.
Thu, May 14, 11:22 PM · Restricted Project
clayborg added a comment to D79962: Fix the verification of DIEs with DW_AT_ranges..

All issues should be resolved. Test case was improved to verify old behavior doesn't persist by adding a CHECK-NOT in the test case.

Thu, May 14, 8:07 PM · Restricted Project
clayborg updated the diff for D79962: Fix the verification of DIEs with DW_AT_ranges..

Rename union_range to union_if_intersecting and and remove llvm:: qualification on None.

Thu, May 14, 8:07 PM · Restricted Project
clayborg updated the diff for D79962: Fix the verification of DIEs with DW_AT_ranges..

Fixed test case to properly check that we do not see a "error: DIE address ranges are not contained in its parent's ranges:" string in the output. The old llvm-dwarfdump --verify would have this incorrect error.

Thu, May 14, 8:07 PM · Restricted Project
clayborg added inline comments to D79962: Fix the verification of DIEs with DW_AT_ranges..
Thu, May 14, 7:35 PM · Restricted Project
clayborg added a comment to D79962: Fix the verification of DIEs with DW_AT_ranges..

I updated the description to better explain the fix.

Thu, May 14, 7:03 PM · Restricted Project
clayborg updated the summary of D79962: Fix the verification of DIEs with DW_AT_ranges..
Thu, May 14, 7:03 PM · Restricted Project
clayborg added a comment to D79962: Fix the verification of DIEs with DW_AT_ranges..

I'm not able to understand the description of the original bug, perhaps you could show the original behavior for your test case for comparison?

Thu, May 14, 7:03 PM · Restricted Project
clayborg added a comment to D79962: Fix the verification of DIEs with DW_AT_ranges..

The verification for:

0x0000000b: DW_TAG_compile_unit
              DW_AT_name        ("/tmp/main.c")
              DW_AT_language    (DW_LANG_C_plus_plus)
              DW_AT_low_pc      (0x0000000000000000)
              DW_AT_ranges      (0x00000000
                 [0x0000000000000000, 0x0000000000000020)
                 [0x0000000000000000, 0x0000000000000030)
                 [0x0000000000001000, 0x0000000000002000))
              DW_AT_stmt_list   (0x00000000)
Thu, May 14, 1:36 PM · Restricted Project
clayborg added reviewers for D79962: Fix the verification of DIEs with DW_AT_ranges.: dblaikie, compnerd.
Thu, May 14, 1:36 PM · Restricted Project
clayborg created D79962: Fix the verification of DIEs with DW_AT_ranges..
Thu, May 14, 1:36 PM · Restricted Project
clayborg added a comment to D79811: WIP: Reenable creation of artificial methods in AddMethodToCXXRecordType(...).

I really worry enabling this will make the expression parser start to emit errors if we change this. The best fix would be to ensure that the AST importer can correctly ignore implicit functions when comparing types.

Thu, May 14, 12:30 PM
clayborg added a comment to D79757: Use IPv4 for Android connections.

@clayborg the support we added was for the lldb-server.

Thu, May 14, 11:57 AM · Restricted Project

Wed, May 13

clayborg committed rG6e73f12a641b: Fix buildbots errors after comitting D78782. (authored by clayborg).
Fix buildbots errors after comitting D78782.
Wed, May 13, 10:19 PM
clayborg added a comment to D78782: Add .debug_ranges support to the DWARF YAML..

Fixed buildbots with:

Wed, May 13, 10:19 PM · Restricted Project
clayborg added a comment to D79757: Use IPv4 for Android connections.

There was a patch previous to this that enabled IPv6. We need IPv6 on some computers here at Facebook. Can you check this file's log and look at the IPv6 patch and make sure this doesn't just undo that patch prior to committing this? If it does undo that patch, maybe we can check to see if IPv6 works somehow in LLDB one time and then enable IPv6 if it is supported and disable it if not?

Wed, May 13, 10:19 PM · Restricted Project
clayborg added a comment to D79757: Use IPv4 for Android connections.

nice catch!

Wed, May 13, 7:39 PM · Restricted Project
clayborg added a comment to D79811: WIP: Reenable creation of artificial methods in AddMethodToCXXRecordType(...).

The error where two of the same classes conflicted usually only happened in complex cases that were hard to reduce down.

If I understand this correctly, the compiler should be able to auto synthesize these functions at will since the original class definition should have all of the information it needs to create them. So why do we need these to be added? Seems like the wrong approach IMHO. I would like the hear the justification for needing to add artificial functions to a class definition before we entertain this more. Can you elaborate on why you think these are needed?

Yes, the test case below shows that if we don't add the method then during expression evaluation of let's say:

A{}

The default member initializer won't be done. So x won't be initialized to 10 and the default constructor for cse will be called instead of ClassForSideEffect(int).

Wed, May 13, 7:07 PM
clayborg committed rG6025fc2243c6: Add .debug_ranges support to the DWARF YAML. (authored by clayborg).
Add .debug_ranges support to the DWARF YAML.
Wed, May 13, 4:25 PM
clayborg closed D78782: Add .debug_ranges support to the DWARF YAML..
Wed, May 13, 4:24 PM · Restricted Project
clayborg added a comment to D79726: Add terminateCommands to lldb-vscode protocol.

might be nice to have "disconnectCommands" at some point if we ever need them too.

Wed, May 13, 12:31 PM · Restricted Project
clayborg accepted D79726: Add terminateCommands to lldb-vscode protocol.
Wed, May 13, 12:31 PM · Restricted Project
clayborg added a comment to D79811: WIP: Reenable creation of artificial methods in AddMethodToCXXRecordType(...).

The error where two of the same classes conflicted usually only happened in complex cases that were hard to reduce down.

Wed, May 13, 12:31 PM

Tue, May 12

clayborg added a comment to D79614: Fix error reporting for qLaunchSuccess, check for fix/enable it via qSupported.

Thanks for the feedback.

I think that "piggy-backing" on the qSupported packet for communicating protocol fixes is a good idea. However, I agree with Greg, that it does not seem like it's needed for this case. Fixing the problem purely on the debugserver side seems preferable, as it avoids adding compatibility code to lldb. It's true that it's a one-off error reporting mechanism, but it's already there, so it seems better to just support what's already implemented then try to support two mechanisms.

For a long-term solution, I am wondering whether we need qLaunchSuccess at all? It seems like the packet is completely redundant in a world where we can return textual error messages to _any_ packet. What was the reason for introducing it in the first place? Could we just switch to using error replies to the A packet for communicating the launch errors (with some transition plan for supporting qLaunchSuccess for a while)?

It's hard to tell what we were thinking (GREG :) back when we used the A packet to set the binary name / arguments /etc, and then the qLaunchSuccess packet to start the process. Reading over the current era gdb Remote Serial Protocol docs, I think the vRun packet does the combination of these two things in one packet, which makes sense.

Tue, May 12, 4:44 PM · Restricted Project

Sat, May 9

clayborg added a comment to D79614: Fix error reporting for qLaunchSuccess, check for fix/enable it via qSupported.

Why not just fix qLaunchSuccess by passing the string through a "escape_string(...)" function? Any packet that can return a string with unknown content should be escaped correctly. Adding a new packet doesn't really fix the problem in older debugserver/lldb-server binaries anyway.

lldb wouldn't know whether to decode the returned error string or not -- short of using a debugserver version #. We'll need to interoperate with debugservers that send the unescaped qLaunchSuccess error messages for years to come.

Sat, May 9, 12:12 PM · Restricted Project

Fri, May 8

clayborg added a comment to D79614: Fix error reporting for qLaunchSuccess, check for fix/enable it via qSupported.

Why not just fix qLaunchSuccess by passing the string through a "escape_string(...)" function? Any packet that can return a string with unknown content should be escaped correctly. Adding a new packet doesn't really fix the problem in older debugserver/lldb-server binaries anyway.

Fri, May 8, 6:17 PM · Restricted Project

Mon, May 4

clayborg added a comment to D78782: Add .debug_ranges support to the DWARF YAML..

if I hand edit the YAML, section sizes change and all of the data is off since and there are the existing yaml2obj ignores a different AddrSize

Mon, May 4, 8:27 PM · Restricted Project
clayborg added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

Interesting approach to DWARF expression evaluation, though it might be simpler to leave the DWARFExpression as it is, and have the plug-in part only handle unknown opcodes. Right now if you want to add just one opcode, you must subclass and make a plug-in instance where 99% of opcodes get forwarded to the original implementation and the one new opcode gets handled by the plug-in. What if the DWARFExpression class was passed to a plug-in that only handles unknown opcodes? Might be fewer code changes and be a bit cleaner. The plug-in would handle only the DW_OP_WASM_location and would still be found/detected if and only if one is encountered?

Mon, May 4, 8:27 PM · Restricted Project
clayborg accepted D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error..

LGTM now. Pavel?

Mon, May 4, 7:22 PM · Restricted Project

Thu, Apr 30

clayborg accepted D79209: [lldb/CommandInterpreter] Add CommandInterpreterRunResult (NFC).
Thu, Apr 30, 6:35 PM · Restricted Project
clayborg added inline comments to D70885: [lldb] Use explicit lldb commands on tests.
Thu, Apr 30, 6:35 PM · Restricted Project
clayborg accepted D79120: [lldb/API] Add RunCommandInterpreter overload that returns SBCommandInterpreterRunResults (NFC).
Thu, Apr 30, 6:35 PM · Restricted Project
clayborg added a comment to D78672: [Debuginfo] Remove redundand variable from getAttributeValue().
In D78672#2013690, @avl wrote:

@clayborg

If we did end up tracking FixedOffset values in each AttributeSpec, we could track index of the last AttributeSpec that has a fixed form size and keep it as an ivar to this class. This loop could become more efficient by skipping all of the fixed form sizes up front and then only iterating over the remaining ones:

I gave it a try. But it did not show any performance improvement. It even created a small(0.5%) performance degradation - https://reviews.llvm.org/differential/diff/261331/

Thu, Apr 30, 3:06 PM · debug-info, Restricted Project
clayborg updated the diff for D78782: Add .debug_ranges support to the DWARF YAML..

Fixed inline comments and a clang format issue.

Thu, Apr 30, 12:53 PM · Restricted Project
clayborg added inline comments to D78782: Add .debug_ranges support to the DWARF YAML..
Thu, Apr 30, 12:53 PM · Restricted Project
clayborg added inline comments to D79108: [lldb/CommandInterpreter] Move AutoHandleEvents and SpawnThread into CommandInterpreterRunOptions (NFC).
Thu, Apr 30, 12:21 PM · Restricted Project
clayborg accepted D79173: [Debuginfo][NFC] Avoid double calling of DWARFDie::find(DW_AT_name)..
Thu, Apr 30, 11:47 AM · debug-info, Restricted Project
clayborg added inline comments to D78782: Add .debug_ranges support to the DWARF YAML..
Thu, Apr 30, 1:12 AM · Restricted Project

Wed, Apr 29

clayborg updated the diff for D78782: Add .debug_ranges support to the DWARF YAML..

Removed whitespace that caused clang format violation.

Wed, Apr 29, 6:24 PM · Restricted Project
clayborg updated the diff for D78782: Add .debug_ranges support to the DWARF YAML..

Remove whitespace.

Wed, Apr 29, 6:24 PM · Restricted Project
clayborg added a comment to D78782: Add .debug_ranges support to the DWARF YAML..

Everything should be updated as requested. Let me know if there is anything else needed

Wed, Apr 29, 6:24 PM · Restricted Project
clayborg added inline comments to D79120: [lldb/API] Add RunCommandInterpreter overload that returns SBCommandInterpreterRunResults (NFC).
Wed, Apr 29, 5:50 PM · Restricted Project
clayborg requested changes to D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error..
Wed, Apr 29, 5:50 PM · Restricted Project
clayborg requested changes to D79120: [lldb/API] Add RunCommandInterpreter overload that returns SBCommandInterpreterRunResults (NFC).

Sorry, missed the fact that the new class had ivars. For ABI stability, we can't modify the number of ivars since we need the class size of SBCommandInterpreterRunResults to never change even if we add more things to it.

Wed, Apr 29, 5:50 PM · Restricted Project
clayborg accepted D79120: [lldb/API] Add RunCommandInterpreter overload that returns SBCommandInterpreterRunResults (NFC).

Yeah, anytime you see API calls that have many arguments it is a good idea to switch to this kind of API as adding accessors doesn't require us to change the API. We did this with SBTarget::Attach() and SBTarget::Launch() after having many variants of these functions...

Wed, Apr 29, 5:50 PM · Restricted Project
clayborg accepted D79108: [lldb/CommandInterpreter] Move AutoHandleEvents and SpawnThread into CommandInterpreterRunOptions (NFC).
Wed, Apr 29, 5:50 PM · Restricted Project
clayborg accepted D79123: [Debuginfo][NFC] findRecursively: Replace std::vector by SmallVector.
Wed, Apr 29, 5:17 PM · debug-info, Restricted Project
clayborg added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

Sounds like we have an approach to try! I would like to see solutions that are not WASM specific when possible.

Wed, Apr 29, 4:45 PM · Restricted Project
clayborg added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

While that idea has occurred to me too, I am not convinced it is a good one:

  • it replaces one odd dependency with another one. Why should a Process need to know how to evaluate a DWARF expression? Or even that DWARF exists for that matter? This seems totally unrelated to what other Process functions are doing currently...

But it is what people do in reality. DW_OP_low_user and DW_OP_high_user are ranges that are made available to people to customize their DWARF opcodes. If you don't handle it, you are hosed and can't show a variable location. And to make things worse, two different compilers could both use the same value in that range. So they made DWARF expressions customizable with no real attempt to make them function for different architectures. that is unless you standardize it and make a real opcode that gets accepted into DWARF. The kind of DWARF location opcode that is being used here could easily be generalized into a DW_OP_get_stack_variable with a bunch of args, but at some point you have to talk to someone that is in communication with the runtime of the thing you are debugging to get the answer. So I do believe asking the process for this is not out of scope.

I think the "at some point" part is very important here. I get how dwarf expressions are meant to be extended, and that doing that is tricky, but I don't think that automatically means that we should delegate that to a different process. There are various ways that could be implemented and the delegation could be performed at different levels. For example the DWARFExpression class could be made into a class hierarchy and we could have a subclass of it for each architecture with funny operations. Then the subclass would have enough knowledge about wasm to properly parse the expression and evaluate it (possibly by making additional queries to someone else) -- this is sort of what the current patch does, without the "subclass" part.

The problem I have with a function like EvaluateCustomDWARFExpressionOpcode is that it is completely unlike anything else that our process class needs to deal with. The Process deals with threads (and how to control them), memory (read/write) and, to a limited degree, with modules. It knows nothing about "stack frames" or "variables" or "dwarf expressions" -- these are concepts built on top of that. This becomes even more true if we start to talk about the gdb-remote protocol instead of the lldb Process abstraction.

  • I am not sure it even completely removes wasm knowledge from e.g. DWARFExpression -- the class would presumably still need to know how to parse this opcode.

It is true and this is another hole in the "people can extend DWARF easily" scenario. We need to know what opcode arguments are and that would need to be hard coded for now. But it wouldn't have to rely on anything except virtual function on the generic lldb_private::Process/Thread APIs. In this case as soon as we get an unknown opcode we would need to pass the DataExtractor and the offset into it so the process could extract the arguments.

Not only that, we might need to pass in the entire DWARF stack, in case the opcode depends on some of the stack arguments.

Wed, Apr 29, 4:45 PM · Restricted Project

Tue, Apr 28

clayborg added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

Could we just always use memory reading and have the address contain more info? Right now you have the top 32 bits for the module ID. Could it be something like:

Tue, Apr 28, 5:50 PM · Restricted Project
clayborg added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

Thanks for the explanations if everything WASM related. I now understand much better what you have.

Tue, Apr 28, 5:18 PM · Restricted Project
clayborg added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

It would be fine to ask the lldb_private::Process class to evaluate any unknown DWARF expression opcodes like DW_OP_WASM_location and return the result.

While that idea has occurred to me too, I am not convinced it is a good one:

  • it replaces one odd dependency with another one. Why should a Process need to know how to evaluate a DWARF expression? Or even that DWARF exists for that matter? This seems totally unrelated to what other Process functions are doing currently...
Tue, Apr 28, 4:45 PM · Restricted Project
clayborg updated the diff for D78782: Add .debug_ranges support to the DWARF YAML..
  • Updated yaml test case to encoded DW_AT_ranges with a base address entry to verify this works
  • Change test case to save yaml to a tmp object file and then run llvm-dwarfdump and obj2yaml on it
  • fixed all other issues mentioned in comments
Tue, Apr 28, 12:23 PM · Restricted Project
clayborg added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

I am adding all the pieces to this patch to make the whole picture clearer; I thought to add a piece at the time to simplify reviews, but probably it ended up making things more obscure. I can always split this patch later and I need to refactor everything anyway.

So, the idea is to use DWARF as debug info for Wasm, as it is already supported by LLVM and Emscripten. For this we introduced some time ago the plugin classes ObjectFileWasm, SymbolVendorWasm and DynamicLoaderWasmDYLD. However, WebAssembly is peculiarly different from the native targets. When source code is compiled to Wasm, Clang produces a module that contains Wasm bytecode (a bit like it happens with Java and C#) and the DWARF info refers to this bytecode.
The Wasm module then runs in a Wasm runtime. (It is also possible to AoT-compile Wasm to native, but this is outside the scope of this patch).

Therefore, LLDB cannot debug Wasm by just controlling the inferior process, but it needs to talk with the Wasm engine to query the Wasm engine state. For example, for backtrace, only the runtime knows what is the current call stack. Hence the idea of using the gdb-remote protocol: if a Wasm engine has a GDB stub LLDB can connect to it to start a debugging session and access its state.

Wasm execution is defined in terms of a stack machine. There are no registers (besides the implicit IP) and most Wasm instructions push/pop values into/from a virtual stack. Besides the stack the other possible stores are a set of parameters and locals defined in the function, a set of global variables defined in the module and the module memory, which is separated from the code address space.

The DWARF debug info to evaluate the value of variables is defined in terms of these constructs. For example, we can have something like this in DWARF:

0x00005a88:      DW_TAG_variable
                          DW_AT_location	(0x000006f3: 
                             [0x00000840, 0x00000850): DW_OP_WASM_location 0x0 +8, DW_OP_stack_value)
                          DW_AT_name	("xx")
                          DW_AT_type	(0x00002b17 "float")
                          […]

Which says that on that address range the value of ‘xx’ can be evaluated as the content of the 8th local. Here DW_OP_WASM_location is a Wasm-specific opcode, with two args, the first defines the store (0: Local, 1: Global, 2: the operand stack) and the index in that store. In most cases the value of the variable could be retrieved from the Wasm memory instead.

Tue, Apr 28, 12:29 AM · Restricted Project

Mon, Apr 27

clayborg added a comment to D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error..
In D78825#2002598, @vsk wrote:

Can we delete an override of SBDebugger::RunCommandInterpreter, or are they all part of the stable API? If we can, it'd be nice to get rid of the one with 6 args.

Mon, Apr 27, 11:57 PM · Restricted Project
clayborg accepted D78924: [DebugInfo] Fix crash caused by unhandled error..
Mon, Apr 27, 11:57 PM · Restricted Project

Apr 27 2020

clayborg added a comment to D78782: Add .debug_ranges support to the DWARF YAML..

Does this patch add support in yaml2obj for debug_ranges (I get a bit lost as to what point this happens)? If it is newly supported, it should be tested in a yaml2obj test too.

Apr 27 2020, 7:24 PM · Restricted Project

Apr 26 2020

clayborg added a comment to D78874: [clang] Add vendor identity for Hygon Dhyana processor.

I am not sure I am the right person to review? I work on LLDB and LLVM mostly.

Apr 26 2020, 2:52 PM · Restricted Project
clayborg added a comment to D78839: [lldb-vscode] Add an option for loading core files.

You might look around for a core file in another test location and be able to use that. Functionality looks good to me. This could have been done with attachCommands before, but it is nice to have a built in and supported way to do this.

Apr 26 2020, 2:52 PM · Restricted Project
clayborg added a comment to D76085: [DWARFLinker][dsymutil][NFC] add section index into address range..

lgtm now. Probably best to have someone that worked on llvm-dsymutil do the final accept on this.

Apr 26 2020, 2:52 PM · debug-info, Restricted Project
clayborg updated the diff for D78782: Add .debug_ranges support to the DWARF YAML..

Updated things labath commented on by renaming Descriptors to Entries.

Apr 26 2020, 2:20 PM · Restricted Project
clayborg added inline comments to D78782: Add .debug_ranges support to the DWARF YAML..
Apr 26 2020, 2:20 PM · Restricted Project
clayborg added a comment to D78801: [LLDB] Add class WasmProcess for WebAssembly debugging.

So a few things here. It doesn't seem like it is necessary to create the WasmProcessGDBRemote and IWasmProcess. It would be fine to extend the current ProcessGDBRemote and ThreadGDBRemote classes. The whole reason seems to be that the variables (globals, locals, etc) are fetched through the GDB server API and that doesn't happen for other users of the protocol where this information is fetched via the debug info. Is this correct? You seem to have debug info and DWARF (since you mentioned a new DWARF expression opcode), so how do variables actually work? Do you use debug info? What info for variables do you need to fetch from the API?

Apr 26 2020, 1:48 PM · Restricted Project

Apr 23 2020

clayborg created D78782: Add .debug_ranges support to the DWARF YAML..
Apr 23 2020, 7:34 PM · Restricted Project
clayborg added a comment to D76085: [DWARFLinker][dsymutil][NFC] add section index into address range..

Sorry about the delay, I had comments on this but I never submitted them!...

Apr 23 2020, 1:00 PM · debug-info, Restricted Project
clayborg added a comment to D78672: [Debuginfo] Remove redundand variable from getAttributeValue().

Thinking from the compiler side: it would be really cool if the compiler could emit all variable sized DWARF attributes at the end of each DIE to maximize how many constant attribute values accesses we could do (if we implement the O(1) access to the value perf optimization in the debug info).

Apr 23 2020, 12:28 PM · debug-info, Restricted Project
clayborg accepted D78672: [Debuginfo] Remove redundand variable from getAttributeValue().

Yes, much cleaner! I look forward to seeing any perf optimizations in the future if they prove to be faster. It really depends on how many workflows directly access attributes. It is probably quite common for symbolication where it will look for low and high pc and name.

Apr 23 2020, 12:28 PM · debug-info, Restricted Project

Apr 22 2020

clayborg accepted D78489: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables.

Sounds like a win then, as long as we don't get slower I am fine with this. I was guessing that line tables might be faster because it is generally very compressed and compact compared to debug info, but thanks for verifying.

Might be worth checking the memory consumption of LLDB quickly too with DW_AT_ranges compiled out and just make sure we don't take up too much extra memory.

I've done a similar benchmark to the last one, but measured memory usage ("RssAnon" as reported by linux). One notable difference is that I

Currently (information retrieved from DW_AT_ranges) we use about ~330 MB of memory. If I switch to dwarf dies as the source, the memory goes all the way to 2890 MB. This number is suspiciously large -- it either means that our die freeing is not working properly, or that glibc is very bad at releasing memory back to the OS. Given the magnitude of the increase, i think it's a little bit of both. With line tables as the source the memory usage is 706 MB. It's an increase from 330, but definitely smaller than 2.8 GB. (the number 330 is kind of misleading here since we're not considering removing that option -- it will always be used if it is available).

Apr 22 2020, 4:20 PM · Restricted Project
clayborg added a comment to D78672: [Debuginfo] Remove redundand variable from getAttributeValue().

So my only issue is adding a comment so people don't remove the code that quickly checks if this abbreviation has the attribute. This is a quick check that doesn't require manually skipping each form size only to discover that we don't have the form.

Apr 22 2020, 4:20 PM · debug-info, Restricted Project

Apr 21 2020

clayborg added a comment to D78489: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables.

Sounds like a win then, as long as we don't get slower I am fine with this. I was guessing that line tables might be faster because it is generally very compressed and compact compared to debug info, but thanks for verifying.

Apr 21 2020, 6:25 PM · Restricted Project
clayborg added a comment to D78588: [lldb/Core] Don't crash in GetSoftwareBreakpointTrapOpcode for unknown triples.

None of this is exposed through SBPlatform right? No way to test this?

Apr 21 2020, 4:48 PM · Restricted Project

Apr 20 2020

clayborg added a comment to D78489: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables.

So it looks like there are bugs in the "llvm-dwarfdump --verify". The blurb I posted above clearly has the function's address range contained in it, sorry for the false alarm. I have been quite a few problems with DWARF with LTO and other post production linkers. The llvm-dwarfdump might be assuming that the address ranges in DW_AT_ranges are sorted. I will work on a fix for this if my llvm-dwarfdump was from top of tree.

Apr 20 2020, 10:46 PM · Restricted Project
clayborg added a comment to D78489: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables.

And this one binary had 115 examples of this:

$ llvm-dwarfdump --verify libIGL.so | grep "DIE address ranges are not contained in its parent" | wc -l
    115
Apr 20 2020, 10:13 PM · Restricted Project
clayborg added a comment to D78489: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables.

Sorry I might have not understood this patch's actual implementation. I thought we were switching to trusting DW_AT_ranges, which seems we are already doing. Let me read the patch code a bit more carefully, not just quickly reading the description...

Apr 20 2020, 10:13 PM · Restricted Project
clayborg added a comment to D78489: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables.

And also it is worth noting that just because new compilers might generate this information correctly, it doesn't mean LLDB won't be used to try and load older debug info from compilers that don't. LTO can also greatly affect the reliability of this information. And many other code post production tools often ruin this information when they move things around. The tools know to modify the information for the DW_TAG_subprogram DIE, but they very often don't even try to update the compile unit's DW_AT_ranges.

Apr 20 2020, 10:13 PM · Restricted Project
clayborg requested changes to D78489: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables.

I see plenty of examples daily, from clang version 7, where this happens. The first binary I tried to verify after seeing this patch, I found this error. Dump is below. This compile unit also shows what happens when the linker sets every function that was dead stripped to address zero: we end up with many functions at address zero. What happens if address zero is a real address? Then we end up with the first function that got dead stripped that was large enough to contain the address we are trying to lookup claiming to own this address. So I would vote to NOT change LLDB.

Apr 20 2020, 10:13 PM · Restricted Project
clayborg added a comment to D78489: [lldb/DWARF] Trust CU DW_AT_low/high_pc information when building address tables.

So if llvm is relying on this, we should change llvm. Symbolication will fail using LLVM's DWARF parser if it is using this information for anything real.

Apr 20 2020, 10:13 PM · Restricted Project

Apr 14 2020

clayborg requested changes to D78077: Fix bug in UnwindAssemblyInstEmulation with fp-using codegen and mid-function epilogues.

If you test worked, then there is something wrong with this test? See inline comment for copy and paste error

Apr 14 2020, 3:09 AM · Restricted Project

Apr 12 2020

clayborg removed a reviewer for D77790: [NFC] Add a test for the inferior memory cache (mainly L1): clayborg.
Apr 12 2020, 8:18 PM · Restricted Project
clayborg removed a reviewer for D77765: Fix incorrect L1 inferior memory cache flushing: clayborg.
Apr 12 2020, 8:18 PM · Restricted Project

Apr 10 2020

clayborg added a comment to D77790: [NFC] Add a test for the inferior memory cache (mainly L1).

Regarding the callback idea, I have bad experience with callbacks because they break if the code is not crafted for re-entrancy and they are much harder to understand. That change feels out of scope for just adding a test and fixing an unrelated bug.

Apr 10 2020, 4:09 PM · Restricted Project

Apr 9 2020

clayborg added a comment to D77790: [NFC] Add a test for the inferior memory cache (mainly L1).

Mostly good, but it seems weird to supply the cache line size when calling the MemoryCache::Clear() function. We also don't seem to be catching updates to the cache line size property and invalidating the cache when and only when the property is modified, but we seem to be relying on calls to Clear() to do this when we stop? It would be nice to clean this up before submitting just because this change forces this now out of place looking setting to be passed along. ProcessProperties::ProcessProperties() has a place where you can hook in and call a function when the property changes:

Apr 9 2020, 5:39 PM · Restricted Project

Apr 8 2020

clayborg added a comment to D77765: Fix incorrect L1 inferior memory cache flushing.

I am not a pro at the gtest stuff, but this was very hard to follow and figure out what these tests are doing.

Apr 8 2020, 9:02 PM · Restricted Project

Apr 6 2020

clayborg added a comment to D77444: [commands] Support autorepeat in SBCommands.

The biggest issue is maintaining the API. We can't add anything to SBCommandPluginInterface

If we're going to be adding a new inheritable class for this feature, I'd recommend adding about half a dozen or so dummy virtual methods to it so we reserve vtable space for future expansion.

Apr 6 2020, 11:57 AM · Restricted Project
clayborg accepted D77295: [lldb/Core] Fix a race in the Communication class.
Apr 6 2020, 11:57 AM · Restricted Project

Apr 5 2020

clayborg added a comment to D77444: [commands] Support autorepeat in SBCommands.

I was thinking if auto repeat was enabled that the DoExecute would just get called again with nothing and then the plug-in could maintain any repeat commands without needing to add anything... Glad you chimed in!

Apr 5 2020, 10:25 PM · Restricted Project
clayborg added a comment to D77444: [commands] Support autorepeat in SBCommands.

The biggest issue is maintaining the API. We can't add anything to SBCommandPluginInterface

Apr 5 2020, 10:25 PM · Restricted Project

Apr 3 2020

clayborg added a comment to D77444: [commands] Support autorepeat in SBCommands.

LGTM. Pavel?

Apr 3 2020, 6:26 PM · Restricted Project
clayborg added a comment to D77326: 1/2: [nfc] [lldb] Unindent code.

Does anyone know why harbormaster is useless?

Apr 3 2020, 3:11 PM · Restricted Project