LGTM.

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?

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

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?

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

Much better!

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

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.

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

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.

I updated the description to better explain the fix.

In D79962#2037671, @dblaikie wrote:

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?

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)

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.

In D79757#2036618, @aadsm wrote:

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

Fixed buildbots with:

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?

nice catch!

In D79811#2035078, @shafik wrote:

In D79811#2034842, @clayborg wrote:

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).

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

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

In D79614#2030692, @jasonmolenda wrote:

Thanks for the feedback.

In D79614#2029157, @labath wrote:

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.

In D79614#2027869, @jasonmolenda wrote:

In D79614#2027861, @clayborg wrote:

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.

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.

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

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?

LGTM now. Pavel?

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/

Fixed inline comments and a clang format issue.

Removed whitespace that caused clang format violation.

Remove whitespace.

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

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.

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...

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

In D78801#2009917, @labath wrote:

In D78801#2009048, @clayborg wrote:

In D78801#2007795, @labath wrote:

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.

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:

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

In D78801#2007795, @labath wrote:

In D78801#2007083, @clayborg wrote:

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...

• 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

In D78801#2004501, @paolosev wrote:

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.

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.

In D78782#2004682, @jhenderson wrote:

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.

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

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.

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

Updated things labath commented on by renaming Descriptors to Entries.

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?

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

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).

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.

In D78489#1996834, @labath wrote:

In D78489#1995837, @clayborg wrote:

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).

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.

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.

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

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.

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

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...

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.

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.

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.

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

In D77790#1974047, @jarin wrote:

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.

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:

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

In D77444#1963354, @labath wrote:

In D77444#1962952, @clayborg wrote:

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.

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!

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

LGTM. Pavel?

Does anyone know why harbormaster is useless?