[Lldb-commits] [PATCH] D158583: Fix shared library loading when users define duplicate _r_debug structure.

[Greg Clayton via Phabricator via lldb-commits]

clayborg updated this revision to Diff 552966.
clayborg added a comment.

Address review comments:

- Added documentation in DYLDRendezvous.h to explain how things are supposed to 
work
- Updated the documentation in DYLDRendezvous::GetAction() to explain why we 
need to work around seeing two consecutive eAdd states
- Greatly simplify the test that was added per suggestions


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158583/new/

https://reviews.llvm.org/D158583

Files:
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.h
  lldb/test/API/functionalities/dyld-multiple-rdebug/Makefile
  
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py
  lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.cpp
  lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.h
  lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp

Index: lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp
@@ -0,0 +1,32 @@
+#include "library_file.h"
+#include 
+#include 
+// Make a duplicate "_r_debug" symbol that is visible. This is the global
+// variable name that the dynamic loader uses to communicate changes in shared
+// libraries that get loaded and unloaded. LLDB finds the address of this
+// variable by reading the DT_DEBUG entry from the .dynamic section of the main
+// executable.
+// What will happen is the dynamic loader will use the "_r_debug" symbol from
+// itself until the a.out executable gets loaded. At this point the new
+// "_r_debug" symbol will take precedence over the orignal "_r_debug" symbol
+// from the dynamic loader and the copy below will get updated with shared
+// library state changes while the version that LLDB checks in the dynamic
+// loader stays the same for ever after this.
+//
+// When our DYLDRendezvous.cpp tries to check the state in the _r_debug
+// structure, it will continue to get the last eAdd as the state before the
+// switch in symbol resolution.
+//
+// Before a fix in LLDB, this would mean that we wouldn't ever load any shared
+// libraries since DYLDRendezvous was waiting to see a eAdd state followed by a
+// eConsistent state which would trigger the adding of shared libraries, but we
+// would never see this change because the local copy below is actually what
+// would get updated. Now if DYLDRendezvous detects two eAdd states in a row,
+// it will load the shared libraries instead of doing nothing and a log message
+// will be printed out if "log enable lldb dyld" is active.
+r_debug _r_debug;
+
+int main() {
+  library_function(); // Break here
+  return 0;
+}
Index: lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.h
===
--- /dev/null
+++ lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.h
@@ -0,0 +1 @@
+int library_function();
Index: lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.cpp
@@ -0,0 +1,7 @@
+#include "library_file.h"
+#include 
+
+int library_function(void) {
+  puts(__FUNCTION__); // Library break here
+  return 0;
+}
Index: lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py
===
--- /dev/null
+++ lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py
@@ -0,0 +1,45 @@
+"""
+Test that LLDB can launch a linux executable through the dynamic loader where
+the main executable has an extra exported "_r_debug" symbol that used to mess
+up shared library loading with DYLDRendezvous and the POSIX dynamic loader
+plug-in. What used to happen is that any shared libraries other than the main
+executable and the dynamic loader and VSDO would not get loaded. This test
+checks to make sure that we still load libraries correctly when we have
+multiple "_r_debug" symbols. See comments in the main.cpp source file for full
+details on what the problem is.
+"""
+
+import lldb
+import os
+
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestDyldWithMultipleRDebug(TestBase):
+@skipIf(oslist=no_match(["linux"]))
+@no_debug_info_test
+def test(self):
+self.build()
+
+ctx = self.platformContext
+lib_shortname = "testlib"
+lib_fullname = (
+ctx.shlib_prefix + lib_shortname + "." + ctx.shlib_extension
+)
+
+# Run to a breakpoint in main.cpp to ensure we can hit breakpoints
+# in the main executable. Setting breakpoints by file and line 

[Lldb-commits] [PATCH] D158323: [lldb/infrastructure] Revamp lldb.llvm.org

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere accepted this revision as: JDevlieghere.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

This patch changes the theme and removes the inline table-of-contents that are 
always shown on the right. If there are any other changes needed to better 
support the theme we can apply them as we discover them. LGTM.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158323/new/

https://reviews.llvm.org/D158323

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

[Lldb-commits] [PATCH] D158323: [lldb/infrastructure] Revamp lldb.llvm.org

[Med Ismail Bennani via Phabricator via lldb-commits]

mib updated this revision to Diff 552871.
mib added a comment.

Revert deletions to `formatting.rst`


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158323/new/

https://reviews.llvm.org/D158323

Files:
  lldb/docs/_static/lldb.css
  lldb/docs/conf.py
  lldb/docs/resources/build.rst
  lldb/docs/resources/caveats.rst
  lldb/docs/resources/overview.rst
  lldb/docs/resources/projects.rst
  lldb/docs/resources/test.rst
  lldb/docs/use/formatting.rst
  lldb/docs/use/intel_pt.rst
  lldb/docs/use/map.rst
  lldb/docs/use/ondemand.rst
  lldb/docs/use/python-reference.rst
  lldb/docs/use/python.rst
  lldb/docs/use/qemu-testing.rst
  lldb/docs/use/remote.rst
  lldb/docs/use/symbolication.rst
  lldb/docs/use/symbols.rst
  lldb/docs/use/troubleshooting.rst
  lldb/docs/use/tutorial.rst
  lldb/docs/use/variable.rst

Index: lldb/docs/use/variable.rst
===
--- lldb/docs/use/variable.rst
+++ lldb/docs/use/variable.rst
@@ -1,9 +1,6 @@
 Variable Formatting
 ===
 
-.. contents::
-   :local:
-
 LLDB has a data formatters subsystem that allows users to define custom display
 options for their variables.
 
Index: lldb/docs/use/tutorial.rst
===
--- lldb/docs/use/tutorial.rst
+++ lldb/docs/use/tutorial.rst
@@ -5,9 +5,6 @@
 command set. We will start with some details on lldb command structure and
 syntax to help orient you.
 
-.. contents::
-   :local:
-
 Command Structure
 -
 
Index: lldb/docs/use/troubleshooting.rst
===
--- lldb/docs/use/troubleshooting.rst
+++ lldb/docs/use/troubleshooting.rst
@@ -1,9 +1,6 @@
 Troubleshooting
 ===
 
-.. contents::
-   :local:
-
 File and Line Breakpoints Are Not Getting Hit
 -
 
Index: lldb/docs/use/symbols.rst
===
--- lldb/docs/use/symbols.rst
+++ lldb/docs/use/symbols.rst
@@ -1,9 +1,6 @@
 Symbols on macOS
 
 
-.. contents::
-   :local:
-
 On macOS, debug symbols are often in stand alone bundles called **dSYM** files.
 These are bundles that contain DWARF debug information and other resources
 related to builds and debug info.
Index: lldb/docs/use/symbolication.rst
===
--- lldb/docs/use/symbolication.rst
+++ lldb/docs/use/symbolication.rst
@@ -1,10 +1,6 @@
 Symbolication
 =
 
-.. contents::
-   :local:
-
-
 LLDB is separated into a shared library that contains the core of the debugger,
 and a driver that implements debugging and a command interpreter. LLDB can be
 used to symbolicate your crash logs and can often provide more information than
Index: lldb/docs/use/remote.rst
===
--- lldb/docs/use/remote.rst
+++ lldb/docs/use/remote.rst
@@ -23,9 +23,6 @@
 debugging this whole process is transparent to the user. The platform binary is
 not used in this case, since no file transfers are needed.
 
-.. contents::
-   :local:
-
 Preparation for Remote Debugging
 -
 
Index: lldb/docs/use/qemu-testing.rst
===
--- lldb/docs/use/qemu-testing.rst
+++ lldb/docs/use/qemu-testing.rst
@@ -1,9 +1,6 @@
 Testing LLDB using QEMU
 ===
 
-.. contents::
-   :local:
-
 QEMU system mode emulation
 --
 
Index: lldb/docs/use/python.rst
===
--- lldb/docs/use/python.rst
+++ lldb/docs/use/python.rst
@@ -11,9 +11,6 @@
 Python scripting to find a bug in a program that searches for text in a
 large binary tree.
 
-.. contents::
-   :local:
-
 The Test Program and Input
 --
 
Index: lldb/docs/use/python-reference.rst
===
--- lldb/docs/use/python-reference.rst
+++ lldb/docs/use/python-reference.rst
@@ -10,9 +10,6 @@
 Of course, in this context it has full access to the LLDB API - with some
 additional conveniences we will call out in the FAQ.
 
-.. contents::
-   :local:
-
 Documentation
 --
 
Index: lldb/docs/use/ondemand.rst
===
--- lldb/docs/use/ondemand.rst
+++ lldb/docs/use/ondemand.rst
@@ -11,9 +11,6 @@
 is queried for very common types, or global name lookups fail due to a mistyped
 expression.
 
-.. contents::
-   :local:
-
 When should I consider enabling this feature?
 -
 
Index: lldb/docs/use/map.rst
===
--- lldb/docs/use/map.rst
+++ lldb/docs/use/map.rst
@@ -6,1834 +6,1344 @@
 are often long, but any unique short form can be used. Instead of 

[Lldb-commits] [PATCH] D158663: [lldb] Fix stdcpp type summary mistakenly marked as regex (NFC)

[Dave Lee via Phabricator via lldb-commits]

kastiglione created this revision.
kastiglione added a reviewer: jingham.
Herald added a project: All.
kastiglione requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

`std::basic_string` is not a regex, and treating it as such could 
unintentionally
cause a formatter to substring match a template type parameter, for example:
`std::vector>`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D158663

Files:
  lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp


Index: lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -1009,7 +1009,7 @@
   cpp_category_sp->AddTypeSummary("std::string", eFormatterMatchExact,
   std_string_summary_sp);
   cpp_category_sp->AddTypeSummary("std::basic_string",
-  eFormatterMatchRegex, std_string_summary_sp);
+  eFormatterMatchExact, std_string_summary_sp);
   cpp_category_sp->AddTypeSummary(
   "std::basic_string,std::allocator >",
   eFormatterMatchExact, std_string_summary_sp);


Index: lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
===
--- lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
+++ lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
@@ -1009,7 +1009,7 @@
   cpp_category_sp->AddTypeSummary("std::string", eFormatterMatchExact,
   std_string_summary_sp);
   cpp_category_sp->AddTypeSummary("std::basic_string",
-  eFormatterMatchRegex, std_string_summary_sp);
+  eFormatterMatchExact, std_string_summary_sp);
   cpp_category_sp->AddTypeSummary(
   "std::basic_string,std::allocator >",
   eFormatterMatchExact, std_string_summary_sp);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D158583: Fix shared library loading when users define duplicate _r_debug structure.

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In D158583#4609320 , @DavidSpickett 
wrote:

> I'm not familiar with this mechanism but just out of curiosity: `ld.so loads 
> the main executable and any dependent shared libraries and wants to update 
> the "_r_debug" structure, but it now finds "_r_debug" in the a.out program 
> and updates the state in this other copy`
>
> Is this some undefined behaviour or is there a good use case for this? From 
> the program's point of view.

This is just how name lookups happen across shared library boundaries as far as 
I know. External symbols get resolved by searching the shared libraries 
including the main executable.

I have verified this is indeed what is happening by debugging the ld.so binary 
and stepping through it at this code in rtld.c:

  /* Notify the debugger all new objects are now ready to go.  We must re-get
 the address since by now the variable might be in another object.  */
  r = _dl_debug_initialize (0, LM_ID_BASE);
  r->r_state = RT_CONSISTENT;
  _dl_debug_state ();

The code for _dl_debug_initialize() looks like:

  struct r_debug *
  _dl_debug_initialize (ElfW(Addr) ldbase, Lmid_t ns)
  {
struct r_debug *r;
  
if (ns == LM_ID_BASE)
  r = &_r_debug; /// <- this will switch to 
else
  r = (dl_ns)[ns]._ns_debug;
  
if (r->r_map == NULL || ldbase != 0)
  {
/* Tell the debugger where to find the map of loaded objects.  */
r->r_version = 1/* R_DEBUG_VERSION XXX */;
r->r_ldbase = ldbase ?: _r_debug.r_ldbase;
r->r_map = (void *) GL(dl_ns)[ns]._ns_loaded;
r->r_brk = (ElfW(Addr)) &_dl_debug_state;
  }
  
return r;
  }

And the line "r = &_r_debug;" picks up the first item in the library search 
paths for "_r_debug" which gets the one from the a.out program...




Comment at: 
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp:260-266
+// the dynamic loader. The problem happens as soon as the executable or
+// shared library that exports another "_r_debug" is loaded by the dynamic
+// loader due to the way symbols are found using the shared library search
+// paths will mean that the new copy takes precedence over the one in the
+// dynamic loader and the dynamic loader will be updating the other copy
+// somewhere else that we won't find and that copy will have the
+// eConsistent state.

DavidSpickett wrote:
> DavidSpickett wrote:
> > Can we split this sentence just for readability? Bullet points of each step 
> > might be clearer.
> What you have in the commit message basically.
yeah, I was tired last night when finishing this up, I will grab the stuff from 
the commit message



Comment at: 
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py:22
+@no_debug_info_test
+@skipIf(oslist=["linux"], archs=["arm"])
+def test(self):

DavidSpickett wrote:
> Any specific reason for this? Not that it really matters, it'll get plenty of 
> testing elsewhere.
Yeah, copy paste issue. I would be able to remove this.



Comment at: 
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py:28
+exe = self.getBuildArtifact("a.out")
+print(exe)
+target = self.dbg.CreateTarget(exe)

DavidSpickett wrote:
> Leftover debug print.
good catch, yes!



Comment at: 
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py:54
+self.assertIn("main",
+  thread.GetFrameAtIndex(0).GetDisplayFunctionName())
+process.Continue()

aprantl wrote:
> You should be able to shorten the test setup considerably by using 
> lldbutil.run_to_name_breakpoint() and only manually setting the second 
> breakpoint afterwards.
will do


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158583/new/

https://reviews.llvm.org/D158583

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

[Lldb-commits] [PATCH] D158583: Fix shared library loading when users define duplicate _r_debug structure.

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added inline comments.



Comment at: 
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py:54
+self.assertIn("main",
+  thread.GetFrameAtIndex(0).GetDisplayFunctionName())
+process.Continue()

You should be able to shorten the test setup considerably by using 
lldbutil.run_to_name_breakpoint() and only manually setting the second 
breakpoint afterwards.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158583/new/

https://reviews.llvm.org/D158583

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

[Lldb-commits] [PATCH] D158323: [lldb/infrastructure] Revamp lldb.llvm.org

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: lldb/docs/conf.py:52-57
 try:
 import sphinx_automodapi.automodapi
 except ModuleNotFoundError:
 print(
 f"install sphinx_automodapi with {sys.executable} -m pip install 
sphinx_automodapi"
 )

We should do something similar for the `furo` theme. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158323/new/

https://reviews.llvm.org/D158323

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

[Lldb-commits] [lldb] a6c97a1 - [lldb/test] Fix `Crashlog/no-args.test` on ASAN builds (NFC)

[Med Ismail Bennani via lldb-commits]

Author: Med Ismail Bennani
Date: 2023-08-23T07:32:35-07:00
New Revision: a6c97a1a308e413bda63cbeaa3bebe7b2e739902

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

LOG: [lldb/test] Fix `Crashlog/no-args.test` on ASAN builds (NFC)

This should fix the Sanitizer Green Dragon LLDB Bot:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-sanitized/4633

Signed-off-by: Med Ismail Bennani 

Added: 


Modified: 
lldb/test/Shell/ScriptInterpreter/Python/Crashlog/no-args.test

Removed: 




diff  --git a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/no-args.test 
b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/no-args.test
index 6c1af2de771a63..cad2f2443ac1e7 100644
--- a/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/no-args.test
+++ b/lldb/test/Shell/ScriptInterpreter/Python/Crashlog/no-args.test
@@ -6,6 +6,6 @@
 # CHECK: Symbolicate one or more darwin crash log files to provide source file 
and line
 # CHECK: positional arguments:
 # CHECK-NEXT: FILE  crash report(s) to symbolicate (default: 
None)
-# CHECK: options:
+# CHECK: option
 # CHECK:  -h, --helpshow this help message and exit
 



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

[Lldb-commits] [PATCH] D158583: Fix shared library loading when users define duplicate _r_debug structure.

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added inline comments.



Comment at: 
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp:260-266
+// the dynamic loader. The problem happens as soon as the executable or
+// shared library that exports another "_r_debug" is loaded by the dynamic
+// loader due to the way symbols are found using the shared library search
+// paths will mean that the new copy takes precedence over the one in the
+// dynamic loader and the dynamic loader will be updating the other copy
+// somewhere else that we won't find and that copy will have the
+// eConsistent state.

DavidSpickett wrote:
> Can we split this sentence just for readability? Bullet points of each step 
> might be clearer.
What you have in the commit message basically.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158583/new/

https://reviews.llvm.org/D158583

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

[Lldb-commits] [PATCH] D158583: Fix shared library loading when users define duplicate _r_debug structure.

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

I'm not familiar with this mechanism but just out of curiosity: `ld.so loads 
the main executable and any dependent shared libraries and wants to update the 
"_r_debug" structure, but it now finds "_r_debug" in the a.out program and 
updates the state in this other copy`

Is this some undefined behaviour or is there a good use case for this? From the 
program's point of view.




Comment at: 
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp:260-266
+// the dynamic loader. The problem happens as soon as the executable or
+// shared library that exports another "_r_debug" is loaded by the dynamic
+// loader due to the way symbols are found using the shared library search
+// paths will mean that the new copy takes precedence over the one in the
+// dynamic loader and the dynamic loader will be updating the other copy
+// somewhere else that we won't find and that copy will have the
+// eConsistent state.

Can we split this sentence just for readability? Bullet points of each step 
might be clearer.



Comment at: 
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py:22
+@no_debug_info_test
+@skipIf(oslist=["linux"], archs=["arm"])
+def test(self):

Any specific reason for this? Not that it really matters, it'll get plenty of 
testing elsewhere.



Comment at: 
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py:28
+exe = self.getBuildArtifact("a.out")
+print(exe)
+target = self.dbg.CreateTarget(exe)

Leftover debug print.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158583/new/

https://reviews.llvm.org/D158583

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

[Lldb-commits] [PATCH] D158506: [lldb][AArch64] Add release notes and documentation for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett added a comment.

> LGTM, fwiw.

Thanks! I wanted to have someone who wasn't knee deep in this to look it over.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158506/new/

https://reviews.llvm.org/D158506

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

[Lldb-commits] [PATCH] D158506: [lldb][AArch64] Add release notes and documentation for SME

[David Spickett via Phabricator via lldb-commits]

DavidSpickett updated this revision to Diff 552623.
DavidSpickett added a comment.

- Correct speeling.
- Drop repeated word.
- Clarify vg/vq/vl explanation and end with a listing of each value for the 
example shown.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158506/new/

https://reviews.llvm.org/D158506

Files:
  lldb/docs/index.rst
  lldb/docs/use/aarch64-linux.rst
  llvm/docs/ReleaseNotes.rst

Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -154,6 +154,10 @@
 * Methods in SBHostOS related to threads have had their implementations
   removed. These methods will return a value indicating failure.
 
+* LLDB now supports debugging the Scalable Matrix Extension (SME) on AArch64
+  Linux for both running processes and core files. For details refer to the
+  `AArch64 Linux documentation `_.
+
 Changes to Sanitizers
 -
 * HWASan now defaults to detecting use-after-scope bugs.
Index: lldb/docs/use/aarch64-linux.rst
===
--- /dev/null
+++ lldb/docs/use/aarch64-linux.rst
@@ -0,0 +1,191 @@
+Using LLDB On AArch64 Linux
+===
+
+This page explains the details of debugging certain AArch64 extensions using
+LLDB. If something is not mentioned here, it likely works as you would expect.
+
+This is not a replacement for ptrace and Linux Kernel documentation. This covers
+how LLDB has chosen to use those things and how that effects your experience as
+a user.
+
+Scalable Vector Extension (SVE)
+---
+
+See `here `__
+to learn about the extension and `here `__
+for the Linux Kernel's handling of it.
+
+In LLDB you will be able to see the following new registers:
+
+* ``z0-z31`` vector registers, each one has size equal to the vector length.
+* ``p0-p15`` predicate registers, each one containing 1 bit per byte in the vector
+  length. Making each one vector length / 8 sized.
+* ``ffr`` the first fault register, same size as a predicate register.
+* ``vg``, the vector length in "granules". Each granule is a double word, aka
+  8 bytes.
+
+.. code-block::
+
+   Scalable Vector Extension Registers:
+ vg = 0x0002
+ z0 = {0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 <...> }
+   <...>
+ p0 = {0xff 0xff}
+   <...>
+ffr = {0xff 0xff}
+
+The example above has a vector length of 16 bytes. This is shown in LLDB as a
+``vg`` of 2. 2 doublewords is 2*8 which is 16 bytes. Elsewhere you may see
+``vq`` which is the vector length in quadwords (16 bytes). Where you see ``vl``
+it is in bytes. So here we have ``vg`` 2, ``vq`` 1 and ``vl`` 16.
+
+Changing the Vector Length
+..
+
+While you can count the size of a P or Z register, it is intended that ``vg`` be
+used to find the current vector length.
+
+vg can be written. Writing the current vector length changes nothing. If you
+increase the vector length, the registers will likely be reset to 0. If you
+decrease it, LLDB will truncate the Z registers but everything else will be reset
+to 0.
+
+Generally you should not assume that SVE state after changing the vector length
+is in any way the same as it was previously. If you need to do it, do it before
+a function's first use of SVE.
+
+Z Register Presentation
+...
+
+LLDB makes no attempt to predict how an SVE Z register will be used. Even if the
+next SVE instruction (which may some distance away) would use, for example, 32
+bit elements, LLDB prints ``z0`` as single bytes.
+
+If you know what format you are going to use, give a format option::
+
+  (lldb) register read z0 -f uint32_t[]
+  z0 = {0x01010101 0x01010101 0x01010101 0x01010101}
+
+FPSIMD and SVE Modes
+
+
+Prior to the debugee's first use of SVE, it is in what the Linux Kernel terms
+SIMD mode. Only the FPU is being used. In this state LLDB will still show the
+SVE registers however the values are simply the FPU values zero extended up to
+the vector length.
+
+On first access to SVE, the process goes into SVE mode. Now the Z values are
+in the real Z registers.
+
+You can also trigger this with LLDB by writing to an SVE register. Note that
+there is no way to undo this change from within LLDB. However, the debugee
+itself could do something to end up back in SIMD mode.
+
+Expression evaluation
+.
+
+If you evaluate an expression, all SVE state is saved prior to, and restored
+after the expression has been evaluated. Including the register values and
+vector length.
+
+Scalable Matrix Extension (SME)
+---
+
+See `here 

[Lldb-commits] [PATCH] D158583: Fix shared library loading when users define duplicate _r_debug structure.

[Greg Clayton via Phabricator via lldb-commits]

clayborg created this revision.
clayborg added reviewers: labath, JDevlieghere, GeorgeHuyubo, yinghuitan, 
kusmour.
Herald added a project: All.
clayborg requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

We ran into a case where shared libraries would fail to load in some processes 
on linux. The issue turned out to be if the main executable or a shared library 
defined a symbol named "_r_debug", then it would cause problems once the 
executable that contained it was loaded into the process. The "_r_debug" 
structure is currently found by looking through the .dynamic section in the 
main executable and finding the DT_DEBUG entry which points to this structure. 
The dynamic loader will update this structure as shared libraries are loaded 
and LLDB watches the contents of this structure as the dyld breakpoint is hit. 
Currently we expect the "state" in this structure to change as things happen. 
An issue comes up if someone defines another "_r_debug" struct in their program:

  r_debug _r_debug;

If this code is included, a new "_r_debug" structure is created and it causes 
problems once the executable is loaded. This is because of the way symbol 
lookups happen in linux: they use the shared library list in the order it 
created and the dynamic loader is always last. So at some point the dynamic 
loader will start updating this other copy of "_r_debug", yet LLDB is only 
watching the copy inside of the dynamic loader.

Steps that show the problem are:

- lldb finds the "_r_debug" structure via the DT_DEBUG entry in the .dynamic 
section and this points to the "_r_debug" in ld.so
- ld.so modifies its copy of "_r_debug" with "state = eAdd" before it loads the 
shared libraries and calls the dyld function that LLDB has set a breakpoint on 
and we find this state and do nothing (we are waiting for a state of 
eConsistent to tell us the shared libraries have been fully loaded)
- ld.so loads the main executable and any dependent shared libraries and wants 
to update the "_r_debug" structure, but it now finds "_r_debug" in the a.out 
program and updates the state in this other copy
- lldb hits the notification breakpoint and checks the ld.so copy of "_r_debug" 
which still has a state of "eAdd". LLDB wants the new "eConsistent" state which 
will trigger the shared libraries to load, but it gets stale data and doesn't 
do anyhing and library load is missed. The "_r_debug" in a.out has the state 
set correctly, but we don't know which "_r_debug" is the right one.

The new fix detects the two "eAdd" states and loads shared libraries and will 
emit a log message in the "log enable lldb dyld" log channel which states there 
might be multiple "_r_debug" structs.

The correct solution is that no one should be adding a duplicate "_r_debug" 
symbol to their binaries, but we have programs that are doing this already and 
since it can be done, we should be able to work with this and keep debug 
sessions working as expected. If a user #includes the  file, they can 
just use the existing "_r_debug" structure as it is defined in this header file 
as "extern struct r_debug _r_debug;" and no local copies need to be made.

If your ld.so has debug info, you can easily see the duplicate "_r_debug" 
structs by doing:

  (lldb) target variable _r_debug --raw
  (r_debug) _r_debug = {
r_version = 1
r_map = 0x77e30210
r_brk = 140737349972416
r_state = RT_CONSISTENT
r_ldbase = 0
  }
  (r_debug) _r_debug = {
r_version = 1
r_map = 0x77e30210
r_brk = 140737349972416
r_state = RT_ADD
r_ldbase = 140737349943296
  }
  (lldb) target variable &_r_debug
  (r_debug *) &_r_debug = 0x55601040
  (r_debug *) &_r_debug = 0x77e301e0

And if you do a "image lookup --address " in the addresses, you can see 
one is in the a.out and one in the ld.so.

Adding more logging to print out the m_previous and m_current Rendezvous 
structures to make things more clear. Also added a log when we detect multiple 
eAdd states in a row to detect this problem in logs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D158583

Files:
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
  lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.h
  lldb/test/API/functionalities/dyld-multiple-rdebug/Makefile
  
lldb/test/API/functionalities/dyld-multiple-rdebug/TestDyldWithMultupleRDebug.py
  lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.cpp
  lldb/test/API/functionalities/dyld-multiple-rdebug/library_file.h
  lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp

Index: lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp
===
--- /dev/null
+++ lldb/test/API/functionalities/dyld-multiple-rdebug/main.cpp
@@ -0,0 +1,32 @@
+#include "library_file.h"
+#include 
+#include 
+// Make a duplicate "_r_debug" symbol that is visible.