Re: [Lldb-commits] [PATCH] D22831: [LLDB] Documentation for SBAddress class
Sorry for missing this! What options should I use when running it? On Mon, Sep 19, 2016 at 2:31 PM, Eugene Zelenko wrote: > Eugene.Zelenko added a subscriber: Eugene.Zelenko. > Eugene.Zelenko added a comment. > > Please rebase from trunk and run Clang-format. > > > Repository: > rL LLVM > > https://reviews.llvm.org/D22831 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] Updated documentation for SBAddress
I never heard back on this. Should I file a ticket? Thanks, John On Thu, Apr 7, 2016 at 4:59 PM, John Lindal wrote: > The patch is based off the latest code in the github mirror. It includes > some documentation changes for other classes, but the primary change is for > SBAddress. I intend to fill out the other classes in separate patches. > > I do not have committer access. Can somebody please merge this in? > > Thanks, > John Lindal > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D22831: [LLDB] Documentation for SBAddress class
jafl updated this revision to Diff 66678.
jafl added a comment.
Incorporated feedback
Repository:
rL LLVM
https://reviews.llvm.org/D22831
Files:
include/lldb/API/SBAddress.h
Index: include/lldb/API/SBAddress.h
===
--- include/lldb/API/SBAddress.h
+++ include/lldb/API/SBAddress.h
@@ -15,6 +15,74 @@
namespace lldb {
+//--
+/// \class SBAddress
+///
+/// Represents an address. An address may refer to code or data from an
+/// existing module (SBModule), or it may refer to something on the stack
+/// or heap.
+///
+/// SBAddress objects can represent two types of addresses: file address
+/// and load address.
+///
+/// File addresses refer to the raw address as it is known in the object
+/// file that the module is using. File addresses will match the virtual
+/// addresses that are found in the object file, such as the address values
+/// in the symbols in the native symbol tables, unwind tables and any other
+/// data structures in the object file format (ELF, mach-o, COFF). File
+/// addresses are not unique across multiple modules as many modules might
+/// contain a file address of 0x0 (possibly the first function in the .text
+/// section) since many object files, like shared libraries, have their
+/// virtual addresses start at 0x0.
+///
+/// Load addresses represent a unique location within a process' address
+/// space. A load address might represent a section/offset address within a
+/// process. In this case the SBAddress will have a valid section
+/// (lldb::SBAddress::GetSection() will return a SBSection that is valid),
+/// and a valid offset (lldb::addr_t lldb::SBAddress::GetOffset()) into
+/// that section. Or a load address might represent a unique location in
+/// the process' memory space that doesn't resolve to a section within an
+/// object file, like a location on the stack or heap. In this case the
+/// address will not have a valid section (lldb::SBSection
+/// lldb::SBAddress::GetSection() will return a SBSection that is *not*
+/// valid), and lldb::SBAddress::GetOffset() will return the value load
+/// address.
+///
+/// If an address has a valid section, the address might refer to things
+/// found in the debug information:
+///
+/// SBModule - the module that contains the section
+/// SBCompileUnit - the source file that was compiled to create this code
+/// SBFunction - the function that contains this address
+/// SBBlock - the deepest lexical block that contains the address within the SBFucntion
+/// SBLineEntry - the file and line and column that contains the address
+/// SBVariable - the static/global variable that contains the address
+///
+/// If there is no debug information, then the address might also refer to
+/// a symbol from the symbol table:
+///
+/// SBSymbol - the symbol that contains the address
+///
+/// If an address comes from an existing module, then it will be resolved
+/// into an offset from its containing section in that module. That way it
+/// can refer to the same logical location in the module that holds it even
+/// if the module is unloaded and loaded at different addresses. Module
+/// based SBAddresses are not bound to a particular target or process, but
+/// you can ask the SBAddress where/if it has been loaded in a particular
+/// target.
+///
+/// The individual Get*() functions grab individual objects for a given
+/// address and are less efficient if you want more than one symbol related
+/// objects. Use one of the following when you want multiple debug symbol
+/// related objects for an address:
+/// ~~~
+/// * lldb::SBSymbolContext SBAddress::GetSymbolContext (uint32_t resolve_scope);
+/// * lldb::SBSymbolContext SBTarget::ResolveSymbolContextForAddress (const SBAddress &addr, uint32_t resolve_scope);
+/// ~~~
+/// One or more bits from the SymbolContextItem enumerations can be
+/// logically OR'ed together to more efficiently retrieve multiple symbol
+/// objects.
+//--
class LLDB_API SBAddress
{
public:
@@ -33,73 +101,203 @@
const lldb::SBAddress &
operator = (const lldb::SBAddress &rhs);
+//--
+/// @return
+/// true if the object is valid. If the object is invalid, it is
+/// not safe to call any other methods.
+//--
bool
IsValid () const;
+//--
+/// Clears the address. The object is no longer valid.
+//--
void
Clear ();
+//--
+/// Get the file address.
+///
+/// @return
+/// The valid file address, or LLDB_INVALI
Re: [Lldb-commits] [PATCH] D22831: [LLDB] Documentation for SBAddress class
jafl updated this revision to Diff 67405.
jafl added a comment.
Incorporate additional feedback from Greg Clayton.
Repository:
rL LLVM
https://reviews.llvm.org/D22831
Files:
include/lldb/API/SBAddress.h
Index: include/lldb/API/SBAddress.h
===
--- include/lldb/API/SBAddress.h
+++ include/lldb/API/SBAddress.h
@@ -15,6 +15,93 @@
namespace lldb {
+//--
+/// \class SBAddress
+///
+/// Represents an address. An address may refer to code or data from an
+/// existing module (SBModule), or it may refer to something on the stack
+/// or heap.
+///
+/// SBAddress objects use two different kinds of addresses: file addresses
+/// and load addresses.
+///
+/// File addresses refer to the raw address as it is known in the object
+/// file that the module is using. File addresses will match the virtual
+/// addresses that are found in the object file, such as the address values
+/// in the symbols in the native symbol tables, unwind tables and any other
+/// data structures in the object file format (ELF, mach-o, COFF). File
+/// addresses are not unique across multiple modules as many modules might
+/// contain a file address of 0x0 (possibly the first function in the .text
+/// section) since many object files, like shared libraries, have their
+/// virtual addresses start at 0x0. Since file addresses are only unique
+/// within an SBModule, you must use a valid module object to resolve a
+/// file address into an SBAddress:
+///
+/// lldb::SBAddress SBModule::ResolveFileAddress (lldb::addr_t vm_addr);
+///
+/// File addresses are also useful in case you want to use other command
+/// line tools that know how to extract data from an object file, like
+/// objdump or many other tools that dump mach-o, ELF and COFF files.
+///
+/// Load addresses represent a unique location within a process' address
+/// space. A load address might represent a section/offset address within a
+/// process. In this case the SBAddress will have a valid section
+/// (lldb::SBAddress::GetSection() will return a SBSection that is valid),
+/// and a valid offset (lldb::addr_t lldb::SBAddress::GetOffset()) into
+/// that section. Or a load address might represent a unique location in
+/// the process' memory space that doesn't resolve to a section within an
+/// object file, like a location on the stack or heap. In this case the
+/// address will not have a valid section (lldb::SBSection
+/// lldb::SBAddress::GetSection() will return an SBSection that is *not*
+/// valid), and lldb::SBAddress::GetOffset() will return the value load
+/// address. You can resolve a load address back into a SBAddress by using
+/// either of:
+///
+/// SBAddress (lldb::addr_t load_addr, lldb::SBTarget &target);
+/// void SBAddress::SetLoadAddress (lldb::addr_t load_addr, lldb::SBTarget &target);
+///
+/// This will take the "load_addr" and figure out which section, if any,
+/// that the load address belongs to within the specified target. If
+/// "load_addr" belongs to a section, the resulting SBAddress objects will
+/// contain a valid section and offset (address that matches data in an
+/// object file's sections), otherwise it will have no section and the
+/// offset will match "load_addr" (stack or heap address).
+///
+/// If an address has a valid section, the address might refer to things
+/// found in the debug information:
+///
+/// SBModule - the module that contains the section
+/// SBCompileUnit - the source file that was compiled to create this code
+/// SBFunction - the function that contains this address
+/// SBBlock - the deepest lexical block that contains the address within the SBFucntion
+/// SBLineEntry - the file and line and column that contains the address
+/// SBVariable - the static/global variable that contains the address
+///
+/// If there is no debug information, then the address might also refer to
+/// a symbol from the symbol table:
+///
+/// SBSymbol - the symbol that contains the address
+///
+/// If an address comes from an existing module, then it will be resolved
+/// into an offset from its containing section in that module. That way it
+/// can refer to the same logical location in the module that holds it even
+/// if the module is unloaded and loaded at different addresses. Module
+/// based SBAddresses are not bound to a particular target or process, but
+/// you can ask the SBAddress where/if it has been loaded in a particular
+/// target.
+///
+/// The individual Get*() functions grab individual objects for a given
+/// address and are less efficient if you want more than one symbol related
+/// objects. Use one of the following when you want multiple debug symbol
+/// related objects for an address:
+/// ~~~
+/// * lldb::SBSymbolContext SBAddress::GetSymbolContext (uint32_t resolve_scope);
+/// * lldb::SBSymbolContext SBTarget::ResolveSymbolContextForAddress (const SBAddress &a
[Lldb-commits] Improving the documentation
Having completed my C++ app on top of lldb, I would like to improve the function-level documentation so others don't have to blunder around in the dark the way I did :) Here is a patch for SBAddress.h If this is the right direction, I will work my way through the rest of the SB*.h files. Thanks! John Lindal - diff --git a/include/lldb/API/SBAddress.h b/include/lldb/API/SBAddress.h index 4cbbee9..b324e90 100644 --- a/include/lldb/API/SBAddress.h +++ b/include/lldb/API/SBAddress.h @@ -33,27 +33,100 @@ public: const lldb::SBAddress & operator = (const lldb::SBAddress &rhs); +//-- +/// @return +/// true if the object is valid. If the object is invalid, it is +/// not safe to call any other methods. +//-- bool IsValid () const; +//-- +/// Clears the address. The object is no longer valid. +//-- void Clear (); +//-- +/// Get the file address. +/// +/// If an address comes from a file on disk that has section +/// relative addresses, then it has a virtual address that is +/// relative to a unique section in the object file. +/// +/// @return +/// The valid file virtual address, or LLDB_INVALID_ADDRESS if +/// the address doesn't have a file virtual address (image is +/// from memory only with no representation on disk). +//-- addr_t GetFileAddress () const; +//-- +/// Get the load address. +/// +/// If an address comes from a file on disk that has section +/// relative addresses, then it has a virtual address that is +/// relative to a unique section in the object file. Sections +/// get resolved at runtime by DynamicLoader plug-ins as images +/// (executables and shared libraries) get loaded/unloaded. If a +/// section is loaded, then the load address can be resolved. +/// +/// @param[in] target +/// The target in which to search. +/// +/// @return +/// The valid load virtual address, or LLDB_INVALID_ADDRESS if +/// the address is currently not loaded. +//-- addr_t GetLoadAddress (const lldb::SBTarget &target) const; +//-- +/// Set the section and address within the section. If it succeeds, +/// the object becomes valid. +/// +/// @param[in] section +/// A lldb::SBSection object to use as the section base. +/// +/// @param[in] offset +/// A new offset value for this object. +//-- void SetAddress (lldb::SBSection section, lldb::addr_t offset); +//-- +/// Tries to resolve the address within the target. If this fails, +/// assumes the address is absolute, e.g., on the stack or heap. If it +/// succeeds, the object becomes valid. +/// +/// @param[in] load_addr +/// A new offset value for this object. +/// +/// @param[in] target +/// The target within which the offset is valid. +//-- void SetLoadAddress (lldb::addr_t load_addr, lldb::SBTarget &target); + +//-- +/// Set the offset for this address, relative to the current section, +/// if any. +/// +/// @param[in] offset +/// A new offset value for this object. +//-- +// FIXME: Should this be SetOffsetAddress? bool OffsetAddress (addr_t offset); +//-- +/// Dump a description of this object to the given lldb::SBStream. +/// +/// @param[in] description +/// The stream to which to dump the object description. +//-- bool GetDescription (lldb::SBStream &description); @@ -63,10 +136,25 @@ public: // will only return valid values if the address has been resolved to a code // or data address using "void SBAddress::SetLoadAddress(...)" or // "lldb::SBAddress SBTarget::ResolveLoadAddress (...)". + +//-- +/// Lookup symb
Re: [Lldb-commits] Improving the documentation
Here is a refinement of SBAddress. The patch also includes updates to classes referenced by SBAddress. Does this read better? Thanks, John On Wed, Mar 9, 2016 at 11:56 AM, Jim Ingham wrote: > In the case of something like SBAddress, I think it would be better to > have a class header that explains file/load addresses and section offset > addresses. Then you can just use the terms in the function documentation, > and they can be shorter and more explicit. Trying to define terms inline > like this makes it harder both to define the term and to say what the > function does. It also means it is hard to avoid redundantly redefining > terms as they are used in different functions. > > Thanks for starting this process! > > Jim > > > > On Mar 9, 2016, at 11:47 AM, John Lindal via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > > > > Having completed my C++ app on top of lldb, I would like to improve the > function-level documentation so others don't have to blunder around in the > dark the way I did :) > > > > Here is a patch for SBAddress.h > > > > If this is the right direction, I will work my way through the rest of > the SB*.h files. > > > > Thanks! > > John Lindal > > > > - > > > > diff --git a/include/lldb/API/SBAddress.h b/include/lldb/API/SBAddress.h > > index 4cbbee9..b324e90 100644 > > --- a/include/lldb/API/SBAddress.h > > +++ b/include/lldb/API/SBAddress.h > > @@ -33,27 +33,100 @@ public: > > const lldb::SBAddress & > > operator = (const lldb::SBAddress &rhs); > > > > +//-- > > +/// @return > > +/// true if the object is valid. If the object is invalid, it > is > > +/// not safe to call any other methods. > > +//-- > > bool > > IsValid () const; > > > > +//-- > > +/// Clears the address. The object is no longer valid. > > +//-- > > void > > Clear (); > > > > +//-- > > +/// Get the file address. > > +/// > > +/// If an address comes from a file on disk that has section > > +/// relative addresses, then it has a virtual address that is > > +/// relative to a unique section in the object file. > > +/// > > +/// @return > > +/// The valid file virtual address, or LLDB_INVALID_ADDRESS if > > +/// the address doesn't have a file virtual address (image is > > +/// from memory only with no representation on disk). > > +//-- > > addr_t > > GetFileAddress () const; > > > > +//-- > > +/// Get the load address. > > +/// > > +/// If an address comes from a file on disk that has section > > +/// relative addresses, then it has a virtual address that is > > +/// relative to a unique section in the object file. Sections > > +/// get resolved at runtime by DynamicLoader plug-ins as images > > +/// (executables and shared libraries) get loaded/unloaded. If a > > +/// section is loaded, then the load address can be resolved. > > +/// > > +/// @param[in] target > > +/// The target in which to search. > > +/// > > +/// @return > > +/// The valid load virtual address, or LLDB_INVALID_ADDRESS if > > +/// the address is currently not loaded. > > +//-- > > addr_t > > GetLoadAddress (const lldb::SBTarget &target) const; > > > > +//-- > > +/// Set the section and address within the section. If it succeeds, > > +/// the object becomes valid. > > +/// > > +/// @param[in] section > > +/// A lldb::SBSection object to use as the section base. > > +/// > > +/// @param[in] offset > > +/// A new offset value for this object. > > +//-- > > void > > SetAddress (lldb::SBSection section, lldb::addr_t offset); > > >
Re: [Lldb-commits] Improving the documentation
> > Does this read better? > > > > Thanks, > > John > > > > On Wed, Mar 9, 2016 at 11:56 AM, Jim Ingham wrote: > > In the case of something like SBAddress, I think it would be better to > have a class header that explains file/load addresses and section offset > addresses. Then you can just use the terms in the function documentation, > and they can be shorter and more explicit. Trying to define terms inline > like this makes it harder both to define the term and to say what the > function does. It also means it is hard to avoid redundantly redefining > terms as they are used in different functions. > > > > Thanks for starting this process! > > > > Jim > > > > > > > On Mar 9, 2016, at 11:47 AM, John Lindal via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > > > > > > Having completed my C++ app on top of lldb, I would like to improve > the function-level documentation so others don't have to blunder around in > the dark the way I did :) > > > > > > Here is a patch for SBAddress.h > > > > > > If this is the right direction, I will work my way through the rest of > the SB*.h files. > > > > > > Thanks! > > > John Lindal > > > > > > - > > > > > > diff --git a/include/lldb/API/SBAddress.h > b/include/lldb/API/SBAddress.h > > > index 4cbbee9..b324e90 100644 > > > --- a/include/lldb/API/SBAddress.h > > > +++ b/include/lldb/API/SBAddress.h > > > @@ -33,27 +33,100 @@ public: > > > const lldb::SBAddress & > > > operator = (const lldb::SBAddress &rhs); > > > > > > + > //-- > > > +/// @return > > > +/// true if the object is valid. If the object is invalid, > it is > > > +/// not safe to call any other methods. > > > + > //-- > > > bool > > > IsValid () const; > > > > > > + > //-- > > > +/// Clears the address. The object is no longer valid. > > > + > //-- > > > void > > > Clear (); > > > > > > + > //-- > > > +/// Get the file address. > > > +/// > > > +/// If an address comes from a file on disk that has section > > > +/// relative addresses, then it has a virtual address that is > > > +/// relative to a unique section in the object file. > > > +/// > > > +/// @return > > > +/// The valid file virtual address, or LLDB_INVALID_ADDRESS if > > > +/// the address doesn't have a file virtual address (image is > > > +/// from memory only with no representation on disk). > > > + > //-- > > > addr_t > > > GetFileAddress () const; > > > > > > + > //-- > > > +/// Get the load address. > > > +/// > > > +/// If an address comes from a file on disk that has section > > > +/// relative addresses, then it has a virtual address that is > > > +/// relative to a unique section in the object file. Sections > > > +/// get resolved at runtime by DynamicLoader plug-ins as images > > > +/// (executables and shared libraries) get loaded/unloaded. If a > > > +/// section is loaded, then the load address can be resolved. > > > +/// > > > +/// @param[in] target > > > +/// The target in which to search. > > > +/// > > > +/// @return > > > +/// The valid load virtual address, or LLDB_INVALID_ADDRESS if > > > +/// the address is currently not loaded. > > > + > //-- > > > addr_t > > > GetLoadAddress (const lldb::SBTarget &target) const; > > > > > > + > //-- > > > +/// Set the section and address within the section. If it > succeeds, > > > +/// the object becomes valid. > > > +/// > >
Re: [Lldb-commits] Improving the documentation
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 "void SBAddress::SetLoadAddress(...)" or
> > -// "lldb::SBAddress SBTarget::ResolveLoadAddress (...)".
> > +//--
> > +/// Lookup symbol information for this address. This function will
> only
> > +/// return a valid object if the address has been resolved to a
> code or
> > +/// data address using "void SBAddress::SetLoadAddress(...)" or
> > +/// "lldb::SBAddress SBTarget::ResolveLoadAddress (...)".
> > +///
> > +/// @param[in] resolve_scope
> > +/// lldb::SymbolContextItem value specifying the scope in which
> to
> > +/// resolve this address.
> > +///
> > +/// @return
> > +/// lldb::SBSymbolContext with the result.
> > +//--
> >
> > You are faithfully representing the original docs, but they aren't
> right. For instance, load a program that has a "main" symbol, but don't
> run it, then do:
> >
> > (lldb) script
> > >>> func = lldb.target.FindFunctions("main")
> > >>> print len(func)
> > 1
> > >>> func = func[0]
> > >>> addr = func.symbol.GetStartAddress()
> > >>> sc = addr.GetSymbolContext(lldb.eSymbolContextEverything)
> > >>> print sc.symbol
> > id = {0x04df}, range = [0x000100018fa0-0x0001000191f6),
> name="main"
> >
> > So that worked just fine even though there were no load addresses around
> anywhere. ResolveSymbolContext needs an Address that can be
> > resolved to a Module, but that module doesn't need to be loaded...
> >
> > Also this bit:
> >
> > +/// @param[in] resolve_scope
> > +/// lldb::SymbolContextItem value specifying the scope in which
> to
> > +/// resolve this address.
> > +///
> >
> > isn't quite right. "The scope in which to resolve the address" makes it
> sound like this specifies some context you are using to resolve the address,
> > but it really determines how much information to fetch in the symbol
> context that the function returns. There should be some general discussion
> of the
> > SymbolContextItem (maybe where we document FindFunctions?) But in any
> case, here you can just "specifying how much information to fill in in the
> returned
> > SymbolContext.
> >
> > Jim
> >
> >
> >
> > > On Mar 9, 2016, at 2:24 PM, John Lindal
> wrote:
> > >
> > > Here is a refinement of SBAddress. The patch also includes updates to
> classes referenced by SBAddress.
> > >
> > > Does this read better?
> > >
> > > Thanks,
> > > John
> > >
> > > On Wed, Mar 9, 2016 at 11:56 AM, Jim Ingham wrote:
> > > In the case of something like SBAddress, I think it would be better to
> have a class header that explains file/load addresses and section offset
> addresses. Then you can just use the terms in the function documentation,
> and they can be shorter and more explicit. Trying to define terms inline
> like this makes it harder both to define the term and to say what the
> function does. It also means it is hard to avoid redundantly redefining
> terms as they are used in different functions.
> > >
> > > Thanks for starting this process!
> > >
> > > Jim
> > >
> > >
> > > > On Mar 9, 2016, at 11:47 AM, John Lindal via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> > > >
> > > > Having completed my C++ app on top of lldb, I would like to improve
> the function-level documentation so others don't have to blunder around in
> the dark the way I did :)
> > > >
> > > > Here is a patch for SBAddress.h
> > > >
> > > > If this is the right direction, I will work my way through the rest
> of the SB*.h files.
> > > >
> > > > Thanks!
> > > > John Lindal
> > > >
> > > > -
> > > >
> > > > diff --git a/include/lldb/API/SBAddress.h
> b/include/lldb/API/SBAddress.h
> > > > index 4cbbee9..b324e90 100644
> &
Re: [Lldb-commits] Improving the documentation
taining section in that module. That way it can refer to
> the same logical
> > > location as the module that holds it is unloaded and loaded at
> different addresses.
> > > Module based SBAddresses are not bound to a particular target or
> process, but you
> > > can ask the SBAddress where/if it has been loaded in a particular
> target.
> > >
> > > I don't think you need to mention the Dynamic loader plugin here, it
> isn't essential to know who tracks the
> > > loads to understand what these do. Also, you use "resolve" in the
> rest of the docs to mean "resolve to
> > > section/offset in a Module. So using it for loading libraries here is
> confusing. Better to define it
> > > here as you are going to use it.
> > >
> > > This bit doesn't seem right to me:
> > >
> > > -// The following queries 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 "void SBAddress::SetLoadAddress(...)" or
> > > -// "lldb::SBAddress SBTarget::ResolveLoadAddress (...)".
> > > +
> //--
> > > +/// Lookup symbol information for this address. This function
> will only
> > > +/// return a valid object if the address has been resolved to a
> code or
> > > +/// data address using "void SBAddress::SetLoadAddress(...)" or
> > > +/// "lldb::SBAddress SBTarget::ResolveLoadAddress (...)".
> > > +///
> > > +/// @param[in] resolve_scope
> > > +/// lldb::SymbolContextItem value specifying the scope in
> which to
> > > +/// resolve this address.
> > > +///
> > > +/// @return
> > > +/// lldb::SBSymbolContext with the result.
> > > +
> //--
> > >
> > > You are faithfully representing the original docs, but they aren't
> right. For instance, load a program that has a "main" symbol, but don't
> run it, then do:
> > >
> > > (lldb) script
> > > >>> func = lldb.target.FindFunctions("main")
> > > >>> print len(func)
> > > 1
> > > >>> func = func[0]
> > > >>> addr = func.symbol.GetStartAddress()
> > > >>> sc = addr.GetSymbolContext(lldb.eSymbolContextEverything)
> > > >>> print sc.symbol
> > > id = {0x04df}, range = [0x000100018fa0-0x0001000191f6),
> name="main"
> > >
> > > So that worked just fine even though there were no load addresses
> around anywhere. ResolveSymbolContext needs an Address that can be
> > > resolved to a Module, but that module doesn't need to be loaded...
> > >
> > > Also this bit:
> > >
> > > +/// @param[in] resolve_scope
> > > +/// lldb::SymbolContextItem value specifying the scope in
> which to
> > > +/// resolve this address.
> > > +///
> > >
> > > isn't quite right. "The scope in which to resolve the address" makes
> it sound like this specifies some context you are using to resolve the
> address,
> > > but it really determines how much information to fetch in the symbol
> context that the function returns. There should be some general discussion
> of the
> > > SymbolContextItem (maybe where we document FindFunctions?) But in any
> case, here you can just "specifying how much information to fill in in the
> returned
> > > SymbolContext.
> > >
> > > Jim
> > >
> > >
> > >
> > > > On Mar 9, 2016, at 2:24 PM, John Lindal <
> git...@newplanetsoftware.com> wrote:
> > > >
> > > > Here is a refinement of SBAddress. The patch also includes updates
> to classes referenced by SBAddress.
> > > >
> > > > Does this read better?
> > > >
> > > > Thanks,
> > > > John
> > > >
> > > > On Wed, Mar 9, 2016 at 11:56 AM, Jim Ingham
> wrote:
> > > > In the case of something like SBAddress, I think it would be better
>
[Lldb-commits] Updated documentation for SBAddress
The patch is based off the latest code in the github mirror. It includes some documentation changes for other classes, but the primary change is for SBAddress. I intend to fill out the other classes in separate patches. I do not have committer access. Can somebody please merge this in? Thanks, John Lindal SBAddress-docs.patch Description: Binary data ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] Updated documentation for SBAddress
The patch is based off the latest code in the github mirror. It includes some documentation changes for other classes, but the primary change is for SBAddress. I intend to fill out the other classes in separate patches. I do not have committer access. Can somebody please merge this in? Thanks, John Lindal SBAddress-docs.patch Description: Binary data ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
