bulbazord created this revision.
bulbazord added reviewers: JDevlieghere, clayborg, jingham, labath, mib.
Herald added a project: All.
bulbazord requested review of this revision.
Herald added a project: LLDB.
This is a proof-of-concept change that shows what it would take to use
the API headers as the source-of-truth for generating swig bindings instead of
using the interface files directly. It only covers SBAddress but can easily
extend to all the other SB classes.
The idea is to use the API headers as the "source of truth" when generating the
swig bindings. The swig interfaces include a bit more than the C++ API (e.g.
docstrings, python methods) but those can be conditionally included when we
invoke swig. To avoid "polluting" the headers in the LLDB framework on macOS, we
can use the unifdef utility to remove the swig bits as we copy them for staging.
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D142926
Files:
lldb/bindings/interface/SBAddress.i
lldb/bindings/interface/SBAddressDocstrings.i
lldb/bindings/interface/SBAddressExtensions.i
lldb/bindings/interfaces.swig
lldb/bindings/macros.swig
lldb/cmake/modules/LLDBFramework.cmake
lldb/include/lldb/API/SBAddress.h
Index: lldb/include/lldb/API/SBAddress.h
===================================================================
--- lldb/include/lldb/API/SBAddress.h
+++ lldb/include/lldb/API/SBAddress.h
@@ -11,6 +11,9 @@
#include "lldb/API/SBDefines.h"
#include "lldb/API/SBModule.h"
+#ifdef SWIG
+%include "interface/SBAddressDocstrings.i"
+#endif
namespace lldb {
@@ -27,7 +30,9 @@
~SBAddress();
+#ifndef SWIG
const lldb::SBAddress &operator=(const lldb::SBAddress &rhs);
+#endif
explicit operator bool() const;
@@ -107,7 +112,9 @@
const lldb_private::Address *operator->() const;
+#ifndef SWIG
friend bool LLDB_API operator==(const SBAddress &lhs, const SBAddress &rhs);
+#endif
lldb_private::Address *get();
@@ -123,8 +130,13 @@
std::unique_ptr<lldb_private::Address> m_opaque_up;
};
+#ifndef SWIG
bool LLDB_API operator==(const SBAddress &lhs, const SBAddress &rhs);
+#endif
} // namespace lldb
+#ifdef SWIG
+%include "interface/SBAddressExtensions.i"
+#endif
#endif // LLDB_API_SBADDRESS_H
Index: lldb/cmake/modules/LLDBFramework.cmake
===================================================================
--- lldb/cmake/modules/LLDBFramework.cmake
+++ lldb/cmake/modules/LLDBFramework.cmake
@@ -83,10 +83,13 @@
get_filename_component(basename ${header} NAME)
set(staged_header ${lldb_header_staging}/${basename})
+ # unifdef returns 0 when the file is unchanged and 1 if something was changed.
+ # That means if we successfully remove SWIG code, the build system believes
+ # that the command has failed and stops. This is undesirable.
add_custom_command(
DEPENDS ${header} OUTPUT ${staged_header}
- COMMAND ${CMAKE_COMMAND} -E copy ${header} ${staged_header}
- COMMENT "LLDB.framework: collect framework header")
+ COMMAND unifdef -USWIG -o ${staged_header} ${header} || (exit 0)
+ COMMENT "LLDB.framework: collect framework header and remove SWIG macros")
list(APPEND lldb_staged_headers ${staged_header})
endforeach()
Index: lldb/bindings/macros.swig
===================================================================
--- lldb/bindings/macros.swig
+++ lldb/bindings/macros.swig
@@ -27,3 +27,22 @@
}
}
%enddef
+
+// NOTE:
+// This is for when you are peforming the extension from outside of the class
+// instead of inside of it. If this change works out, it will replace
+// STRING_EXTENSION entirely.
+%define STRING_EXTENSION_OUTSIDE(Class)
+%extend lldb:: ## Class ## {
+ std::string __repr__(){
+ lldb::SBStream stream;
+ $self->GetDescription (stream);
+ const char *desc = stream.GetData();
+ size_t desc_len = stream.GetSize();
+ if (desc_len > 0 && (desc[desc_len-1] == '\n' || desc[desc_len-1] == '\r')) {
+ --desc_len;
+ }
+ return std::string(desc, desc_len);
+ }
+}
+%enddef
Index: lldb/bindings/interfaces.swig
===================================================================
--- lldb/bindings/interfaces.swig
+++ lldb/bindings/interfaces.swig
@@ -11,7 +11,7 @@
%include "lldb/API/SBDefines.h"
/* Python interface files with docstrings. */
-%include "./interface/SBAddress.i"
+%include "lldb/API/SBAddress.h"
%include "./interface/SBAttachInfo.i"
%include "./interface/SBBlock.i"
%include "./interface/SBBreakpoint.i"
Index: lldb/bindings/interface/SBAddressExtensions.i
===================================================================
--- lldb/bindings/interface/SBAddressExtensions.i
+++ lldb/bindings/interface/SBAddressExtensions.i
@@ -1,69 +1,6 @@
-//===-- SWIG Interface for SBAddress ----------------------------*- C++ -*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===----------------------------------------------------------------------===//
-
-namespace lldb {
-
-%feature("docstring",
-"A section + offset based address class.
-
-The SBAddress class allows addresses to be relative to a section
-that can move during runtime due to images (executables, shared
-libraries, bundles, frameworks) being loaded at different
-addresses than the addresses found in the object file that
-represents them on disk. There are currently two types of addresses
-for a section:
-
-* file addresses
-* load addresses
-
-File addresses represents the virtual addresses that are in the 'on
-disk' object files. These virtual addresses are converted to be
-relative to unique sections scoped to the object file so that
-when/if the addresses slide when the images are loaded/unloaded
-in memory, we can easily track these changes without having to
-update every object (compile unit ranges, line tables, function
-address ranges, lexical block and inlined subroutine address
-ranges, global and static variables) each time an image is loaded or
-unloaded.
-
-Load addresses represents the virtual addresses where each section
-ends up getting loaded at runtime. Before executing a program, it
-is common for all of the load addresses to be unresolved. When a
-DynamicLoader plug-in receives notification that shared libraries
-have been loaded/unloaded, the load addresses of the main executable
-and any images (shared libraries) will be resolved/unresolved. When
-this happens, breakpoints that are in one of these sections can be
-set/cleared.
-
-See docstring of SBFunction for example usage of SBAddress."
-) SBAddress;
-class SBAddress
-{
-public:
-
- SBAddress ();
-
- SBAddress (const lldb::SBAddress &rhs);
-
- SBAddress (lldb::SBSection section,
- lldb::addr_t offset);
-
- %feature("docstring", "
- Create an address by resolving a load address using the supplied target.") SBAddress;
- SBAddress (lldb::addr_t load_addr, lldb::SBTarget &target);
-
- ~SBAddress ();
-
- bool
- IsValid () const;
-
- explicit operator bool() const;
+STRING_EXTENSION_OUTSIDE(SBAddress)
+%extend lldb::SBAddress {
#ifdef SWIGPYTHON
// operator== is a free function, which swig does not handle, so we inject
// our own equality operator here
@@ -71,78 +8,7 @@
def __eq__(self, other):
return not self.__ne__(other)
%}
-#endif
-
- bool operator!=(const SBAddress &rhs) const;
-
- void
- Clear ();
-
- addr_t
- GetFileAddress () const;
- addr_t
- GetLoadAddress (const lldb::SBTarget &target) const;
-
- void
- SetLoadAddress (lldb::addr_t load_addr,
- lldb::SBTarget &target);
-
- bool
- OffsetAddress (addr_t offset);
-
- bool
- GetDescription (lldb::SBStream &description);
-
- lldb::SBSection
- GetSection ();
-
- lldb::addr_t
- SBAddress::GetOffset ();
-
- void
- SetAddress (lldb::SBSection section,
- lldb::addr_t offset);
-
- %feature("docstring", "
- GetSymbolContext() and the following can lookup symbol information for a given address.
- An address might refer to code or data from an existing module, or it
- might refer to something on the stack or heap. The following functions
- will only return valid values if the address has been resolved to a code
- or data address using :py:class:`SBAddress.SetLoadAddress' or
- :py:class:`SBTarget.ResolveLoadAddress`.") GetSymbolContext;
- lldb::SBSymbolContext
- GetSymbolContext (uint32_t resolve_scope);
-
- %feature("docstring", "
- GetModule() and the following grab individual objects for a given address and
- are less efficient if you want more than one symbol related objects.
- Use :py:class:`SBAddress.GetSymbolContext` or
- :py:class:`SBTarget.ResolveSymbolContextForAddress` when you want multiple
- debug symbol related objects for an address.
- One or more bits from the SymbolContextItem enumerations can be logically
- OR'ed together to more efficiently retrieve multiple symbol objects.") GetModule;
- lldb::SBModule
- GetModule ();
-
- lldb::SBCompileUnit
- GetCompileUnit ();
-
- lldb::SBFunction
- GetFunction ();
-
- lldb::SBBlock
- GetBlock ();
-
- lldb::SBSymbol
- GetSymbol ();
-
- lldb::SBLineEntry
- GetLineEntry ();
-
- STRING_EXTENSION(SBAddress)
-
-#ifdef SWIGPYTHON
%pythoncode %{
__runtime_error_str = 'This resolves the SBAddress using the SBTarget from lldb.target so this property can ONLY be used in the interactive script interpreter (i.e. under the lldb script command). For things like Python based commands and breakpoint callbacks use GetLoadAddress instead.'
@@ -186,7 +52,4 @@
load_addr = property(__get_load_addr_property__, __set_load_addr_property__, doc='''A read/write property that gets/sets the SBAddress using load address. This resolves the SBAddress using the SBTarget from lldb.target so this property can ONLY be used in the interactive script interpreter (i.e. under the lldb script command). For things like Python based commands and breakpoint callbacks use GetLoadAddress instead.''')
%}
#endif
-
-};
-
-} // namespace lldb
+}
Index: lldb/bindings/interface/SBAddressDocstrings.i
===================================================================
--- /dev/null
+++ lldb/bindings/interface/SBAddressDocstrings.i
@@ -0,0 +1,56 @@
+%feature("docstring",
+"A section + offset based address class.
+
+The SBAddress class allows addresses to be relative to a section
+that can move during runtime due to images (executables, shared
+libraries, bundles, frameworks) being loaded at different
+addresses than the addresses found in the object file that
+represents them on disk. There are currently two types of addresses
+for a section:
+
+* file addresses
+* load addresses
+
+File addresses represents the virtual addresses that are in the 'on
+disk' object files. These virtual addresses are converted to be
+relative to unique sections scoped to the object file so that
+when/if the addresses slide when the images are loaded/unloaded
+in memory, we can easily track these changes without having to
+update every object (compile unit ranges, line tables, function
+address ranges, lexical block and inlined subroutine address
+ranges, global and static variables) each time an image is loaded or
+unloaded.
+
+Load addresses represents the virtual addresses where each section
+ends up getting loaded at runtime. Before executing a program, it
+is common for all of the load addresses to be unresolved. When a
+DynamicLoader plug-in receives notification that shared libraries
+have been loaded/unloaded, the load addresses of the main executable
+and any images (shared libraries) will be resolved/unresolved. When
+this happens, breakpoints that are in one of these sections can be
+set/cleared.
+
+See docstring of SBFunction for example usage of SBAddress."
+) lldb::SBAddress;
+
+%feature("docstring", "
+Create an address by resolving a load address using the supplied target.")
+lldb::SBAddress::SBAddress;
+
+%feature("docstring", "
+GetSymbolContext() and the following can lookup symbol information for a given address.
+An address might refer to code or data from an existing module, or it
+might refer to something on the stack or heap. The following functions
+will only return valid values if the address has been resolved to a code
+or data address using :py:class:`SBAddress.SetLoadAddress' or
+:py:class:`SBTarget.ResolveLoadAddress`.") lldb::SBAddress::GetSymbolContext;
+
+%feature("docstring", "
+GetModule() and the following grab individual objects for a given address and
+are less efficient if you want more than one symbol related objects.
+Use :py:class:`SBAddress.GetSymbolContext` or
+:py:class:`SBTarget.ResolveSymbolContextForAddress` when you want multiple
+debug symbol related objects for an address.
+One or more bits from the SymbolContextItem enumerations can be logically
+OR'ed together to more efficiently retrieve multiple symbol objects.")
+lldb::SBAddress::GetModule;
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
