[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

First off, thank you for working on this. `debuginfod` has been on my radar 
since support was added to LLVM and I was curious at which point someone was 
going to add support for it to LLDB. I wasn't super familiar with what exactly 
it provides, and in case others here aren't either, I found the following 
documentation very helpful: https://llvm.org/doxygen/Debuginfod_8h.html. 
TL;DR: it gives you a way to get sources, (symbol rich) executables and debug 
info files. 

The functionality `debuginfod` offers seems very similar to `dsymForUUID` (see 
https://lldb.llvm.org/use/symbols.html). We have series of functions such as 
`LocateExecutableObjectFile` and `LocateExecutableSymbolFile` in 
`LocateSymbolFile.h` that abstract over this. It seems appropriate that we use 
the same abstractions for `debuginfod` which avoids the special casing this 
patch introduces and a lot of things will "just work". 

The one caveat is that the current implementation of is really tied to a 
platform. All the `dsymForUUID` stuff is implemented in 
`LocateSymbolFileMacOSX.cpp`. I think we might need to move this to a Plugin 
model where we can have multiple implementations. The plugin name 
`SymbolVendor` is already taken so I would call this the `SymbolServer` plugin. 
Converting the current model to a plugin should be done in separate patch and 
myself or other Apple folks can make sure this doesn't break the dsymForUUID 
paths (we have some tests but not enough given how critical this is for us). 
With that done, it should be trivial to add a plugin implementation that calls 
into `debuginfod`

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Jonas Devlieghere via lldb-commits]

@@ -4892,6 +4894,21 @@ void TargetProperties::SetDebugUtilityExpression(bool 
debug) {
   SetPropertyAtIndex(idx, debug);
 }
 
+Args TargetProperties::GetDebugInfoDURLs() const {
+  Args urls;
+  m_collection_sp->GetPropertyAtIndexAsArgs(ePropertyDebugInfoDURLs, urls);
+  return urls;
+}
+
+void TargetProperties::DebugInfoDURLsChangedCallback() {
+  Args urls = GetDebugInfoDURLs();
+  llvm::SmallVector dbginfod_urls;
+  std::transform(urls.begin(), urls.end(), dbginfod_urls.end(),
+ [](const auto ) { return obj.ref(); });
+  llvm::setDefaultDebuginfodUrls(dbginfod_urls);

JDevlieghere wrote:

Should this be a debugger (rather than a target) setting? In practice, is it 
likely to have multiple instances running or this more of a global resource 
(like dsymForUUID)?

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Greg Clayton via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.

clayborg wrote:

s/class for you command/class for your command/

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Greg Clayton via lldb-commits]

https://github.com/clayborg edited 
https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Greg Clayton via lldb-commits]

https://github.com/clayborg commented:

I like this idea. Since python is so dynamic, I wonder if we can just add extra 
metadata to the standard "argparse" objects so that users can just write their 
stuff in the most pythonic way possible using `import argparse` and then adding 
some extra metadata that lldb can access. For example something like:

```
$ python3
Python 3.8.9 (default, Jul 27 2021, 02:53:04) 
[Clang 7.1.0 (tags/RELEASE_710/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> ap = argparse.ArgumentParser()
>>> v = ap.add_argument('-v')
>>> print(v)
_StoreAction(option_strings=['-v'], dest='v', nargs=None, const=None, 
default=None, type=None, choices=None, help=None, metavar=None)
>>> print(type(v))

>>> v.lldb_type = lldb.eArgTypeBoolean
>>> v.lldb_type
lldb.eArgTypeBoolean
```
Then users can use the standard `argparse` module and just add a bit of extra 
metadata to it that LLDB can then access when needed. This would remove the 
need for a custom LLDBOVParser class.


https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[via lldb-commits]

@@ -4892,6 +4894,21 @@ void TargetProperties::SetDebugUtilityExpression(bool 
debug) {
   SetPropertyAtIndex(idx, debug);
 }
 
+Args TargetProperties::GetDebugInfoDURLs() const {
+  Args urls;
+  m_collection_sp->GetPropertyAtIndexAsArgs(ePropertyDebugInfoDURLs, urls);
+  return urls;
+}
+
+void TargetProperties::DebugInfoDURLsChangedCallback() {
+  Args urls = GetDebugInfoDURLs();
+  llvm::SmallVector dbginfod_urls;
+  std::transform(urls.begin(), urls.end(), dbginfod_urls.end(),
+ [](const auto ) { return obj.ref(); });
+  llvm::setDefaultDebuginfodUrls(dbginfod_urls);

jimingham wrote:

What happens here if I have two targets that want to use different URL's?

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Greg Clayton via lldb-commits]

https://github.com/clayborg edited 
https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Greg Clayton via lldb-commits]

clayborg wrote:

> I would like to see a new setting added to lldb that should be the default 
> way to enable the debuginfod support. Just adding something to 
> `lldb/source/Target/TargetProperties.td` like:
> 
> ```
>   def DebuginfodURLs: Property<"debuginfod-urls", "Args">,
> DefaultStringValue<"">,
> Desc<"A list of debuginfod URLs that will be linearly called to search 
> for debug info.">;
> ```
> 
> Doesn't need to live in "target.*" though.

If this was added in target, then we could do:
```
(lldb) settings set target.debuginfod-urls http://url1 http://url2 http://url3
```

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Greg Clayton via lldb-commits]

https://github.com/clayborg commented:

I would like to see a new setting added to lldb that should be the default way 
to enable the debuginfod support. Just adding something to 
`lldb/source/Target/TargetProperties.td` like:
```
  def DebuginfodURLs: Property<"debuginfod-urls", "Args">,
DefaultStringValue<"">,
Desc<"A list of debuginfod URLs that will be linearly called to search for 
debug info.">;
```
Doesn't need to live in "target.*" though.


https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Will Hawkins via lldb-commits]

hawkinsw wrote:

@jimingham Looks like great work -- I hope my few comments were helpful!

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Will Hawkins via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that. 
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types.  Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.
+@staticmethod
+def to_bool(in_value):
+error = True
+value = False
+low_in = in_value.lower()
+if low_in == "yes" or low_in == "true" or low_in == "1":
+value = True
+error = False
+
+if not value and low_in == "no" or low_in == "false" or low_in == "0":
+value = False
+error = False
+
+return (value, error)
+
+@staticmethod
+def to_int(in_value):
+#FIXME: Not doing errors yet...
+return (int(in_value), False)
+
+def to_unsigned(in_value):
+# FIXME: find an unsigned converter...
+# And handle errors.
+return (int(in_value), False)
+
+translators = {
+lldb.eArgTypeBoolean : to_bool,
+lldb.eArgTypeBreakpointID : to_unsigned,
+lldb.eArgTypeByteSize : to_unsigned,
+lldb.eArgTypeCount : to_unsigned,
+lldb.eArgTypeFrameIndex : to_unsigned,
+lldb.eArgTypeIndex : to_unsigned,
+lldb.eArgTypeLineNum : to_unsigned,
+lldb.eArgTypeNumLines : to_unsigned,
+lldb.eArgTypeNumberPerLine : to_unsigned,
+lldb.eArgTypeOffset : to_int,
+lldb.eArgTypeThreadIndex : to_unsigned,
+lldb.eArgTypeUnsignedInteger : to_unsigned,
+lldb.eArgTypeWatchpointID : to_unsigned,
+lldb.eArgTypeColumnNum : to_unsigned,
+lldb.eArgTypeRecognizerID : to_unsigned,
+lldb.eArgTypeTargetID : to_unsigned,
+lldb.eArgTypeStopHookID : to_unsigned
+}
+
+@classmethod
+def translate_value(cls, value_type, value):
+error = False
+try:
+return cls.translators[value_type](value)
+except KeyError:
+# If we don't have a translator, return the string value.
+return (value, False)
+
+# FIXME: would this be better done on the C++ side?
+# The common completers are missing some useful ones.
+# For instance there really should be a common Type completer
+# And an "lldb command name" completer.
+completion_table = {
+lldb.eArgTypeAddressOrExpression : lldb.eVariablePathCompletion,
+lldb.eArgTypeArchitecture : lldb.eArchitectureCompletion,
+lldb.eArgTypeBreakpointID : lldb.eBreakpointCompletion,
+lldb.eArgTypeBreakpointIDRange : lldb.eBreakpointCompletion,
+lldb.eArgTypeBreakpointName : lldb.eBreakpointNameCompletion,
+lldb.eArgTypeClassName : lldb.eSymbolCompletion,
+lldb.eArgTypeDirectoryName : lldb.eDiskDirectoryCompletion,
+lldb.eArgTypeExpression : lldb.eVariablePathCompletion,
+lldb.eArgTypeExpressionPath : lldb.eVariablePathCompletion,
+lldb.eArgTypeFilename : lldb.eDiskFileCompletion,
+lldb.eArgTypeFrameIndex : lldb.eFrameIndexCompletion,
+lldb.eArgTypeFunctionName : lldb.eSymbolCompletion,
+lldb.eArgTypeFunctionOrSymbol : 

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Will Hawkins via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that. 
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types.  Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.
+@staticmethod
+def to_bool(in_value):
+error = True
+value = False
+low_in = in_value.lower()
+if low_in == "yes" or low_in == "true" or low_in == "1":
+value = True
+error = False
+
+if not value and low_in == "no" or low_in == "false" or low_in == "0":
+value = False
+error = False
+
+return (value, error)
+
+@staticmethod
+def to_int(in_value):
+#FIXME: Not doing errors yet...
+return (int(in_value), False)
+
+def to_unsigned(in_value):
+# FIXME: find an unsigned converter...
+# And handle errors.
+return (int(in_value), False)
+
+translators = {
+lldb.eArgTypeBoolean : to_bool,
+lldb.eArgTypeBreakpointID : to_unsigned,
+lldb.eArgTypeByteSize : to_unsigned,
+lldb.eArgTypeCount : to_unsigned,
+lldb.eArgTypeFrameIndex : to_unsigned,
+lldb.eArgTypeIndex : to_unsigned,
+lldb.eArgTypeLineNum : to_unsigned,
+lldb.eArgTypeNumLines : to_unsigned,
+lldb.eArgTypeNumberPerLine : to_unsigned,
+lldb.eArgTypeOffset : to_int,
+lldb.eArgTypeThreadIndex : to_unsigned,
+lldb.eArgTypeUnsignedInteger : to_unsigned,
+lldb.eArgTypeWatchpointID : to_unsigned,
+lldb.eArgTypeColumnNum : to_unsigned,
+lldb.eArgTypeRecognizerID : to_unsigned,
+lldb.eArgTypeTargetID : to_unsigned,
+lldb.eArgTypeStopHookID : to_unsigned
+}
+
+@classmethod
+def translate_value(cls, value_type, value):
+error = False
+try:
+return cls.translators[value_type](value)
+except KeyError:
+# If we don't have a translator, return the string value.
+return (value, False)
+
+# FIXME: would this be better done on the C++ side?
+# The common completers are missing some useful ones.
+# For instance there really should be a common Type completer
+# And an "lldb command name" completer.
+completion_table = {
+lldb.eArgTypeAddressOrExpression : lldb.eVariablePathCompletion,
+lldb.eArgTypeArchitecture : lldb.eArchitectureCompletion,
+lldb.eArgTypeBreakpointID : lldb.eBreakpointCompletion,
+lldb.eArgTypeBreakpointIDRange : lldb.eBreakpointCompletion,
+lldb.eArgTypeBreakpointName : lldb.eBreakpointNameCompletion,
+lldb.eArgTypeClassName : lldb.eSymbolCompletion,
+lldb.eArgTypeDirectoryName : lldb.eDiskDirectoryCompletion,
+lldb.eArgTypeExpression : lldb.eVariablePathCompletion,
+lldb.eArgTypeExpressionPath : lldb.eVariablePathCompletion,
+lldb.eArgTypeFilename : lldb.eDiskFileCompletion,
+lldb.eArgTypeFrameIndex : lldb.eFrameIndexCompletion,
+lldb.eArgTypeFunctionName : lldb.eSymbolCompletion,
+lldb.eArgTypeFunctionOrSymbol : 

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Will Hawkins via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  

hawkinsw wrote:

```suggestion
You can access the option values using the varname you passed in when defining 
the option.  
```

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that. 
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types.  Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.
+@staticmethod
+def to_bool(in_value):
+error = True
+value = False
+low_in = in_value.lower()
+if low_in == "yes" or low_in == "true" or low_in == "1":
+value = True
+error = False
+
+if not value and low_in == "no" or low_in == "false" or low_in == "0":
+value = False
+error = False
+
+return (value, error)
+
+@staticmethod
+def to_int(in_value):
+#FIXME: Not doing errors yet...
+return (int(in_value), False)
+
+def to_unsigned(in_value):
+# FIXME: find an unsigned converter...
+# And handle errors.
+return (int(in_value), False)
+
+translators = {
+lldb.eArgTypeBoolean : to_bool,
+lldb.eArgTypeBreakpointID : to_unsigned,
+lldb.eArgTypeByteSize : to_unsigned,
+lldb.eArgTypeCount : to_unsigned,
+lldb.eArgTypeFrameIndex : to_unsigned,
+lldb.eArgTypeIndex : to_unsigned,
+lldb.eArgTypeLineNum : to_unsigned,
+lldb.eArgTypeNumLines : to_unsigned,
+lldb.eArgTypeNumberPerLine : to_unsigned,
+lldb.eArgTypeOffset : to_int,
+lldb.eArgTypeThreadIndex : to_unsigned,
+lldb.eArgTypeUnsignedInteger : to_unsigned,
+lldb.eArgTypeWatchpointID : to_unsigned,
+lldb.eArgTypeColumnNum : to_unsigned,
+lldb.eArgTypeRecognizerID : to_unsigned,
+lldb.eArgTypeTargetID : to_unsigned,
+lldb.eArgTypeStopHookID : to_unsigned
+}
+
+@classmethod
+def translate_value(cls, value_type, value):
+error = False
+try:
+return cls.translators[value_type](value)
+except KeyError:
+# If we don't have a translator, return the string value.
+return (value, False)

bulbazord wrote:

The 'False' is unused here, just return `value`

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that. 
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types.  Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.
+@staticmethod
+def to_bool(in_value):
+error = True
+value = False
+low_in = in_value.lower()
+if low_in == "yes" or low_in == "true" or low_in == "1":
+value = True
+error = False
+
+if not value and low_in == "no" or low_in == "false" or low_in == "0":
+value = False
+error = False
+
+return (value, error)
+
+@staticmethod
+def to_int(in_value):
+#FIXME: Not doing errors yet...
+return (int(in_value), False)
+
+def to_unsigned(in_value):
+# FIXME: find an unsigned converter...
+# And handle errors.
+return (int(in_value), False)

bulbazord wrote:

What's the difference between these two? Might be worth changing `to_int` to 
`to_signed`.

Also, it looks like `to_unsigned` should be decorated with `@staticmethod`

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that. 
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types.  Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.
+@staticmethod
+def to_bool(in_value):
+error = True
+value = False
+low_in = in_value.lower()
+if low_in == "yes" or low_in == "true" or low_in == "1":
+value = True
+error = False
+
+if not value and low_in == "no" or low_in == "false" or low_in == "0":

bulbazord wrote:

Empty string is false-y, this might not do what you want in that case.

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -96,7 +96,8 @@ function(finish_swig_python swig_target 
lldb_python_bindings_dir lldb_python_tar
 ${lldb_python_target_dir}
 "utils"
 FILES "${LLDB_SOURCE_DIR}/examples/python/in_call_stack.py"
-  "${LLDB_SOURCE_DIR}/examples/python/symbolication.py")
+  "${LLDB_SOURCE_DIR}/examples/python/symbolication.py"
+  "${LLDB_SOURCE_DIR}/examples/python/parsed_cmd.py")

bulbazord wrote:

Please sort these

Also, I wonder if we should put the `)` on a separate line for code archaeology 
sake?

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  

bulbazord wrote:

```suggestion
def __call__(self, debugger, args_list, exe_ctx, result):

The arguments will be in a list of strings.  
```

Python doesn't really have arrays

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.

bulbazord wrote:

```suggestion
Look up your element by varname and check the "_value_set" element.
```
What is 'varname'? And check the `_value_set` element how? Is it a bool?

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -831,6 +831,37 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
   return true;
 }
 
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger, 
lldb_private::StructuredDataImpl _impl,
+lldb_private::CommandReturnObject _retobj,
+lldb::ExecutionContextRefSP exe_ctx_ref_sp) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = self.ResolveName("__call__");

bulbazord wrote:

Can we add some other safety checks to `pfunc` other than if it's allocated? 
Something like "It takes the number of arguments expected"?

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.

bulbazord wrote:

```suggestion
The way to use it is to make a class for your command that inherits from 
ParsedCommandBase.
```

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument

bulbazord wrote:

```suggestion
  self.get_parser().add_argument()
```

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation

bulbazord wrote:

```suggestion
option definition and fetch option values for the current invocation
```

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -831,6 +831,37 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
   return true;
 }
 
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger, 
lldb_private::StructuredDataImpl _impl,
+lldb_private::CommandReturnObject _retobj,
+lldb::ExecutionContextRefSP exe_ctx_ref_sp) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = self.ResolveName("__call__");
+
+  if (!pfunc.IsAllocated())
+return false;
+
+  auto cmd_retobj_arg = SWIGBridge::ToSWIGWrapper(cmd_retobj);

bulbazord wrote:

Why are you doing this here instead of in the invocation of `pfunc` below like 
you do for all the other arguments?

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -831,6 +831,37 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
   return true;
 }
 
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger, 
lldb_private::StructuredDataImpl _impl,
+lldb_private::CommandReturnObject _retobj,
+lldb::ExecutionContextRefSP exe_ctx_ref_sp) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = self.ResolveName("__call__");
+
+  if (!pfunc.IsAllocated())
+return false;
+
+  auto cmd_retobj_arg = SWIGBridge::ToSWIGWrapper(cmd_retobj);
+
+  // FIXME:
+  // I wanted to do something like:
+  // size_t num_elem = args.size();
+  // PythonList my_list(num_elem);
+  // for (const char *elem : args)
+  //   my_list.append(PythonString(elem);
+  //
+  // and then pass my_list to the pfunc, but that crashes somewhere
+  // deep in Python for reasons that aren't clear to me.

bulbazord wrote:

Do you have a backtrace or other useful info here? It would be useful to 
actually write out what you want the code to be instead of this so future 
contributors can reproduce the crash.

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

https://github.com/bulbazord commented:

I did an initial pass over your patch but I didn't read the python tests yet

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -831,6 +831,37 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
   return true;
 }
 
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger, 
lldb_private::StructuredDataImpl _impl,
+lldb_private::CommandReturnObject _retobj,
+lldb::ExecutionContextRefSP exe_ctx_ref_sp) {
+
+  PyErr_Cleaner py_err_cleaner(true);
+
+  PythonObject self(PyRefType::Borrowed, implementor);
+  auto pfunc = self.ResolveName("__call__");
+
+  if (!pfunc.IsAllocated())
+return false;

bulbazord wrote:

Can we update the `CommandReturnObject` with useful feedback about what failed? 
The bool return value is super opaque.

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that. 
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types.  Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.

bulbazord wrote:

Instead of pushing a conversion error string, why not raise an exception? It's 
the pythonic way to do things. You won't have to return 2 bools then

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that. 
+"""
+import inspect
+import lldb
+import sys
+
+class LLDBOVParser:
+def __init__(self):
+self.options_array = []
+self.args_array = []
+
+# Some methods to translate common value types.  Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.
+# FIXME: Need a way to push the conversion error string back to lldb.
+@staticmethod
+def to_bool(in_value):
+error = True
+value = False
+low_in = in_value.lower()
+if low_in == "yes" or low_in == "true" or low_in == "1":

bulbazord wrote:

Might be useful to recognize 'y' as well

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -831,6 +831,37 @@ bool 
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
   return true;
 }
 
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger, 
lldb_private::StructuredDataImpl _impl,

bulbazord wrote:

Spelling mistake: `implementor` -> `implementer`

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

@@ -0,0 +1,315 @@
+"""
+This module implements a couple of utility classes to make writing
+lldb parsed commands more Pythonic.
+The way to use it is to make a class for you command that inherits from 
ParsedCommandBase.
+That will make an LLDBOVParser which you will use for your
+option definition, and to fetch option values for the current invocation
+of your command.  Access to the OV parser is through:
+
+ParsedCommandBase.get_parser()
+
+Next, implement setup_command_definition in your new command class, and call:
+
+  self.get_parser().add_option
+
+to add all your options.  The order doesn't matter for options, lldb will sort 
them
+alphabetically for you when it prints help.
+
+Similarly you can define the arguments with:
+
+  self.get_parser.add_argument
+
+at present, lldb doesn't do as much work as it should verifying arguments, it 
pretty
+much only checks that commands that take no arguments don't get passed 
arguments.
+
+Then implement the execute function for your command as:
+
+def __call__(self, debugger, args_array, exe_ctx, result):
+
+The arguments will be in a python array as strings.  
+
+You can access the option values using varname you passed in when defining the 
option.  
+If you need to know whether a given option was set by the user or not, you can 
retrieve 
+the option definition array with:
+
+  self.get_options_definition()
+
+look up your element by varname and check the "_value_set" element.
+
+There are example commands in the lldb testsuite at:
+
+llvm-project/lldb/test/API/commands/command/script/add/test_commands.py
+
+FIXME: I should make a convenient wrapper for that. 

bulbazord wrote:

Convenient wrapper for what?

https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to define a Python based command that uses CommandObjectParsed (PR #70734)

[Alex Langford via lldb-commits]

https://github.com/bulbazord edited 
https://github.com/llvm/llvm-project/pull/70734
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [llvm] [lldb] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Alex Langford via lldb-commits]

@@ -48,6 +48,7 @@ add_lldb_library(lldbSymbol NO_PLUGIN_DEPENDENCIES
 lldbHost
 lldbTarget
 lldbUtility
+LLVMDebuginfod

bulbazord wrote:

Should this be in `LINK_COMPONENTS`?

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Alex Langford via lldb-commits]

@@ -396,8 +398,22 @@ Symbols::LocateExecutableSymbolFile(const ModuleSpec 
_spec,
   }
 }
   }
-
-  return LocateExecutableSymbolFileDsym(module_spec);
+  FileSpec dsym_bundle = LocateExecutableSymbolFileDsym(module_spec);
+  if (dsym_bundle)
+return dsym_bundle;

bulbazord wrote:

```suggestion
  if (FileSpec dsym_bundle = LocateExecutableSymbolFileDsym(module_spec))
return dsym_bundle;
```

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Alex Langford via lldb-commits]

@@ -396,8 +398,22 @@ Symbols::LocateExecutableSymbolFile(const ModuleSpec 
_spec,
   }
 }
   }
-
-  return LocateExecutableSymbolFileDsym(module_spec);
+  FileSpec dsym_bundle = LocateExecutableSymbolFileDsym(module_spec);
+  if (dsym_bundle)
+return dsym_bundle;
+
+  // If we didn't find anything by looking locally, let's try Debuginfod.
+  if (module_uuid.IsValid() && llvm::canUseDebuginfod()) {
+llvm::object::BuildID build_id(module_uuid.GetBytes());
+llvm::Expected result =
+llvm::getCachedOrDownloadDebuginfo(build_id);
+if (result)
+  return FileSpec(*result);
+// An error is just fine, here...
+consumeError(result.takeError());

bulbazord wrote:

Generally I agree with this but we should probably be careful, if there's an 
issue with searching then maybe we'll get hit with thousands of log messages 
about the failure.

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Alex Langford via lldb-commits]

@@ -4892,6 +4894,21 @@ void TargetProperties::SetDebugUtilityExpression(bool 
debug) {
   SetPropertyAtIndex(idx, debug);
 }
 
+Args TargetProperties::GetDebugInfoDURLs() const {
+  Args urls;
+  m_collection_sp->GetPropertyAtIndexAsArgs(ePropertyDebugInfoDURLs, urls);
+  return urls;
+}
+
+void TargetProperties::DebugInfoDURLsChangedCallback() {
+  Args urls = GetDebugInfoDURLs();
+  llvm::SmallVector dbginfod_urls;
+  std::transform(urls.begin(), urls.end(), dbginfod_urls.end(),
+ [](const auto ) { return obj.ref(); });

bulbazord wrote:

suggestion: `llvm::transform` will allow you to write just `urls` instead of 
`urls.begin(), urls.end()`

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Alex Langford via lldb-commits]

https://github.com/bulbazord edited 
https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [llvm] [lldb] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Alex Langford via lldb-commits]

https://github.com/bulbazord commented:

Out of curiosity, why did you choose the delimiter as ' ' instead of something 
like ';'?

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [DRAFT][lldb][DWARFASTParserClang] Fetch constant value from variable defintion if available (PR #71004)

[Michael Buch via lldb-commits]

https://github.com/Michael137 edited 
https://github.com/llvm/llvm-project/pull/71004
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [DRAFT][lldb][DWARFASTParserClang] Fetch constant value from variable defintion if available (PR #71004)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)


Changes

This is a **draft** patch that shows how LLDB could continue to support static 
initialisers even if the declaration didn't have a `DW_AT_const_value` anymore.

https://github.com/llvm/llvm-project/pull/70639 proposes moving the 
`DW_AT_const_value` on inline static members from the declaration DIE to the 
definition DIE.

Previously the expression evaluator would find the constant for a VarDecl from 
its declaration `DW_TAG_member` DIE. In cases where the initialiser was 
specified out-of-class, LLDB could find it during symbol resolution.

However, neither of those will work for constants, since we don't have a 
constant attribute on the declaration anymore and we don't have constants in 
the symbol table.

---
Full diff: https://github.com/llvm/llvm-project/pull/71004.diff


2 Files Affected:

- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(+50-1) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h (+5-5) 


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 182cc6764651747..39571dbcd30a57b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -31,6 +31,7 @@
 #include "lldb/Symbol/SymbolFile.h"
 #include "lldb/Symbol/TypeList.h"
 #include "lldb/Symbol/TypeMap.h"
+#include "lldb/Symbol/VariableList.h"
 #include "lldb/Target/Language.h"
 #include "lldb/Utility/LLDBAssert.h"
 #include "lldb/Utility/Log.h"
@@ -133,6 +134,42 @@ static lldb::ModuleSP GetContainingClangModule(const 
DWARFDIE ) {
   return lldb::ModuleSP();
 }
 
+static std::optional
+FindConstantOnVariableDefinition(DWARFDIE die) {
+  auto *dwarf = die.GetDWARF();
+  if (!dwarf)
+return {};
+
+  ConstString name{die.GetName()};
+  if (!name)
+return {};
+
+  // Make sure we populate the GetDieToVariable cache.
+  VariableList variables;
+  dwarf->FindGlobalVariables(name, {}, UINT_MAX, variables);
+
+  auto const _to_var = dwarf->GetDIEToVariable();
+  auto it = die_to_var.find(die.GetDIE());
+  if (it == die_to_var.end())
+return {};
+
+  auto var_sp = it->getSecond();
+  assert(var_sp != nullptr);
+
+  if (!var_sp->GetLocationIsConstantValueData())
+return {};
+
+  auto def = dwarf->GetDIE(var_sp->GetID());
+  auto def_attrs = def.GetAttributes();
+  DWARFFormValue form_value;
+  if (!def_attrs.ExtractFormValueAtIndex(
+  def_attrs.FindAttributeIndex(llvm::dwarf::DW_AT_const_value),
+  form_value))
+return {};
+
+  return form_value;
+}
+
 TypeSP DWARFASTParserClang::ParseTypeFromClangModule(const SymbolContext ,
  const DWARFDIE ,
  Log *log) {
@@ -2906,9 +2943,21 @@ void DWARFASTParserClang::ParseSingleMember(
 
   bool unused;
   // TODO: Support float/double static members as well.
-  if (!attrs.const_value_form || !ct.IsIntegerOrEnumerationType(unused))
+  if (!ct.IsIntegerOrEnumerationType(unused))
 return;
 
+  // Newer versions of Clang don't emit the DW_AT_const_value
+  // on the declaration of a inline static data member. Instead
+  // it's attached to the definition DIE. If that's the case,
+  // try and fetch it.
+  if (!attrs.const_value_form) {
+auto maybe_form_value = FindConstantOnVariableDefinition(die);
+if (!maybe_form_value)
+  return;
+
+attrs.const_value_form = *maybe_form_value;
+  }
+
   llvm::Expected const_value_or_err =
   ExtractIntFromFormValue(ct, *attrs.const_value_form);
   if (!const_value_or_err) {
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
index 069a2050f0eaadc..ba4532c48338b76 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -342,6 +342,11 @@ class SymbolFileDWARF : public SymbolFileCommon {
 return m_forward_decl_compiler_type_to_die;
   }
 
+  typedef llvm::DenseMap
+  DIEToVariableSP;
+
+  virtual DIEToVariableSP () { return m_die_to_variable_sp; }
+
   virtual UniqueDWARFASTTypeMap ();
 
   bool ClassOrStructIsVirtual(const DWARFDIE );
@@ -361,9 +366,6 @@ class SymbolFileDWARF : public SymbolFileCommon {
   Type *ResolveTypeUID(const DIERef _ref);
 
 protected:
-  typedef llvm::DenseMap
-  DIEToVariableSP;
-
   SymbolFileDWARF(const SymbolFileDWARF &) = delete;
   const SymbolFileDWARF =(const SymbolFileDWARF &) = delete;
 
@@ -487,8 +489,6 @@ class SymbolFileDWARF : public SymbolFileCommon {
 
   void UpdateExternalModuleListIfNeeded();
 
-  virtual DIEToVariableSP () { return m_die_to_variable_sp; }
-
   void BuildCuTranslationTable();
   std::optional 

[Lldb-commits] [lldb] [DRAFT][lldb][DWARFASTParserClang] Fetch constant value from variable defintion if available (PR #71004)

[Michael Buch via lldb-commits]

https://github.com/Michael137 created 
https://github.com/llvm/llvm-project/pull/71004

This is a **draft** patch that shows how LLDB could continue to support static 
initialisers even if the declaration didn't have a `DW_AT_const_value` anymore.

https://github.com/llvm/llvm-project/pull/70639 proposes moving the 
`DW_AT_const_value` on inline static members from the declaration DIE to the 
definition DIE.

Previously the expression evaluator would find the constant for a VarDecl from 
its declaration `DW_TAG_member` DIE. In cases where the initialiser was 
specified out-of-class, LLDB could find it during symbol resolution.

However, neither of those will work for constants, since we don't have a 
constant attribute on the declaration anymore and we don't have constants in 
the symbol table.

>From 4f126606668904a32a1742877ab77e8e3999dad6 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Wed, 1 Nov 2023 12:25:06 +
Subject: [PATCH] [lldb][DWARFASTParserClang] Fetch constant value from
 variable definition if available

---
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  | 51 ++-
 .../SymbolFile/DWARF/SymbolFileDWARF.h| 10 ++--
 2 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 182cc6764651747..39571dbcd30a57b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -31,6 +31,7 @@
 #include "lldb/Symbol/SymbolFile.h"
 #include "lldb/Symbol/TypeList.h"
 #include "lldb/Symbol/TypeMap.h"
+#include "lldb/Symbol/VariableList.h"
 #include "lldb/Target/Language.h"
 #include "lldb/Utility/LLDBAssert.h"
 #include "lldb/Utility/Log.h"
@@ -133,6 +134,42 @@ static lldb::ModuleSP GetContainingClangModule(const 
DWARFDIE ) {
   return lldb::ModuleSP();
 }
 
+static std::optional
+FindConstantOnVariableDefinition(DWARFDIE die) {
+  auto *dwarf = die.GetDWARF();
+  if (!dwarf)
+return {};
+
+  ConstString name{die.GetName()};
+  if (!name)
+return {};
+
+  // Make sure we populate the GetDieToVariable cache.
+  VariableList variables;
+  dwarf->FindGlobalVariables(name, {}, UINT_MAX, variables);
+
+  auto const _to_var = dwarf->GetDIEToVariable();
+  auto it = die_to_var.find(die.GetDIE());
+  if (it == die_to_var.end())
+return {};
+
+  auto var_sp = it->getSecond();
+  assert(var_sp != nullptr);
+
+  if (!var_sp->GetLocationIsConstantValueData())
+return {};
+
+  auto def = dwarf->GetDIE(var_sp->GetID());
+  auto def_attrs = def.GetAttributes();
+  DWARFFormValue form_value;
+  if (!def_attrs.ExtractFormValueAtIndex(
+  def_attrs.FindAttributeIndex(llvm::dwarf::DW_AT_const_value),
+  form_value))
+return {};
+
+  return form_value;
+}
+
 TypeSP DWARFASTParserClang::ParseTypeFromClangModule(const SymbolContext ,
  const DWARFDIE ,
  Log *log) {
@@ -2906,9 +2943,21 @@ void DWARFASTParserClang::ParseSingleMember(
 
   bool unused;
   // TODO: Support float/double static members as well.
-  if (!attrs.const_value_form || !ct.IsIntegerOrEnumerationType(unused))
+  if (!ct.IsIntegerOrEnumerationType(unused))
 return;
 
+  // Newer versions of Clang don't emit the DW_AT_const_value
+  // on the declaration of a inline static data member. Instead
+  // it's attached to the definition DIE. If that's the case,
+  // try and fetch it.
+  if (!attrs.const_value_form) {
+auto maybe_form_value = FindConstantOnVariableDefinition(die);
+if (!maybe_form_value)
+  return;
+
+attrs.const_value_form = *maybe_form_value;
+  }
+
   llvm::Expected const_value_or_err =
   ExtractIntFromFormValue(ct, *attrs.const_value_form);
   if (!const_value_or_err) {
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
index 069a2050f0eaadc..ba4532c48338b76 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -342,6 +342,11 @@ class SymbolFileDWARF : public SymbolFileCommon {
 return m_forward_decl_compiler_type_to_die;
   }
 
+  typedef llvm::DenseMap
+  DIEToVariableSP;
+
+  virtual DIEToVariableSP () { return m_die_to_variable_sp; }
+
   virtual UniqueDWARFASTTypeMap ();
 
   bool ClassOrStructIsVirtual(const DWARFDIE );
@@ -361,9 +366,6 @@ class SymbolFileDWARF : public SymbolFileCommon {
   Type *ResolveTypeUID(const DIERef _ref);
 
 protected:
-  typedef llvm::DenseMap
-  DIEToVariableSP;
-
   SymbolFileDWARF(const SymbolFileDWARF &) = delete;
   const SymbolFileDWARF =(const SymbolFileDWARF &) = delete;
 
@@ -487,8 +489,6 @@ class SymbolFileDWARF : public SymbolFileCommon {
 
   void 

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Alex Langford via lldb-commits]

https://github.com/bulbazord edited 
https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Alex Langford via lldb-commits]

@@ -373,14 +374,8 @@ bool GDBRemoteRegisterContext::WriteRegisterBytes(const 
RegisterInfo *reg_info,
   if (dst == nullptr)
 return false;
 
-  // Code below is specific to AArch64 target in SVE or SME state
-  // If vector granule (vg) register is being written then thread's
-  // register context reconfiguration is triggered on success.
-  // We do not allow writes to SVG so it is not mentioned here.
-  const ArchSpec  = process->GetTarget().GetArchitecture();
-  bool do_reconfigure_arm64_sve = arch.IsValid() &&
-  arch.GetTriple().isAArch64() &&
-  (strcmp(reg_info->name, "vg") == 0);
+  bool should_reconfigure_registers =

bulbazord wrote:

`const`?  

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[Alex Langford via lldb-commits]

@@ -445,7 +445,11 @@ class SymbolFile : public PluginInterface {
   /// contains the keys "type", "symfile", and "separate-debug-info-files".
   /// "type" can be used to assume the structure of each object in
   /// "separate-debug-info-files".
-  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary ) {
+  /// \param errors_only
+  /// If true, then only return separate debug info files that encountered
+  /// errors during loading.
+  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary ,
+bool errors_only) {

bulbazord wrote:

Not sure I'm a fan of a parameter that changes behavior. Why not introduce a 
new function entirely?

https://github.com/llvm/llvm-project/pull/71000
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [libc] [flang] [lldb] [libcxx] [llvm] [lld] [clang-tools-extra] [OpenACC] Initial commits to support OpenACC (PR #70234)

[Bruno Cardoso Lopes via lldb-commits]

@@ -605,6 +605,17 @@ static void InitializeStandardPredefinedMacros(const 
TargetInfo ,
   Builder.defineMacro("HIP_API_PER_THREAD_DEFAULT_STREAM");
 }
   }
+
+  if (LangOpts.OpenACC) {
+// FIXME: When we have full support for OpenACC, we should set this to the
+// version we support. Until then, set as '1' by default, but provide a
+// temporary mechanism for users to override this so real-world examples 
can
+// be tested against.
+if (!LangOpts.OpenACCMacroOverride.empty())
+  Builder.defineMacro("_OPENACC", LangOpts.OpenACCMacroOverride);
+else
+  Builder.defineMacro("_OPENACC", "1");

bcardosolopes wrote:

This probably deserves a test akin to `-E -dM` and FileCheck for the macro.

https://github.com/llvm/llvm-project/pull/70234
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [flang] [clang] [llvm] [libc] [lld] [libcxx] [clang-tools-extra] [lldb] [OpenACC] Initial commits to support OpenACC (PR #70234)

[Bruno Cardoso Lopes via lldb-commits]

@@ -0,0 +1,14 @@
+// RUN: %clang -S -### -fopenacc %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-DRIVER
+// CHECK-DRIVER: "-cc1" {{.*}} "-fopenacc"

bcardosolopes wrote:

How does the interaction between using both `-fopenmp` and `-fopenacc` at the 
same time should look like? One takes precedence? Or should it be rejected?

https://github.com/llvm/llvm-project/pull/70234
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [lld] [flang] [clang] [llvm] [lldb] [clang-tools-extra] [libc] [OpenACC] Initial commits to support OpenACC (PR #70234)

[Bruno Cardoso Lopes via lldb-commits]

https://github.com/bcardosolopes commented:

The changes in this patch looks pretty straightforward! Left some inline 
comments.

https://github.com/llvm/llvm-project/pull/70234
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [llvm] [lld] [clang] [libc] [flang] [lldb] [clang-tools-extra] [OpenACC] Initial commits to support OpenACC (PR #70234)

[Bruno Cardoso Lopes via lldb-commits]

https://github.com/bcardosolopes edited 
https://github.com/llvm/llvm-project/pull/70234
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libc] [clang] [lld] [llvm] [lldb] [libcxx] [clang-tools-extra] [flang] [OpenACC] Initial commits to support OpenACC (PR #70234)

[Bruno Cardoso Lopes via lldb-commits]

@@ -1342,6 +1342,15 @@ def err_opencl_logical_exclusive_or : Error<
 def err_openclcxx_virtual_function : Error<
   "virtual functions are not supported in C++ for OpenCL">;
 
+// OpenACC Support.
+def warn_pragma_acc_ignored : Warning<
+  "unexpected '#pragma acc ...' in program">, InGroup, 
DefaultIgnore;
+def err_acc_unexpected_directive : Error<
+  "unexpected OpenACC directive %select{|'#pragma acc %1'}0">;
+def warn_pragma_acc_unimplemented
+: Warning<"OpenACC Directives not yet implemented, pragma ignored">,

bcardosolopes wrote:

Does `Directives` need to be capitalized?

https://github.com/llvm/llvm-project/pull/70234
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[Jason Molenda via lldb-commits]

@@ -339,6 +337,18 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const 
RegisterInfo *reg_info,
   value.SetFromMemoryData(*reg_info, src + sizeof(sve::user_za_header),
   reg_info->byte_size, lldb::eByteOrderLittle,
   error);
+} else if (m_register_info_up->IsSMERegZT(reg)) {
+  value.SetFromMemoryData(*reg_info, m_zt_data.GetDataStart(),
+  reg_info->byte_size, lldb::eByteOrderLittle,
+  error);
+} else {
+  offset = reg_info->byte_offset - m_register_info_up->GetSMEOffset();
+  assert(offset < sizeof(m_sme_pseudo_regs));

jasonmolenda wrote:

This would be someone trying to fetch a register that is at a greater offset 
than the register context buffer has.  My worry about the assert is more that 
in a non-debug/release build, there's no error checking, we'll read from past 
the end of the m_sme_psueo_regs buffer and copy it into value.
On the other hand, this does fall in to "this shouldn't ever happen", but maybe 
returning false here instead of filling in value would be the best choice.

https://github.com/llvm/llvm-project/pull/70934
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/70934
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda edited 
https://github.com/llvm/llvm-project/pull/70934
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[via lldb-commits]

@@ -4296,7 +4297,8 @@ bool 
SymbolFileDWARF::GetSeparateDebugInfo(StructuredData::Dictionary ) {
   dwarf_cu->GetDwoError().AsCString("unknown"));
 }
 dwo_data->AddBooleanItem("loaded", dwo_symfile != nullptr);
-separate_debug_info_files.AddItem(dwo_data);
+if (!errors_only || (errors_only && dwo_data->HasKey("error")))

jeffreytan81 wrote:

You do not need the second `errors_only` check. Simply use:
```
!errors_only || dwo_data->HasKey("error")
```

https://github.com/llvm/llvm-project/pull/71000
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[via lldb-commits]

https://github.com/jeffreytan81 edited 
https://github.com/llvm/llvm-project/pull/71000
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[via lldb-commits]

https://github.com/jeffreytan81 approved this pull request.


https://github.com/llvm/llvm-project/pull/71000
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 66b9283 - [lldb] [debugserver] Shut down the exception thread when clearing (#70979)

[via lldb-commits]

Author: Jason Molenda
Date: 2023-11-01T16:14:36-07:00
New Revision: 66b92830c963158c9f74dd5533265c28d60cc265

URL: 
https://github.com/llvm/llvm-project/commit/66b92830c963158c9f74dd5533265c28d60cc265
DIFF: 
https://github.com/llvm/llvm-project/commit/66b92830c963158c9f74dd5533265c28d60cc265.diff

LOG: [lldb] [debugserver] Shut down the exception thread when clearing (#70979)

MachProcess has a MachTask as an ivar. In the MachProcess dtor, we call
MachTask::Clear() to clear its state, before running the dtor of all our
ivars, including the MachTask one.

When we attach on darwin, MachProcess calls
MachTask::StartExceptionThread which does the task_for_pid and then
starts a thread to listen for mach messages. Then MachProcess calls
ptrace(PT_ATTACHEXC). If that ptrace() fails, MachProcess will call
MachTask::Clear. But the exception thread is now up & running and is not
stopped; its ivars will be reset by the Clear() method, and its object
will be freed after the dtor runs.

Actually eliciting a crash in this scenario is very timing sensitive; I
hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate it
on my desktop and was unable. But looking at the source, and an
occasional crash report we've received, it's clear that this is
possible.

rdar://117521198

Added: 


Modified: 
lldb/tools/debugserver/source/MacOSX/MachTask.mm

Removed: 




diff  --git a/lldb/tools/debugserver/source/MacOSX/MachTask.mm 
b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
index 4f5b4039243f662..fd2ac64ac6cf79c 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachTask.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
@@ -145,6 +145,8 @@
 //--
 void MachTask::Clear() {
   // Do any cleanup needed for this task
+  if (m_exception_thread)
+ShutDownExcecptionThread();
   m_task = TASK_NULL;
   m_exception_thread = 0;
   m_exception_port = MACH_PORT_NULL;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda closed 
https://github.com/llvm/llvm-project/pull/70979
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[Jonas Devlieghere via lldb-commits]

https://github.com/JDevlieghere approved this pull request.


https://github.com/llvm/llvm-project/pull/70979
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[David Blaikie via lldb-commits]

dwblaikie wrote:

> 2) always put DW_AT_const_value in DW_TAG_member.

My understanding is that this is not possible. Dependent initializer 
expressions can't be evaluated in all cases - we're only allowed to evaluate 
them in the places the language allows us to, otherwise we might produce the 
wrong answer.

For non-dependent initializer expressions I think we could produce the answer 
in all cases.

And if we want type descriptions that are consistent (valuable for use with 
Type Units, and with @avl-llvm's DWARFLinker work) and we want to include 
static member variables in those descriptions, then we could put the constant 
value in the declaration of the member in cases where the initializer is 
non-dependent. But we'd still have to put it out in a definition in the 
dependent cases (if we want consistency).

And if we have to put it out in a separate definition DIE anyway - probably 
good to do that consistently so there's fewer special cases?

Admittedly there are other reasons type definitions are inconsistent (eg: 
implicit special members, nested types, and member function template 
specializations (& I guess static member variable template specializations)) - 
and we could move static variables out of the authoritative type definitions 
the same way we do for those cases. We can see this in type units (the type 
unit never has these entities in it, but the skeleton unit that references the 
type unit does have these features) - I'd expect something like that to be what 
@avl-llvm will want to do with DWARFLinker - though without type units in 
input, I'm not sure how easily it'll be to determine that those are the variant 
parts that shouldn't go in the canonical type definition... 

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Tom Yang (zhyty)


Changes

Often, we only care about the split-dwarf files that have failed to load. This 
can be useful when diagnosing binaries with many separate debug info files 
where only some have errors. 

```
(lldb) help image dump separate-debug-info
List the separate debug info symbol files for one or more target modules.

Syntax: target modules dump separate-debug-info cmd-options 
[filename [filename [...]]]

Command Options Usage:
  target modules dump separate-debug-info [-ej] [filename 
[filename [...]]]

   -e ( --errors-only )
Filter to show only debug info files with errors.

   -j ( --json )
Output the details in JSON format.

 This command takes options and free-form arguments.  If your arguments
 resemble option specifiers (i.e., they start with a - or --), you must use
 ' -- ' between the end of the command options and the beginning of the
 arguments.

'image' is an abbreviation for 'target modules'
```

I updated the following tests
```
# on Linux
bin/lldb-dotest -p TestDumpDwo

# on Mac
bin/lldb-dotest -p TestDumpOso
```

This change applies to both the table and JSON outputs.

---
Full diff: https://github.com/llvm/llvm-project/pull/71000.diff


9 Files Affected:

- (modified) lldb/include/lldb/Symbol/SymbolFile.h (+5-1) 
- (modified) lldb/source/Commands/CommandObjectTarget.cpp (+14-6) 
- (modified) lldb/source/Commands/Options.td (+3-1) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+4-2) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h (+2-1) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp 
(+3-2) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h 
(+2-1) 
- (modified) 
lldb/test/API/commands/target/dump-separate-debug-info/dwo/TestDumpDwo.py 
(+13-7) 
- (modified) 
lldb/test/API/commands/target/dump-separate-debug-info/oso/TestDumpOso.py 
(+13-5) 


``diff
diff --git a/lldb/include/lldb/Symbol/SymbolFile.h 
b/lldb/include/lldb/Symbol/SymbolFile.h
index b40d0f03b6e0130..9fc90ad49361be8 100644
--- a/lldb/include/lldb/Symbol/SymbolFile.h
+++ b/lldb/include/lldb/Symbol/SymbolFile.h
@@ -445,7 +445,11 @@ class SymbolFile : public PluginInterface {
   /// contains the keys "type", "symfile", and "separate-debug-info-files".
   /// "type" can be used to assume the structure of each object in
   /// "separate-debug-info-files".
-  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary ) {
+  /// \param errors_only
+  /// If true, then only return separate debug info files that encountered
+  /// errors during loading.
+  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary ,
+bool errors_only) {
 return false;
   };
 
diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index c84a6550d6c75cc..ca8484cc79d4054 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -1452,11 +1452,11 @@ static bool DumpModuleSymbolFile(Stream , Module 
*module) {
 }
 
 static bool GetSeparateDebugInfoList(StructuredData::Array ,
- Module *module) {
+ Module *module, bool errors_only) {
   if (module) {
 if (SymbolFile *symbol_file = module->GetSymbolFile(/*can_create=*/true)) {
   StructuredData::Dictionary d;
-  if (symbol_file->GetSeparateDebugInfo(d)) {
+  if (symbol_file->GetSeparateDebugInfo(d, errors_only)) {
 list.AddItem(
 std::make_shared(std::move(d)));
 return true;
@@ -2561,7 +2561,10 @@ class 
CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 m_json.SetCurrentValue(true);
 m_json.SetOptionWasSet();
 break;
-
+  case 'e':
+m_errors_only.SetCurrentValue(true);
+m_errors_only.SetOptionWasSet();
+break;
   default:
 llvm_unreachable("Unimplemented option");
   }
@@ -2570,6 +2573,7 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 
 void OptionParsingStarting(ExecutionContext *execution_context) override {
   m_json.Clear();
+  m_errors_only.Clear();
 }
 
 llvm::ArrayRef GetDefinitions() override {
@@ -2577,6 +2581,7 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 }
 
 OptionValueBoolean m_json = false;
+OptionValueBoolean m_errors_only = false;
   };
 
 protected:
@@ -2607,7 +2612,8 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
   break;
 
 if (GetSeparateDebugInfoList(separate_debug_info_lists_by_module,
- module_sp.get()))
+ module_sp.get(),
+ bool(m_options.m_errors_only)))
   num_dumped++;
   }
 } else {

[Lldb-commits] [lldb] [lldb][split-dwarf] Add --errors-only argument separate-debug-info list (PR #71000)

[Tom Yang via lldb-commits]

https://github.com/zhyty created https://github.com/llvm/llvm-project/pull/71000

Often, we only care about the split-dwarf files that have failed to load. This 
can be useful when diagnosing binaries with many separate debug info files 
where only some have errors. 

```
(lldb) help image dump separate-debug-info
List the separate debug info symbol files for one or more target modules.

Syntax: target modules dump separate-debug-info  [ 
[ [...]]]

Command Options Usage:
  target modules dump separate-debug-info [-ej] [ [ [...]]]

   -e ( --errors-only )
Filter to show only debug info files with errors.

   -j ( --json )
Output the details in JSON format.

 This command takes options and free-form arguments.  If your arguments
 resemble option specifiers (i.e., they start with a - or --), you must use
 ' -- ' between the end of the command options and the beginning of the
 arguments.

'image' is an abbreviation for 'target modules'
```

I updated the following tests
```
# on Linux
bin/lldb-dotest -p TestDumpDwo

# on Mac
bin/lldb-dotest -p TestDumpOso
```

This change applies to both the table and JSON outputs.

>From c6900333c54d1c3f5dd3e6a88f0627b65ff0efca Mon Sep 17 00:00:00 2001
From: Tom Yang 
Date: Wed, 1 Nov 2023 00:53:19 -0700
Subject: [PATCH] [lldb] Add --errors-only argument separate-debug-info list

---
 lldb/include/lldb/Symbol/SymbolFile.h |  6 +-
 lldb/source/Commands/CommandObjectTarget.cpp  | 20 +--
 lldb/source/Commands/Options.td   |  4 +++-
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  |  6 --
 .../SymbolFile/DWARF/SymbolFileDWARF.h|  3 ++-
 .../DWARF/SymbolFileDWARFDebugMap.cpp |  5 +++--
 .../DWARF/SymbolFileDWARFDebugMap.h   |  3 ++-
 .../dwo/TestDumpDwo.py| 20 ---
 .../oso/TestDumpOso.py| 18 -
 9 files changed, 59 insertions(+), 26 deletions(-)

diff --git a/lldb/include/lldb/Symbol/SymbolFile.h 
b/lldb/include/lldb/Symbol/SymbolFile.h
index b40d0f03b6e0130..9fc90ad49361be8 100644
--- a/lldb/include/lldb/Symbol/SymbolFile.h
+++ b/lldb/include/lldb/Symbol/SymbolFile.h
@@ -445,7 +445,11 @@ class SymbolFile : public PluginInterface {
   /// contains the keys "type", "symfile", and "separate-debug-info-files".
   /// "type" can be used to assume the structure of each object in
   /// "separate-debug-info-files".
-  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary ) {
+  /// \param errors_only
+  /// If true, then only return separate debug info files that encountered
+  /// errors during loading.
+  virtual bool GetSeparateDebugInfo(StructuredData::Dictionary ,
+bool errors_only) {
 return false;
   };
 
diff --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index c84a6550d6c75cc..ca8484cc79d4054 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -1452,11 +1452,11 @@ static bool DumpModuleSymbolFile(Stream , Module 
*module) {
 }
 
 static bool GetSeparateDebugInfoList(StructuredData::Array ,
- Module *module) {
+ Module *module, bool errors_only) {
   if (module) {
 if (SymbolFile *symbol_file = module->GetSymbolFile(/*can_create=*/true)) {
   StructuredData::Dictionary d;
-  if (symbol_file->GetSeparateDebugInfo(d)) {
+  if (symbol_file->GetSeparateDebugInfo(d, errors_only)) {
 list.AddItem(
 std::make_shared(std::move(d)));
 return true;
@@ -2561,7 +2561,10 @@ class 
CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 m_json.SetCurrentValue(true);
 m_json.SetOptionWasSet();
 break;
-
+  case 'e':
+m_errors_only.SetCurrentValue(true);
+m_errors_only.SetOptionWasSet();
+break;
   default:
 llvm_unreachable("Unimplemented option");
   }
@@ -2570,6 +2573,7 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 
 void OptionParsingStarting(ExecutionContext *execution_context) override {
   m_json.Clear();
+  m_errors_only.Clear();
 }
 
 llvm::ArrayRef GetDefinitions() override {
@@ -2577,6 +2581,7 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
 }
 
 OptionValueBoolean m_json = false;
+OptionValueBoolean m_errors_only = false;
   };
 
 protected:
@@ -2607,7 +2612,8 @@ class CommandObjectTargetModulesDumpSeparateDebugInfoFiles
   break;
 
 if (GetSeparateDebugInfoList(separate_debug_info_lists_by_module,
- module_sp.get()))
+ module_sp.get(),
+ bool(m_options.m_errors_only)))
   num_dumped++;
   }
 } else {
@@ -2628,7 +2634,7 @@ class 

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jonas Devlieghere via lldb-commits]

@@ -1612,6 +1612,22 @@ bool 
ProcessGDBRemote::CalculateThreadStopInfo(ThreadGDBRemote *thread) {
   return false;
 }
 
+void ProcessGDBRemote::ParseExpeditedRegisters(
+ExpeditedRegisterMap _register_map, ThreadSP thread_sp) {
+  ThreadGDBRemote *gdb_thread = static_cast(thread_sp.get());
+  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
+
+  for (const auto  : expedited_register_map) {
+StringExtractor reg_value_extractor(pair.second);
+WritableDataBufferSP buffer_sp(

JDevlieghere wrote:

Ah, makes sense. I was focussed on `PrivateSetRegisterValue` and missed the 
extraction bit. Thanks!

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jonas Devlieghere via lldb-commits]

@@ -762,82 +756,22 @@ uint32_t 
GDBRemoteRegisterContext::ConvertRegisterKindToRegisterNumber(
   return m_reg_info_sp->ConvertRegisterKindToRegisterNumber(kind, num);
 }
 
-void GDBRemoteRegisterContext::AArch64Reconfigure() {
-  assert(m_reg_info_sp);
-
-  // Once we start to reconfigure registers, we cannot read any of them.
-  // So we must read VG and SVG up front.
-
-  const uint64_t fail_value = LLDB_INVALID_ADDRESS;
-  std::optional vg_reg_value;
-  const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
-  if (vg_reg_info) {
-// Make sure we get the latest value of vg from the remote.
-SetRegisterIsValid(vg_reg_info, false);
-uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  vg_reg_value = reg_value;
-  }
-
-  std::optional svg_reg_value;
-  const RegisterInfo *svg_reg_info = m_reg_info_sp->GetRegisterInfo("svg");
-  if (svg_reg_info) {
-// When vg is written it is automatically made invalid. Writing vg will 
also
-// change svg if we're in streaming mode but it will not be made invalid
-// so do this manually so the following read gets the latest svg value.
-SetRegisterIsValid(svg_reg_info, false);
-
-uint32_t svg_reg_num = svg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  svg_reg_value = reg_value;
-  }
-
-  if (vg_reg_value)
-m_reg_info_sp->UpdateARM64SVERegistersInfos(*vg_reg_value);
-  if (svg_reg_value)
-m_reg_info_sp->UpdateARM64SMERegistersInfos(*svg_reg_value);
-
-  // At this point if we have updated any registers, their offsets will all be
-  // invalid. If we did, we need to update them all.
-  if (vg_reg_value || svg_reg_value) {
-m_reg_info_sp->ConfigureOffsets();
-// From here we are able to read registers again.
-
-// Make a heap based buffer that is big enough to store all registers
-m_reg_data.SetData(std::make_shared(
-m_reg_info_sp->GetRegisterDataByteSize(), 0));
-m_reg_data.SetByteOrder(GetByteOrder());
-  }
-}
-
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
-  // SVE Z register size is vg x 8 bytes.
-  uint32_t z_reg_byte_size = vg * 8;
-
-  // SVE vector length has changed, accordingly set size of Z, P and FFR
-  // registers. Also invalidate register offsets it will be recalculated
-  // after SVE register size update.
-  for (auto  : m_regs) {
-if (reg.value_regs == nullptr) {
-  if (reg.name[0] == 'z' && isdigit(reg.name[1]))
-reg.byte_size = z_reg_byte_size;
-  else if (reg.name[0] == 'p' && isdigit(reg.name[1]))
-reg.byte_size = vg;
-  else if (strcmp(reg.name, "ffr") == 0)
-reg.byte_size = vg;
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::RegisterWriteCausesReconfigure(
+const char *name) {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();
+  const Architecture *architecture =
+  process->GetTarget().GetArchitecturePlugin();
+  return architecture && architecture->RegisterWriteCausesReconfigure(name);
 }
 
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SMERegistersInfos(uint64_t svg) {
-  for (auto  : m_regs) {
-if (strcmp(reg.name, "za") == 0) {
-  // ZA is a register with size (svg*8) * (svg*8). A square essentially.
-  reg.byte_size = (svg * 8) * (svg * 8);
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::ReconfigureRegisterInfo() {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();

JDevlieghere wrote:

I figured, in which case it should use `GetProcessRef`. 

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jason Molenda via lldb-commits]

@@ -762,82 +756,22 @@ uint32_t 
GDBRemoteRegisterContext::ConvertRegisterKindToRegisterNumber(
   return m_reg_info_sp->ConvertRegisterKindToRegisterNumber(kind, num);
 }
 
-void GDBRemoteRegisterContext::AArch64Reconfigure() {
-  assert(m_reg_info_sp);
-
-  // Once we start to reconfigure registers, we cannot read any of them.
-  // So we must read VG and SVG up front.
-
-  const uint64_t fail_value = LLDB_INVALID_ADDRESS;
-  std::optional vg_reg_value;
-  const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
-  if (vg_reg_info) {
-// Make sure we get the latest value of vg from the remote.
-SetRegisterIsValid(vg_reg_info, false);
-uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  vg_reg_value = reg_value;
-  }
-
-  std::optional svg_reg_value;
-  const RegisterInfo *svg_reg_info = m_reg_info_sp->GetRegisterInfo("svg");
-  if (svg_reg_info) {
-// When vg is written it is automatically made invalid. Writing vg will 
also
-// change svg if we're in streaming mode but it will not be made invalid
-// so do this manually so the following read gets the latest svg value.
-SetRegisterIsValid(svg_reg_info, false);
-
-uint32_t svg_reg_num = svg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  svg_reg_value = reg_value;
-  }
-
-  if (vg_reg_value)
-m_reg_info_sp->UpdateARM64SVERegistersInfos(*vg_reg_value);
-  if (svg_reg_value)
-m_reg_info_sp->UpdateARM64SMERegistersInfos(*svg_reg_value);
-
-  // At this point if we have updated any registers, their offsets will all be
-  // invalid. If we did, we need to update them all.
-  if (vg_reg_value || svg_reg_value) {
-m_reg_info_sp->ConfigureOffsets();
-// From here we are able to read registers again.
-
-// Make a heap based buffer that is big enough to store all registers
-m_reg_data.SetData(std::make_shared(
-m_reg_info_sp->GetRegisterDataByteSize(), 0));
-m_reg_data.SetByteOrder(GetByteOrder());
-  }
-}
-
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
-  // SVE Z register size is vg x 8 bytes.
-  uint32_t z_reg_byte_size = vg * 8;
-
-  // SVE vector length has changed, accordingly set size of Z, P and FFR
-  // registers. Also invalidate register offsets it will be recalculated
-  // after SVE register size update.
-  for (auto  : m_regs) {
-if (reg.value_regs == nullptr) {
-  if (reg.name[0] == 'z' && isdigit(reg.name[1]))
-reg.byte_size = z_reg_byte_size;
-  else if (reg.name[0] == 'p' && isdigit(reg.name[1]))
-reg.byte_size = vg;
-  else if (strcmp(reg.name, "ffr") == 0)
-reg.byte_size = vg;
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::RegisterWriteCausesReconfigure(
+const char *name) {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();
+  const Architecture *architecture =
+  process->GetTarget().GetArchitecturePlugin();
+  return architecture && architecture->RegisterWriteCausesReconfigure(name);
 }
 
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SMERegistersInfos(uint64_t svg) {
-  for (auto  : m_regs) {
-if (strcmp(reg.name, "za") == 0) {
-  // ZA is a register with size (svg*8) * (svg*8). A square essentially.
-  reg.byte_size = (svg * 8) * (svg * 8);
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::ReconfigureRegisterInfo() {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();

jasonmolenda wrote:

A RegisterContext is associated with a StackFrame which is in a Thread which is 
in a Process.  

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jason Molenda via lldb-commits]

@@ -1612,6 +1612,22 @@ bool 
ProcessGDBRemote::CalculateThreadStopInfo(ThreadGDBRemote *thread) {
   return false;
 }
 
+void ProcessGDBRemote::ParseExpeditedRegisters(
+ExpeditedRegisterMap _register_map, ThreadSP thread_sp) {
+  ThreadGDBRemote *gdb_thread = static_cast(thread_sp.get());
+  RegisterContextSP gdb_reg_ctx_sp(gdb_thread->GetRegisterContext());
+
+  for (const auto  : expedited_register_map) {
+StringExtractor reg_value_extractor(pair.second);
+WritableDataBufferSP buffer_sp(

jasonmolenda wrote:

We're decoding the asciihex register values into a byte buffer, this is the 
byte buffer.  

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda approved this pull request.

LGTM.

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda edited 
https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo commented:

pretty nice feature!

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Walter Erquinigo via lldb-commits]

@@ -396,8 +398,22 @@ Symbols::LocateExecutableSymbolFile(const ModuleSpec 
_spec,
   }
 }
   }
-
-  return LocateExecutableSymbolFileDsym(module_spec);
+  FileSpec dsym_bundle = LocateExecutableSymbolFileDsym(module_spec);
+  if (dsym_bundle)
+return dsym_bundle;
+
+  // If we didn't find anything by looking locally, let's try Debuginfod.
+  if (module_uuid.IsValid() && llvm::canUseDebuginfod()) {
+llvm::object::BuildID build_id(module_uuid.GetBytes());
+llvm::Expected result =
+llvm::getCachedOrDownloadDebuginfo(build_id);
+if (result)
+  return FileSpec(*result);
+// An error is just fine, here...
+consumeError(result.takeError());
+  }
+  // Just return the empty FileSpec if nothing was found.
+  return dsym_bundle;

walter-erquinigo wrote:

better return `{}`. It's more readable.

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Walter Erquinigo via lldb-commits]

@@ -396,8 +398,22 @@ Symbols::LocateExecutableSymbolFile(const ModuleSpec 
_spec,
   }
 }
   }
-
-  return LocateExecutableSymbolFileDsym(module_spec);
+  FileSpec dsym_bundle = LocateExecutableSymbolFileDsym(module_spec);
+  if (dsym_bundle)
+return dsym_bundle;
+
+  // If we didn't find anything by looking locally, let's try Debuginfod.
+  if (module_uuid.IsValid() && llvm::canUseDebuginfod()) {
+llvm::object::BuildID build_id(module_uuid.GetBytes());
+llvm::Expected result =
+llvm::getCachedOrDownloadDebuginfo(build_id);
+if (result)
+  return FileSpec(*result);
+// An error is just fine, here...
+consumeError(result.takeError());

walter-erquinigo wrote:

log this to some log channel instead of consuming it

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Walter Erquinigo via lldb-commits]

https://github.com/walter-erquinigo edited 
https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[via lldb-commits]

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 801c78d5b474c2319aa8ead44db7ba8cacac4714 
6454d4fb652f61a20850c75f0e69759dffe28511 -- lldb/include/lldb/Target/Target.h 
lldb/source/Core/Debugger.cpp 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
lldb/source/Symbol/LocateSymbolFile.cpp lldb/source/Target/Target.cpp 
llvm/include/llvm/Debuginfod/Debuginfod.h llvm/lib/Debuginfod/Debuginfod.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 1c0ead3677ea..06862ad2c2c8 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4908,7 +4908,6 @@ void TargetProperties::DebugInfoDURLsChangedCallback() {
   llvm::setDefaultDebuginfodUrls(dbginfod_urls);
 }
 
-
 // Target::TargetEventData
 
 Target::TargetEventData::TargetEventData(const lldb::TargetSP _sp)

``




https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-debuginfo

Author: Kevin Frei (kevinfrei)


Changes

I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic 
downloading of DWP files to the SymbolFileDWARF.cpp plugin. If you have 
DEBUGINFOD_URLS set to a space delimited set of web servers, LLDB will try to 
use them as a last resort when searching for DWP files. If you do *not* have 
that environment variable set, nothing should be changed. There's also a 
setting, per @clayborg 's suggestion, that will override the 
environment variable, or can be used instead of the environment variable. The 
setting is why I also needed to add an API to the llvm-debuginfod library

### Test Plan:

Suggestions are welcome here. I should probably have some positive and negative 
tests, but I wanted to get the diff up for people who have a clue what they're 
doing to rip it to pieces before spending too much time validating the initial 
implementation.

---
Full diff: https://github.com/llvm/llvm-project/pull/70996.diff


10 Files Affected:

- (modified) lldb/include/lldb/Target/Target.h (+3) 
- (modified) lldb/source/Core/CoreProperties.td (+1-1) 
- (modified) lldb/source/Core/Debugger.cpp (+5) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+1) 
- (modified) lldb/source/Symbol/CMakeLists.txt (+1) 
- (modified) lldb/source/Symbol/LocateSymbolFile.cpp (+18-2) 
- (modified) lldb/source/Target/Target.cpp (+18-1) 
- (modified) lldb/source/Target/TargetProperties.td (+4) 
- (modified) llvm/include/llvm/Debuginfod/Debuginfod.h (+4) 
- (modified) llvm/lib/Debuginfod/Debuginfod.cpp (+20-6) 


``diff
diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index 82045988018b606..cd5c88767c900d1 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -258,6 +258,8 @@ class TargetProperties : public Properties {
 
   bool GetDebugUtilityExpression() const;
 
+  Args GetDebugInfoDURLs() const;
+
 private:
   // Callbacks for m_launch_info.
   void Arg0ValueChangedCallback();
@@ -270,6 +272,7 @@ class TargetProperties : public Properties {
   void DisableASLRValueChangedCallback();
   void InheritTCCValueChangedCallback();
   void DisableSTDIOValueChangedCallback();
+  void DebugInfoDURLsChangedCallback();
 
   // Settings checker for target.jit-save-objects-dir:
   void CheckJITObjectsDir();
diff --git a/lldb/source/Core/CoreProperties.td 
b/lldb/source/Core/CoreProperties.td
index 92884258347e9be..865030b0133bbb2 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -4,7 +4,7 @@ let Definition = "modulelist" in {
   def EnableExternalLookup: Property<"enable-external-lookup", "Boolean">,
 Global,
 DefaultTrue,
-Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched.">;
+Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched. If all other methods fail, and 
the DEBUGINFOD_URLS environment variable is specified, the Debuginfod protocol 
is used to acquire symbols from a compatible Debuginfod service.">;
   def EnableBackgroundLookup: Property<"enable-background-lookup", "Boolean">,
 Global,
 DefaultFalse,
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 21f71e449ca5ed0..9a3e82f3e6a2adf 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -61,6 +61,8 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/iterator.h"
+#include "llvm/Debuginfod/Debuginfod.h"
+#include "llvm/Debuginfod/HTTPClient.h"
 #include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Process.h"
@@ -594,6 +596,9 @@ lldb::DWIMPrintVerbosity Debugger::GetDWIMPrintVerbosity() 
const {
 void Debugger::Initialize(LoadPluginCallbackType load_plugin_callback) {
   assert(g_debugger_list_ptr == nullptr &&
  "Debugger::Initialize called more than once!");
+  // We might be using the Debuginfod service, so we have to initialize the
+  // HTTPClient *before* any new 

[Lldb-commits] [lldb] [llvm] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

[Kevin Frei via lldb-commits]

https://github.com/kevinfrei created 
https://github.com/llvm/llvm-project/pull/70996

I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic 
downloading of DWP files to the SymbolFileDWARF.cpp plugin. If you have 
DEBUGINFOD_URLS set to a space delimited set of web servers, LLDB will try to 
use them as a last resort when searching for DWP files. If you do *not* have 
that environment variable set, nothing should be changed. There's also a 
setting, per @clayborg 's suggestion, that will override the environment 
variable, or can be used instead of the environment variable. The setting is 
why I also needed to add an API to the llvm-debuginfod library

### Test Plan:

Suggestions are welcome here. I should probably have some positive and negative 
tests, but I wanted to get the diff up for people who have a clue what they're 
doing to rip it to pieces before spending too much time validating the initial 
implementation.

>From 6454d4fb652f61a20850c75f0e69759dffe28511 Mon Sep 17 00:00:00 2001
From: Kevin Frei 
Date: Wed, 18 Oct 2023 14:37:34 -0700
Subject: [PATCH] DEBUGINFOD based DWP acquisition for LLDB

Summary:
I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic 
downloading of
DWP files to the SymbolFileDWARF.cpp plugin. If you have `DEBUGINFOD_URLS` set 
to a
space delimited set of web servers, LLDB will try to use them as a last resort 
when
searching for DWP files. If you do *not* have that environment variable set, 
nothing
should be changed. There's also a setting, per Greg Clayton's request, that will
override the env variable, or can be used instead of the env var. This setting 
is the
reason for the additional API added to the llvm's Debuginfod library.

Test Plan:
Suggestions are welcome here. I should probably have some positive and negative 
tests,
but I wanted to get the diff up for people who have a clue what they're doing 
to rip it
to pieces before spending too much time validating my implementation.
---
 lldb/include/lldb/Target/Target.h |  3 +++
 lldb/source/Core/CoreProperties.td|  2 +-
 lldb/source/Core/Debugger.cpp |  5 
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  |  1 +
 lldb/source/Symbol/CMakeLists.txt |  1 +
 lldb/source/Symbol/LocateSymbolFile.cpp   | 20 --
 lldb/source/Target/Target.cpp | 19 +-
 lldb/source/Target/TargetProperties.td|  4 +++
 llvm/include/llvm/Debuginfod/Debuginfod.h |  4 +++
 llvm/lib/Debuginfod/Debuginfod.cpp| 26 ++-
 10 files changed, 75 insertions(+), 10 deletions(-)

diff --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index 82045988018b606..cd5c88767c900d1 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -258,6 +258,8 @@ class TargetProperties : public Properties {
 
   bool GetDebugUtilityExpression() const;
 
+  Args GetDebugInfoDURLs() const;
+
 private:
   // Callbacks for m_launch_info.
   void Arg0ValueChangedCallback();
@@ -270,6 +272,7 @@ class TargetProperties : public Properties {
   void DisableASLRValueChangedCallback();
   void InheritTCCValueChangedCallback();
   void DisableSTDIOValueChangedCallback();
+  void DebugInfoDURLsChangedCallback();
 
   // Settings checker for target.jit-save-objects-dir:
   void CheckJITObjectsDir();
diff --git a/lldb/source/Core/CoreProperties.td 
b/lldb/source/Core/CoreProperties.td
index 92884258347e9be..865030b0133bbb2 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -4,7 +4,7 @@ let Definition = "modulelist" in {
   def EnableExternalLookup: Property<"enable-external-lookup", "Boolean">,
 Global,
 DefaultTrue,
-Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched.">;
+Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched. If all other methods fail, and 
the DEBUGINFOD_URLS environment variable is specified, the Debuginfod protocol 
is used to acquire symbols from a compatible Debuginfod service.">;

[Lldb-commits] [flang] [compiler-rt] [llvm] [openmp] [clang] [libcxx] [lldb] [lld] [mlir] [clang-tools-extra] [AMDGPU] GCNRegPressure printing pass for testing. (PR #70031)

[Valery Pykhtin via lldb-commits]

vpykhtin wrote:

I've removed live-through registers printing from this PR and will submit it 
separately.

https://github.com/llvm/llvm-project/pull/70031
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [flang] [compiler-rt] [llvm] [openmp] [clang] [libcxx] [lldb] [lld] [mlir] [clang-tools-extra] [AMDGPU] GCNRegPressure printing pass for testing. (PR #70031)

[Valery Pykhtin via lldb-commits]

https://github.com/vpykhtin closed 
https://github.com/llvm/llvm-project/pull/70031
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[via lldb-commits]

avl-llvm wrote:

> > Or maybe we can include the DW_AT_const_value in both places?
> 
> The ask to drop the constant off of the declaration comes from the 
> DWARFParallelLinker work where it was causing non-deterministic output. But 
> @dwblaikie @avl-llvm will know more about that

I do not have a strong opinion which variant is better : 1) remove 
DW_AT_const_value from DW_TAG_member and put DW_AT_const_value into newly 
created DW_TAG_variable(which does not have a location). or 2) always put  
DW_AT_const_value in DW_TAG_member.

The problem which parallel DWARFLinker met is that DW_TAG_member from one 
compilation unit has DW_AT_const_value while the same DW_TAG_member from 
another compilation unit does not have DW_AT_const_value - 
https://github.com/llvm/llvm-project/pull/68721#issuecomment-1763409701.

If there is a solution when we could always put DW_AT_const_value into the 
DW_TAG_member (so that DW_TAG_member from different compile units have 
DW_AT_const_value) - then that would be also a good solution(and we would not 
need to create additional variable.)

Both solutions 1) and 2) are good for parallel DWARFLinker if they result in 
equal DWARF in different compile units.

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[Michael Buch via lldb-commits]

Michael137 wrote:

> The DWARFASTParserClang, with the current state of things, will automatically 
> add the const value initializer to the clang AST field. See 
> `DWARFASTParserClang::ParseSingleMember(...)` around the `// Handle static 
> members` around 
> lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2882. The code 
> extracts the `llvm::Expected const_value_or_err` and then calls 
> `TypeSystemClang::SetIntegerInitializerForVariable(v, *const_value_or_err);` 
> to set the constant value of the static member. 
> 
> 
> 
> I think the expression parser knows how to grab this value if it is in a 
> static member variable. If this isn't there, it assumes there is a global 
> variable that backs it and that we will be able to find the location of this 
> variable in memory. The expression parser will ask for the address of this 
> value during expression evaluation when it resolves the symbols.

Yup, what i was trying to explain is that with the current patch this will 
break because the expression evaluator neither finds the constant on the 
declaration (since we removed it) nor via symbol resolution (since they just 
won't exist for constants).

My point was just that if we are to drop the constant from the declaration, 
we'll have to amend that DWARFASTParserClang logic that you linked so it finds 
the correct variable definition and take the constant off of that.

> It would be nice to add this as a way to indicate this is a constexpr and 
> that we need to do something special with it.

I agree, though i think that can be done in isolation as a follow-up PR.

> Is there anyway we can just leave the `DW_AT_const_value` in the 
> `DW_TAG_member` and then have the `DW_TAG_variable` point to the 
> `DW_TAG_member` using a `DW_AT_specification` or `DW_AT_abstract_origin`? My 
> guess this isn't great DWARF where we have a `DW_TAG_variable` have a 
> specification or abstract origin that points to a different DWARF tag.

The variable definition *will* have a specification back to the declaration.

> Or maybe we can include the DW_AT_const_value in both places?

The ask to drop the constant off of the declaration comes from the 
DWARFParallelLinker work where it was causing non-deterministic output. But 
@dwblaikie @avl-llvm will know more about that



https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[Med Ismail Bennani via lldb-commits]

https://github.com/medismailben approved this pull request.

Makes sense. LGTM!

https://github.com/llvm/llvm-project/pull/70979
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

MachProcess has a MachTask as an ivar.  In the MachProcess dtor, we call 
MachTask::Clear() to clear its state, before running the dtor of all our ivars, 
including the MachTask one.

When we attach on darwin, MachProcess calls MachTask::StartExceptionThread 
which does the task_for_pid and then starts a thread to listen for mach 
messages.  Then MachProcess calls ptrace(PT_ATTACHEXC).  If that ptrace() 
fails, MachProcess will call MachTask::Clear.  But the exception thread is now 
up  running and is not stopped; its ivars will be reset by the Clear() 
method, and its object will be freed after the dtor runs.

Actually eliciting a crash in this scenario is very timing sensitive; I 
hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate it on my 
desktop and was unable.  But looking at the source, and an occasional crash 
report we've received, it's clear that this is possible.

rdar://117521198

---
Full diff: https://github.com/llvm/llvm-project/pull/70979.diff


1 Files Affected:

- (modified) lldb/tools/debugserver/source/MacOSX/MachTask.mm (+2) 


``diff
diff --git a/lldb/tools/debugserver/source/MacOSX/MachTask.mm 
b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
index 4f5b4039243f662..fd2ac64ac6cf79c 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachTask.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
@@ -145,6 +145,8 @@
 //--
 void MachTask::Clear() {
   // Do any cleanup needed for this task
+  if (m_exception_thread)
+ShutDownExcecptionThread();
   m_task = TASK_NULL;
   m_exception_thread = 0;
   m_exception_port = MACH_PORT_NULL;

``




https://github.com/llvm/llvm-project/pull/70979
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] [debugserver] Shut down the exception thread when clearing (PR #70979)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda created 
https://github.com/llvm/llvm-project/pull/70979

MachProcess has a MachTask as an ivar.  In the MachProcess dtor, we call 
MachTask::Clear() to clear its state, before running the dtor of all our ivars, 
including the MachTask one.

When we attach on darwin, MachProcess calls MachTask::StartExceptionThread 
which does the task_for_pid and then starts a thread to listen for mach 
messages.  Then MachProcess calls ptrace(PT_ATTACHEXC).  If that ptrace() 
fails, MachProcess will call MachTask::Clear.  But the exception thread is now 
up & running and is not stopped; its ivars will be reset by the Clear() method, 
and its object will be freed after the dtor runs.

Actually eliciting a crash in this scenario is very timing sensitive; I 
hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate it on my 
desktop and was unable.  But looking at the source, and an occasional crash 
report we've received, it's clear that this is possible.

rdar://117521198

>From 027e2ce8fcad6f1d6f5776033a938e34156cfaa7 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Wed, 1 Nov 2023 13:25:55 -0700
Subject: [PATCH] [lldb] [debugserver] Shut down the exception thread when
 clearing

MachProcess has a MachTask as an ivar.  In the MachProcess dtor,
we call MachTask::Clear() to clear its state, before running the
dtor of all our ivars, including the MachTask one.

When we attach on darwin, MachProcess calls MachTask::StartExceptionThread
which does the task_for_pid and then starts a thread to listen for
mach messages.  Then MachProcess calls ptrace(PT_ATTACHEXC).  If
that ptrace() fails, MachProcess will call MachTask::Clear.  But
the exception thread is now up & running and is not stopped; its
ivars will be reset by the Clear() method, and its object will be
freed after the dtor runs.

Actually eliciting a crash in this scenario is very timing sensitive;
I hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate
it on my desktop and was unable.  But looking at the source, and an
occasional crash report we've received, it's clear that this is
possible.

rdar://117521198
---
 lldb/tools/debugserver/source/MacOSX/MachTask.mm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lldb/tools/debugserver/source/MacOSX/MachTask.mm 
b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
index 4f5b4039243f662..fd2ac64ac6cf79c 100644
--- a/lldb/tools/debugserver/source/MacOSX/MachTask.mm
+++ b/lldb/tools/debugserver/source/MacOSX/MachTask.mm
@@ -145,6 +145,8 @@
 //--
 void MachTask::Clear() {
   // Do any cleanup needed for this task
+  if (m_exception_thread)
+ShutDownExcecptionThread();
   m_task = TASK_NULL;
   m_exception_thread = 0;
   m_exception_port = MACH_PORT_NULL;

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

https://github.com/medismailben commented:

Thanks for taking care of this. LGTM with some comments.

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

@@ -93,6 +93,10 @@ class DynamicRegisterInfo {
 return llvm::iterator_range(m_regs);
   }
 
+  llvm::iterator_range registers_mutable() {

medismailben wrote:

Can't this be just an overload of the `registers()` method above ? 

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

@@ -109,6 +110,24 @@ class Architecture : public PluginInterface {
   virtual const MemoryTagManager *GetMemoryTagManager() const {
 return nullptr;
   }
+
+  // This returns true if a write to the named register should cause lldb to
+  // reconfigure its register information. For example on AArch64 writing to vg
+  // to change the vector length means lldb has to change the size of 
registers.
+  virtual bool RegisterWriteCausesReconfigure(const char *name) const {

medismailben wrote:

+1

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

@@ -762,82 +756,22 @@ uint32_t 
GDBRemoteRegisterContext::ConvertRegisterKindToRegisterNumber(
   return m_reg_info_sp->ConvertRegisterKindToRegisterNumber(kind, num);
 }
 
-void GDBRemoteRegisterContext::AArch64Reconfigure() {
-  assert(m_reg_info_sp);
-
-  // Once we start to reconfigure registers, we cannot read any of them.
-  // So we must read VG and SVG up front.
-
-  const uint64_t fail_value = LLDB_INVALID_ADDRESS;
-  std::optional vg_reg_value;
-  const RegisterInfo *vg_reg_info = m_reg_info_sp->GetRegisterInfo("vg");
-  if (vg_reg_info) {
-// Make sure we get the latest value of vg from the remote.
-SetRegisterIsValid(vg_reg_info, false);
-uint32_t vg_reg_num = vg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(vg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  vg_reg_value = reg_value;
-  }
-
-  std::optional svg_reg_value;
-  const RegisterInfo *svg_reg_info = m_reg_info_sp->GetRegisterInfo("svg");
-  if (svg_reg_info) {
-// When vg is written it is automatically made invalid. Writing vg will 
also
-// change svg if we're in streaming mode but it will not be made invalid
-// so do this manually so the following read gets the latest svg value.
-SetRegisterIsValid(svg_reg_info, false);
-
-uint32_t svg_reg_num = svg_reg_info->kinds[eRegisterKindLLDB];
-uint64_t reg_value = ReadRegisterAsUnsigned(svg_reg_num, fail_value);
-if (reg_value != fail_value && reg_value <= 32)
-  svg_reg_value = reg_value;
-  }
-
-  if (vg_reg_value)
-m_reg_info_sp->UpdateARM64SVERegistersInfos(*vg_reg_value);
-  if (svg_reg_value)
-m_reg_info_sp->UpdateARM64SMERegistersInfos(*svg_reg_value);
-
-  // At this point if we have updated any registers, their offsets will all be
-  // invalid. If we did, we need to update them all.
-  if (vg_reg_value || svg_reg_value) {
-m_reg_info_sp->ConfigureOffsets();
-// From here we are able to read registers again.
-
-// Make a heap based buffer that is big enough to store all registers
-m_reg_data.SetData(std::make_shared(
-m_reg_info_sp->GetRegisterDataByteSize(), 0));
-m_reg_data.SetByteOrder(GetByteOrder());
-  }
-}
-
-void GDBRemoteDynamicRegisterInfo::UpdateARM64SVERegistersInfos(uint64_t vg) {
-  // SVE Z register size is vg x 8 bytes.
-  uint32_t z_reg_byte_size = vg * 8;
-
-  // SVE vector length has changed, accordingly set size of Z, P and FFR
-  // registers. Also invalidate register offsets it will be recalculated
-  // after SVE register size update.
-  for (auto  : m_regs) {
-if (reg.value_regs == nullptr) {
-  if (reg.name[0] == 'z' && isdigit(reg.name[1]))
-reg.byte_size = z_reg_byte_size;
-  else if (reg.name[0] == 'p' && isdigit(reg.name[1]))
-reg.byte_size = vg;
-  else if (strcmp(reg.name, "ffr") == 0)
-reg.byte_size = vg;
-}
-reg.byte_offset = LLDB_INVALID_INDEX32;
-  }
+bool GDBRemoteRegisterContext::RegisterWriteCausesReconfigure(
+const char *name) {
+  ExecutionContext exe_ctx(CalculateThread());
+  Process *process = exe_ctx.GetProcessPtr();
+  const Architecture *architecture =
+  process->GetTarget().GetArchitecturePlugin();
+  return architecture && architecture->RegisterWriteCausesReconfigure(name);

medismailben wrote:

Nice!

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Med Ismail Bennani via lldb-commits]

https://github.com/medismailben edited 
https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

[Greg Clayton via lldb-commits]

clayborg wrote:

> Sorry about the noise. All the reverts are in a private branch on my fork 
> repo. I didn't know it would broadcast to all the people who worked on the 
> reverted commits. My apologies.

No worries! I am getting used to the new github workflow. I will watch the 
revert messages more closely to make sure they aren't on upstream. Sorry for 
the noise from me!

https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[Greg Clayton via lldb-commits]

clayborg wrote:

> > The DWARFASTParserClang.cpp will try to create the class from the DWARF for 
> > the class definition. You will need to find the DW_TAG_variable when we are 
> > creating the static field if there is no DW_AT_const_value in the 
> > DW_TAG_member. But we also need to support the DW_AT_const_value being in 
> > the DW_TAG_member since older DWARF will be emitted like this.
> 
> That's 100% correct. I was thinking, before [this 
> block](https://github.com/llvm/llvm-project/blob/8b91de5d6a3f98dcc00bbd286e339e512f7e3682/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L2909-L2919)
>  where we check for the existence of a `const_value_form`, we could try to 
> look for the definition and take the constant off of that.
> 
> What's interesting is that with this patch, the expression evaluator 
> successfully finds the `DW_TAG_variable`s which have a location attribute but 
> not if they have a constant instead of a location. It's probably some logic 
> that assumes statics always have a location

The DWARFASTParserClang, with the current state of things, will automatically 
add the const value initializer to the clang AST field. See 
`DWARFASTParserClang::ParseSingleMember(...)` around the `// Handle static 
members` around 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2882. The code 
extracts the `llvm::Expected const_value_or_err` and then calls 
`TypeSystemClang::SetIntegerInitializerForVariable(v, *const_value_or_err);` to 
set the constant value of the static member. 

I think the expression parser knows how to grab this value if it is in a static 
member variable. If this isn't there, it assumes there is a global variable 
that backs it and that we will be able to find the location of this variable in 
memory. The expression parser will ask for the address of this value during 
expression evaluation when it resolves the symbols.

> 
> > Are we going to emit a DW_AT_const_expr now in the DW_TAG_member? If so, 
> > then we will know that we need to look for the DW_TAG_variable. I don't 
> > think clang emitted the DW_AT_const_expr attribute before.
> 
> That wasn't part of this patch. But would make sense to add (i've noticed GCC 
> adds that attribute)

It would be nice to add this as a way to indicate this is a constexpr and that 
we need to do something special with it.

Is there anyway we can just leave the `DW_AT_const_value` in the 
`DW_TAG_member` and then have the `DW_TAG_variable` point to the 
`DW_TAG_member` using a `DW_AT_specification` or `DW_AT_abstract_origin`? My 
guess this isn't great DWARF where we have a `DW_TAG_variable` have a 
specification or abstract origin that points to a different DWARF tag.

Or maybe we can include the DW_AT_const_value in both places?

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Simplify handing of scalable registers using vg and svg (PR #70914)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda approved this pull request.

This looks good to me, but this is at least partially overlapping with the 
change in https://github.com/llvm/llvm-project/pull/70950 right? 

https://github.com/llvm/llvm-project/pull/70914
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang-tools-extra] [llvm] [clang] [compiler-rt] [flang] [lldb] [lld] [libcxx] [YAMLParser] Unfold multi-line scalar values (PR #70898)

[Igor Kudrin via lldb-commits]

https://github.com/igorkudrin updated 
https://github.com/llvm/llvm-project/pull/70898

>From 113c03bbf773c71d329ab2afd063753365e4ac68 Mon Sep 17 00:00:00 2001
From: Igor Kudrin 
Date: Thu, 26 Oct 2023 13:19:08 -0700
Subject: [PATCH] [YAMLParser] Unfold multi-line scalar values

Long scalar values can be split into multiple lines to improve
readability. The rules are described in Section 6.5. "Line Folding",
https://yaml.org/spec/1.2.2/#65-line-folding. In addition, for flow
scalar styles, the Spec states that "All leading and trailing white
space characters on each line are excluded from the content",
https://yaml.org/spec/1.2.2/#73-flow-scalar-styles.

The patch implements these unfolding rules for double-quoted,
single-quoted, and plain scalars.
---
 llvm/include/llvm/Support/YAMLParser.h  |   9 +-
 llvm/lib/Support/YAMLParser.cpp | 364 +---
 llvm/test/YAMLParser/spec-09-01.test|  11 +-
 llvm/test/YAMLParser/spec-09-02.test|  31 +-
 llvm/test/YAMLParser/spec-09-03.test|   7 +-
 llvm/test/YAMLParser/spec-09-04.test|   3 +-
 llvm/test/YAMLParser/spec-09-05.test|   7 +-
 llvm/test/YAMLParser/spec-09-06.test|   3 +-
 llvm/test/YAMLParser/spec-09-07.test|  11 +-
 llvm/test/YAMLParser/spec-09-08.test|  15 +-
 llvm/test/YAMLParser/spec-09-09.test|   7 +-
 llvm/test/YAMLParser/spec-09-10.test|   3 +-
 llvm/test/YAMLParser/spec-09-11.test|   6 +-
 llvm/test/YAMLParser/spec-09-13.test|  11 +-
 llvm/test/YAMLParser/spec-09-16.test|  17 +-
 llvm/test/YAMLParser/spec-09-17.test|   3 +-
 llvm/test/YAMLParser/spec1.2-07-05.test |   8 +
 llvm/test/YAMLParser/spec1.2-07-06.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-09.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-12.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-14.test |  23 ++
 21 files changed, 367 insertions(+), 193 deletions(-)
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-05.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-06.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-09.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-12.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-14.test

diff --git a/llvm/include/llvm/Support/YAMLParser.h 
b/llvm/include/llvm/Support/YAMLParser.h
index f4767641647c217..9d95a1e13a0dff4 100644
--- a/llvm/include/llvm/Support/YAMLParser.h
+++ b/llvm/include/llvm/Support/YAMLParser.h
@@ -240,9 +240,14 @@ class ScalarNode final : public Node {
 private:
   StringRef Value;
 
-  StringRef unescapeDoubleQuoted(StringRef UnquotedValue,
- StringRef::size_type Start,
+  StringRef getDoubleQuotedValue(StringRef UnquotedValue,
  SmallVectorImpl ) const;
+
+  static StringRef getSingleQuotedValue(StringRef RawValue,
+SmallVectorImpl );
+
+  static StringRef getPlainValue(StringRef RawValue,
+ SmallVectorImpl );
 };
 
 /// A block scalar node is an opaque datum that can be presented as a
diff --git a/llvm/lib/Support/YAMLParser.cpp b/llvm/lib/Support/YAMLParser.cpp
index 1422e40f91944ae..96b9aa95a96b3a6 100644
--- a/llvm/lib/Support/YAMLParser.cpp
+++ b/llvm/lib/Support/YAMLParser.cpp
@@ -2030,187 +2030,219 @@ bool Node::failed() const {
 }
 
 StringRef ScalarNode::getValue(SmallVectorImpl ) const {
-  // TODO: Handle newlines properly. We need to remove leading whitespace.
-  if (Value[0] == '"') { // Double quoted.
-// Pull off the leading and trailing "s.
-StringRef UnquotedValue = Value.substr(1, Value.size() - 2);
-// Search for characters that would require unescaping the value.
-StringRef::size_type i = UnquotedValue.find_first_of("\\\r\n");
-if (i != StringRef::npos)
-  return unescapeDoubleQuoted(UnquotedValue, i, Storage);
+  if (Value[0] == '"')
+return getDoubleQuotedValue(Value, Storage);
+  if (Value[0] == '\'')
+return getSingleQuotedValue(Value, Storage);
+  return getPlainValue(Value, Storage);
+}
+
+static StringRef
+parseScalarValue(StringRef UnquotedValue, SmallVectorImpl ,
+ StringRef LookupChars,
+ std::function &)>
+ UnescapeCallback) {
+  size_t I = UnquotedValue.find_first_of(LookupChars);
+  if (I == StringRef::npos)
 return UnquotedValue;
-  } else if (Value[0] == '\'') { // Single quoted.
-// Pull off the leading and trailing 's.
-StringRef UnquotedValue = Value.substr(1, Value.size() - 2);
-StringRef::size_type i = UnquotedValue.find('\'');
-if (i != StringRef::npos) {
-  // We're going to need Storage.
-  Storage.clear();
-  Storage.reserve(UnquotedValue.size());
-  for (; i != StringRef::npos; i = UnquotedValue.find('\'')) {
-StringRef Valid(UnquotedValue.begin(), i);
-llvm::append_range(Storage, Valid);
-Storage.push_back('\'');
-UnquotedValue = UnquotedValue.substr(i + 2);
-  }
-  

[Lldb-commits] [lld] [lldb] [flang] [libcxx] [compiler-rt] [clang-tools-extra] [llvm] [clang] [YAMLParser] Unfold multi-line scalar values (PR #70898)

[Igor Kudrin via lldb-commits]

https://github.com/igorkudrin updated 
https://github.com/llvm/llvm-project/pull/70898

>From 113c03bbf773c71d329ab2afd063753365e4ac68 Mon Sep 17 00:00:00 2001
From: Igor Kudrin 
Date: Thu, 26 Oct 2023 13:19:08 -0700
Subject: [PATCH] [YAMLParser] Unfold multi-line scalar values

Long scalar values can be split into multiple lines to improve
readability. The rules are described in Section 6.5. "Line Folding",
https://yaml.org/spec/1.2.2/#65-line-folding. In addition, for flow
scalar styles, the Spec states that "All leading and trailing white
space characters on each line are excluded from the content",
https://yaml.org/spec/1.2.2/#73-flow-scalar-styles.

The patch implements these unfolding rules for double-quoted,
single-quoted, and plain scalars.
---
 llvm/include/llvm/Support/YAMLParser.h  |   9 +-
 llvm/lib/Support/YAMLParser.cpp | 364 +---
 llvm/test/YAMLParser/spec-09-01.test|  11 +-
 llvm/test/YAMLParser/spec-09-02.test|  31 +-
 llvm/test/YAMLParser/spec-09-03.test|   7 +-
 llvm/test/YAMLParser/spec-09-04.test|   3 +-
 llvm/test/YAMLParser/spec-09-05.test|   7 +-
 llvm/test/YAMLParser/spec-09-06.test|   3 +-
 llvm/test/YAMLParser/spec-09-07.test|  11 +-
 llvm/test/YAMLParser/spec-09-08.test|  15 +-
 llvm/test/YAMLParser/spec-09-09.test|   7 +-
 llvm/test/YAMLParser/spec-09-10.test|   3 +-
 llvm/test/YAMLParser/spec-09-11.test|   6 +-
 llvm/test/YAMLParser/spec-09-13.test|  11 +-
 llvm/test/YAMLParser/spec-09-16.test|  17 +-
 llvm/test/YAMLParser/spec-09-17.test|   3 +-
 llvm/test/YAMLParser/spec1.2-07-05.test |   8 +
 llvm/test/YAMLParser/spec1.2-07-06.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-09.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-12.test |   7 +
 llvm/test/YAMLParser/spec1.2-07-14.test |  23 ++
 21 files changed, 367 insertions(+), 193 deletions(-)
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-05.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-06.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-09.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-12.test
 create mode 100644 llvm/test/YAMLParser/spec1.2-07-14.test

diff --git a/llvm/include/llvm/Support/YAMLParser.h 
b/llvm/include/llvm/Support/YAMLParser.h
index f4767641647c217..9d95a1e13a0dff4 100644
--- a/llvm/include/llvm/Support/YAMLParser.h
+++ b/llvm/include/llvm/Support/YAMLParser.h
@@ -240,9 +240,14 @@ class ScalarNode final : public Node {
 private:
   StringRef Value;
 
-  StringRef unescapeDoubleQuoted(StringRef UnquotedValue,
- StringRef::size_type Start,
+  StringRef getDoubleQuotedValue(StringRef UnquotedValue,
  SmallVectorImpl ) const;
+
+  static StringRef getSingleQuotedValue(StringRef RawValue,
+SmallVectorImpl );
+
+  static StringRef getPlainValue(StringRef RawValue,
+ SmallVectorImpl );
 };
 
 /// A block scalar node is an opaque datum that can be presented as a
diff --git a/llvm/lib/Support/YAMLParser.cpp b/llvm/lib/Support/YAMLParser.cpp
index 1422e40f91944ae..96b9aa95a96b3a6 100644
--- a/llvm/lib/Support/YAMLParser.cpp
+++ b/llvm/lib/Support/YAMLParser.cpp
@@ -2030,187 +2030,219 @@ bool Node::failed() const {
 }
 
 StringRef ScalarNode::getValue(SmallVectorImpl ) const {
-  // TODO: Handle newlines properly. We need to remove leading whitespace.
-  if (Value[0] == '"') { // Double quoted.
-// Pull off the leading and trailing "s.
-StringRef UnquotedValue = Value.substr(1, Value.size() - 2);
-// Search for characters that would require unescaping the value.
-StringRef::size_type i = UnquotedValue.find_first_of("\\\r\n");
-if (i != StringRef::npos)
-  return unescapeDoubleQuoted(UnquotedValue, i, Storage);
+  if (Value[0] == '"')
+return getDoubleQuotedValue(Value, Storage);
+  if (Value[0] == '\'')
+return getSingleQuotedValue(Value, Storage);
+  return getPlainValue(Value, Storage);
+}
+
+static StringRef
+parseScalarValue(StringRef UnquotedValue, SmallVectorImpl ,
+ StringRef LookupChars,
+ std::function &)>
+ UnescapeCallback) {
+  size_t I = UnquotedValue.find_first_of(LookupChars);
+  if (I == StringRef::npos)
 return UnquotedValue;
-  } else if (Value[0] == '\'') { // Single quoted.
-// Pull off the leading and trailing 's.
-StringRef UnquotedValue = Value.substr(1, Value.size() - 2);
-StringRef::size_type i = UnquotedValue.find('\'');
-if (i != StringRef::npos) {
-  // We're going to need Storage.
-  Storage.clear();
-  Storage.reserve(UnquotedValue.size());
-  for (; i != StringRef::npos; i = UnquotedValue.find('\'')) {
-StringRef Valid(UnquotedValue.begin(), i);
-llvm::append_range(Storage, Valid);
-Storage.push_back('\'');
-UnquotedValue = UnquotedValue.substr(i + 2);
-  }
-  

[Lldb-commits] [libcxx] [clang] [compiler-rt] [clang-tools-extra] [lldb] [flang] [llvm] [openmp] [OpenMP] Add memory diff dump for kernel record-replay (PR #70667)

[via lldb-commits]

https://github.com/nmustakin updated 
https://github.com/llvm/llvm-project/pull/70667

>From 153c6d812939cd23bb71e53c71378117ed5b23c7 Mon Sep 17 00:00:00 2001
From: Nafis Mustakin 
Date: Mon, 30 Oct 2023 07:50:59 -0700
Subject: [PATCH 1/4] Add memory diff dump for kernel record-replay

---
 .../PluginInterface/PluginInterface.cpp   | 65 +++
 1 file changed, 54 insertions(+), 11 deletions(-)

diff --git 
a/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
 
b/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
index 0243f0205dbf0e5..8469e8eaf1593cd 100644
--- 
a/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
+++ 
b/openmp/libomptarget/plugins-nextgen/common/PluginInterface/PluginInterface.cpp
@@ -83,7 +83,7 @@ struct RecordReplayTy {
 return Plugin::success();
   }
 
-  void dumpDeviceMemory(StringRef Filename) {
+  void dumpDeviceMemory(StringRef Filename, bool saveDiff) {
 ErrorOr> DeviceMemoryMB =
 WritableMemoryBuffer::getNewUninitMemBuffer(MemorySize);
 if (!DeviceMemoryMB)
@@ -93,15 +93,58 @@ struct RecordReplayTy {
 MemoryStart, MemorySize, nullptr);
 if (Err)
   report_fatal_error("Error retrieving data for target pointer");
-
-StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), MemorySize);
-std::error_code EC;
-raw_fd_ostream OS(Filename, EC);
-if (EC)
+
+std::error_code EC; 
+raw_fd_ostream OS(Filename, EC); 
+if(EC)
   report_fatal_error("Error dumping memory to file " + Filename + " :" +
  EC.message());
-OS << DeviceMemory;
-OS.close();
+
+if (saveDiff){
+  //Get the pre-record memory filename  
+  SmallString<128> InputFilename = {Filename.split('.').first, ".memory"};
+  //read the pre-record memorydump
+  auto InputFileBuffer = MemoryBuffer::getFileOrSTDIN(InputFilename); 
+  if(std::error_code EC = InputFileBuffer.getError())
+report_fatal_error("Error reading pre-record device memory");
+  
+  StringRef InputBufferContents = (*InputFileBuffer)->getBuffer(); 
+  if(InputBufferContents.size() != MemorySize) 
+report_fatal_error("Error: Pre-record device memory size mismatch");
+  
+  //get current memory contents
+  StringRef DeviceMemoryContents(DeviceMemoryMB.get()->getBuffer().data(),
+ DeviceMemoryMB.get()->getBuffer().size());
+  
+  //compare pre-record memorydump to current contents
+  size_t i = 0;
+  while(i < MemorySize){
+//if mismatch found, create a new diff line
+//current format - location, size, differences ...
+if(InputBufferContents[i] != DeviceMemoryContents[i]){
+  OS << i << " "; //marks the start offset
+  SmallVector modified; 
+  modified.push_back(DeviceMemoryContents[i]);
+  size_t j = 1;
+  //loop until next match is found
+  while(InputBufferContents[i+j] != DeviceMemoryContents[i+j]){
+modified.push_back(DeviceMemoryContents[i+j]);
+j++;
+  }
+  OS << j << " "; //marks the length of the mismatching sequence
+  for(const auto  : modified)
+OS << value << " ";
+  OS << "\n"; 
+  i+=j+1; 
+}
+else i++; 
+  }
+}
+else {
+  StringRef DeviceMemory(DeviceMemoryMB.get()->getBufferStart(), 
MemorySize);
+  OS << DeviceMemory;
+}
+OS.close();  
   }
 
 public:
@@ -209,7 +252,7 @@ struct RecordReplayTy {
 JsonKernelInfo["ArgOffsets"] = json::Value(std::move(JsonArgOffsets));
 
 SmallString<128> MemoryFilename = {Name, ".memory"};
-dumpDeviceMemory(MemoryFilename);
+dumpDeviceMemory(MemoryFilename, false);
 
 SmallString<128> GlobalsFilename = {Name, ".globals"};
 dumpGlobals(GlobalsFilename, Image);
@@ -227,7 +270,7 @@ struct RecordReplayTy {
   void saveKernelOutputInfo(const char *Name) {
 SmallString<128> OutputFilename = {
 Name, (isRecording() ? ".original.output" : ".replay.output")};
-dumpDeviceMemory(OutputFilename);
+dumpDeviceMemory(OutputFilename, true);
   }
 
   void *alloc(uint64_t Size) {
@@ -1307,7 +1350,7 @@ Error GenericDeviceTy::launchKernel(void *EntryPtr, void 
**ArgPtrs,
 GenericKernel.getName(), GenericKernel.getImage(), ArgPtrs, ArgOffsets,
 KernelArgs.NumArgs, KernelArgs.NumTeams[0], KernelArgs.ThreadLimit[0],
 KernelArgs.Tripcount);
-
+   
   if (RecordReplay.isRecording())
 RecordReplay.saveImage(GenericKernel.getName(), GenericKernel.getImage());
 

>From 8daffad57074dd09287d321acd79c74a667eb65f Mon Sep 17 00:00:00 2001
From: Nafis Mustakin 
Date: Mon, 30 Oct 2023 08:39:40 -0700
Subject: [PATCH 2/4] Fix clang-formatting issues, accept reviewed suggestions

---
 .../PluginInterface/PluginInterface.cpp   | 78 

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[Michael Buch via lldb-commits]

Michael137 wrote:

> > That's true, if defined in a header, we'll emit a DW_TAG_variable for the 
> > constant in each compile unit the header is included in. GCC does do the 
> > right thing and only emit the definition DIE in a single CU. We should 
> > probably do the same. Though not sure at which level we want to catch that.
> 
> Which variable are you discussing here, `val1` or `val2`?
> 
> For `val1`, we could not emit the constant value and only emit the real 
> definition (there's /some/ risk here - non-ODR uses (or otherwise optimized 
> away uses) of the variable may mean that the object file that defines the 
> variable won't be linked in - so we'd miss the constant value) For `val2` the 
> variable is effectively `inline` and doesn't have a home, so there's no one 
> place that we can emit the `DW_TAG_variable` out-of-line definition...

Sorry for the confusion. I wasn't referring to that code snippet.

Also, I must've not looked at the GCC dwarfdump output carefully enough. 
Compiling two CUs that include a class with a `static constexpr` member will 
produce two separate definitions and two entries in `.debug_pubnames`:
```
.debug_pubnames 
   
global die-in-sect 0x0070, cu-in-sect 0x000c, die-in-cu 0x0070, 
cu-header-in-sect 0x 'Foo::val2'
   
global die-in-sect 0x007b, cu-in-sect 0x000c, die-in-cu 0x007b, 
cu-header-in-sect 0x 'main' 
  
global die-in-sect 0x0118, cu-in-sect 0x00b4, die-in-cu 0x0070, 
cu-header-in-sect 0x00a8 'Foo::val2'
   
global die-in-sect 0x0128, cu-in-sect 0x00b4, die-in-cu 0x0080, 
cu-header-in-sect 0x00a8 'Foo::func'   
```

So to answer Greg's question, yes we will potentially produce multiple variable 
definition DIEs. One for each CU that the header was included in

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Emit global variable definitions for static data members with constant initializers (PR #70639)

[David Blaikie via lldb-commits]

dwblaikie wrote:

> That's true, if defined in a header, we'll emit a DW_TAG_variable for the 
> constant in each compile unit the header is included in. GCC does do the 
> right thing and only emit the definition DIE in a single CU. We should 
> probably do the same. Though not sure at which level we want to catch that.

Which variable are you discussing here, `val1` or `val2`?

For `val1`, we could not emit the constant value and only emit the real 
definition (there's /some/ risk here - non-ODR uses (or otherwise optimized 
away uses) of the variable may mean that the object file that defines the 
variable won't be linked in - so we'd miss the constant value)
For `val2` the variable is effectively `inline` and doesn't have a home, so 
there's no one place that we can emit the `DW_TAG_variable` out-of-line 
definition... 

https://github.com/llvm/llvm-project/pull/70639
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][AArch64] Read SME2's ZT0 register from Linux core files (PR #70934)

[Alex Langford via lldb-commits]

@@ -339,6 +337,18 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const 
RegisterInfo *reg_info,
   value.SetFromMemoryData(*reg_info, src + sizeof(sve::user_za_header),
   reg_info->byte_size, lldb::eByteOrderLittle,
   error);
+} else if (m_register_info_up->IsSMERegZT(reg)) {
+  value.SetFromMemoryData(*reg_info, m_zt_data.GetDataStart(),
+  reg_info->byte_size, lldb::eByteOrderLittle,
+  error);
+} else {
+  offset = reg_info->byte_offset - m_register_info_up->GetSMEOffset();
+  assert(offset < sizeof(m_sme_pseudo_regs));

bulbazord wrote:

Since you're using an assert, I'll ask:
Is this a hard error that isn't recoverable from? Or could we do something else 
here?

https://github.com/llvm/llvm-project/pull/70934
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

[Daniel Chen via lldb-commits]

DanielCChen wrote:

I think it is still my fault because it is indeed a PR branch that I did revert 
even though it is on my forked repo. I guess GitHub is doing the right thing to 
notify everyone affected as the PR could be potentially merged onto upstream 
branch by accident if it is approved. Again, my apologies to everyone who got 
distracted by this event.

https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] Add the ability to get a C++ vtable ValueObject from another ValueObj… (PR #67599)

[via lldb-commits]

jimingham wrote:

That seems more like a GitHub problem than a you problem?  Seems weird to have 
to not touch a PR commit on a private branch lest you spam everyone with the 
notification...

Jim

> On Nov 1, 2023, at 8:49 AM, Daniel Chen ***@***.***> wrote:
> 
> 
> Sorry about the noise. All the reverts are in a private branch on my fork 
> repo. I didn't know it would broadcast to all the people who worked on the 
> reverted commits. My apologies.
> 
> —
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
> You are receiving this because your review was requested.
> 



https://github.com/llvm/llvm-project/pull/67599
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [clang] [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind (PR #70955)

[Vlad Serebrennikov via lldb-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/70955
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] a8ead56 - [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind (#70955)

[via lldb-commits]

Author: Vlad Serebrennikov
Date: 2023-11-01T20:38:28+04:00
New Revision: a8ead5606800261e94c2c703a366c59a12347fc4

URL: 
https://github.com/llvm/llvm-project/commit/a8ead5606800261e94c2c703a366c59a12347fc4
DIFF: 
https://github.com/llvm/llvm-project/commit/a8ead5606800261e94c2c703a366c59a12347fc4.diff

LOG: [clang][NFC] Rename ArgPassingKind to RecordArgPassingKind (#70955)

During the recent refactoring (b120fe8d3288c4dca1b5427ca34839ce8833f71c) this 
enum was moved out of `RecordDecl`. During post-commit review it was found out 
that its association with `RecordDecl` should be expressed in the name.

Added: 


Modified: 
clang/include/clang/AST/Decl.h
clang/include/clang/AST/DeclBase.h
clang/lib/AST/Decl.cpp
clang/lib/AST/DeclCXX.cpp
clang/lib/CodeGen/CGCall.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Removed: 




diff  --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index d9b00b1628ab25c..d8ea8c1dfb4f292 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -4063,7 +4063,7 @@ class EnumDecl : public TagDecl {
 /// returned from function calls. This takes into account the target-specific
 /// and version-specific rules along with the rules determined by the
 /// language.
-enum class ArgPassingKind {
+enum class RecordArgPassingKind {
   /// The argument of this type can be passed directly in registers.
   CanPassInRegs,
 
@@ -4216,14 +4216,15 @@ class RecordDecl : public TagDecl {
   /// it must have at least one trivial, non-deleted copy or move constructor.
   /// FIXME: This should be set as part of completeDefinition.
   bool canPassInRegisters() const {
-return getArgPassingRestrictions() == ArgPassingKind::CanPassInRegs;
+return getArgPassingRestrictions() == RecordArgPassingKind::CanPassInRegs;
   }
 
-  ArgPassingKind getArgPassingRestrictions() const {
-return static_cast(RecordDeclBits.ArgPassingRestrictions);
+  RecordArgPassingKind getArgPassingRestrictions() const {
+return static_cast(
+RecordDeclBits.ArgPassingRestrictions);
   }
 
-  void setArgPassingRestrictions(ArgPassingKind Kind) {
+  void setArgPassingRestrictions(RecordArgPassingKind Kind) {
 RecordDeclBits.ArgPassingRestrictions = llvm::to_underlying(Kind);
   }
 

diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 6704c0cd41ecd3d..df1d6e8a3b5af72 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -1399,7 +1399,7 @@ enum class DeductionCandidate : unsigned char {
   Aggregate,
 };
 
-enum class ArgPassingKind;
+enum class RecordArgPassingKind;
 enum class OMPDeclareReductionInitKind;
 enum class ObjCImplementationControl;
 enum class LinkageSpecLanguageIDs;

diff  --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 28243a76712d63e..6efc177d61c03ba 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -4932,7 +4932,7 @@ RecordDecl::RecordDecl(Kind DK, TagKind TK, const 
ASTContext ,
   setHasNonTrivialToPrimitiveDestructCUnion(false);
   setHasNonTrivialToPrimitiveCopyCUnion(false);
   setParamDestroyedInCallee(false);
-  setArgPassingRestrictions(ArgPassingKind::CanPassInRegs);
+  setArgPassingRestrictions(RecordArgPassingKind::CanPassInRegs);
   setIsRandomized(false);
   setODRHash(0);
 }

diff  --git a/clang/lib/AST/DeclCXX.cpp b/clang/lib/AST/DeclCXX.cpp
index 066b62b7c24110d..4002c63e9f94c12 100644
--- a/clang/lib/AST/DeclCXX.cpp
+++ b/clang/lib/AST/DeclCXX.cpp
@@ -446,8 +446,8 @@ CXXRecordDecl::setBases(CXXBaseSpecifier const * const 
*Bases,
   setHasVolatileMember(true);
 
 if (BaseClassDecl->getArgPassingRestrictions() ==
-ArgPassingKind::CanNeverPassInRegs)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+RecordArgPassingKind::CanNeverPassInRegs)
+  setArgPassingRestrictions(RecordArgPassingKind::CanNeverPassInRegs);
 
 // Keep track of the presence of mutable fields.
 if (BaseClassDecl->hasMutableFields())
@@ -1032,7 +1032,7 @@ void CXXRecordDecl::addedMember(Decl *D) {
 
 // Structs with __weak fields should never be passed directly.
 if (LT == Qualifiers::OCL_Weak)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+  setArgPassingRestrictions(RecordArgPassingKind::CanNeverPassInRegs);
 
 Data.HasIrrelevantDestructor = false;
 
@@ -1226,8 +1226,8 @@ void CXXRecordDecl::addedMember(Decl *D) {
 if (FieldRec->hasVolatileMember())
   setHasVolatileMember(true);
 if (FieldRec->getArgPassingRestrictions() ==
-ArgPassingKind::CanNeverPassInRegs)
-  setArgPassingRestrictions(ArgPassingKind::CanNeverPassInRegs);
+

[Lldb-commits] [lldb] [lldb][AArch64] Move register info reconfigure into architecture plugin (PR #70950)

[Jonas Devlieghere via lldb-commits]

@@ -109,6 +110,24 @@ class Architecture : public PluginInterface {
   virtual const MemoryTagManager *GetMemoryTagManager() const {
 return nullptr;
   }
+
+  // This returns true if a write to the named register should cause lldb to
+  // reconfigure its register information. For example on AArch64 writing to vg
+  // to change the vector length means lldb has to change the size of 
registers.
+  virtual bool RegisterWriteCausesReconfigure(const char *name) const {

JDevlieghere wrote:

Why a `const char*` and not a `StringRef`? That would get rid of the `strcmp` 
in the AArch64 implementation. 

https://github.com/llvm/llvm-project/pull/70950
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits