================
@@ -18,6 +18,26 @@ def tearDown(self):
if self.background_pid:
os.kill(self.background_pid, signal.SIGKILL)
+ def test_getname(self):
+ """Test the SBModule::GetName() method"""
+ self.build()
+ target, _, _, _ = lldbutil.run_to_source_breakpoint(
+ self, "// break here", lldb.SBFileSpec("main.c")
+ )
+
+ self.assertGreater(target.GetNumModules(), 0)
+ for i in range(target.GetNumModules()):
+ module = target.GetModuleAtIndex(i)
+ file_spec = module.GetFileSpec()
+ name = module.GetName()
+ if file_spec.IsValid() and file_spec.exists:
+#If file is valid and file exist, expect GetName() to be None
+ self.assertIsNone(name, f"Expected None for module with valid
file {file_spec.GetFilename()}, got {name!r}")
+ else:
+#If no valid file, expect GetName() to be a non - empty string
+ self.assertIsInstance(name, str)
+ self.assertTrue(name, "Expected a non-empty name for module
without a valid file")
----------------
labath wrote:
> If I follow correct the precedence of 'uniqueness' is
I don't think you can really order these, as they all have different
properties. The UUID (build-id) is assigned at build time, and it's supposed to
be unique -- but it may not be assigned, and you can't really guarantee its
uniqueness, which makes it unsuitable for some uses. The numeric ID uniquely
identifies a loaded copy of a specific module, but it's a purely internal
thing, so you can't use it to link two sessions together. The object name is
only meaningful within an archive (you can have two archives with the same
object), so it's best to think of these two as a single entity -- the
file+object name pair uniquely identifies an object file on a specific file
system at a specific point in time.
> Having a 'helper' accessor exposing the object name or the file name would
> solve my needs.
The file name is available already through `GetFileSpec` and it shows the vdso
"name":
```
(lldb) script for m in lldb.target.modules: print(m.GetFileSpec())
/bin/ls
/lib64/ld-linux-x86-64.so.2
[vdso]
```
Is that enough? If you want to also access the object name, I think the
simplest approach would be to expose `m_object_name` via `Get*Object*Name()` as
that makes it clear what it's doing and it matches the function name of
SBModuleSpec. Then you can combine these however you see fit on your end.
https://github.com/llvm/llvm-project/pull/150331
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
