Re: [lldb-dev] LLDB expressions confused by overloading
Hi Greg, It turns out that the problem I was having was fixed when I patched a bug in DwarfSymbolFile: http://reviews.llvm.org/D14538 But thanks for the additional info. Aidan On 12/11/2015 17:54, Greg Clayton wrote: On Nov 5, 2015, at 9:43 AM, Aidan Dodds via lldb-dev wrote: I believe I have tracked down an interesting bug which related to LLDBs expression parser. In my target program I have a math library, a shared object which makes use of clangs __attribute__((overloadable)) extension for C99. This causes the the function names in the math library to be mangled. A problem arises however since some of the function names mirror those exported by libm.so, and the function names in libm are not mangled. My problem scenario: If I call an expression during a debugging session, the symbol table of libm.so is consulted first and a match will be found. Later on in the expression setup, any dwarf information will be consulted for functions with this name. libm.so doesn't have any debugging info attached, however the math library of my target may. In this case the expression will now call which ever function it could first find dwarf info for, regardless of the name mangling. The net result is that a function will be called in my targets math library that may not match the given function signature. In my case this causes the expression to raise a SEGFAULT and fail. I was seeing an expression to call a vector4 function, in fact call the vector 2 version behinds the scenes. One solution to this problem seems to be to have the expression evaluator try and first look for any functions that may have a mangled name for the given function signature, and if that fails fall back to simply checking for the unmangled version, as is currently done. Would this make sense? It seems less then ideal to have a clash of mangled and unmangled names, but I can imagine this situation may not be all that rare. The correct fix for this is to have the DWARFASTParserClang, when it parses the function prototype, recognize that a C function (check the language of the compile unit) has a mangled name and enable the corresponding bit in the clang::FunctionType so that the expression parser knows to look for the mangled name when someone uses it. Then no changes to the expression parser should be required. Greg Clayton ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] swig generation
Hi all,
I'd like to do a few things with our swig generation and handling:
* Create a maintainer-mode style setup where the swig Python bindings are
generated and checked into the repo (I'll call it the static python
binding).
This will be used by default, removing the need for most people and all
builders/bots from having swig on their system just for lldb. In the event
that Windows needs a different version (e.g. for, say, Python 3.5 support
that is incompatible with the swig-1.3.40-generated bindings), we can
support multiple source bindings, or we can post process the swig-1.3.x
generated bindings.
We'll keep them by swig-{swig-major}-{swig-minor}. Internally over at
Apple, we will stick with the swig-1.x bindings. I don't think we will
care about the dot release (1.3.40 vs. 1.3.39, for example). We'll just
make sure to use the latest for a {swig-major}.{swig-minor}. As always, SB
API changes generated by swig need to remain swig-1.3 compatible (i.e.
swig-1.3 must be capable of generating usable Python wrappers).
Ideally we don't need more than one set of bindings so we can avoid needing
to generate multiple ones when we do it.
* Add an explicit Python binding generation step.
This would only be used by those who are touching the bindings (adding SB
API or adjusting the documentation of existing SB API). In the event that
we need two bindings, we may just need a handshake that says "okay, we'll
take care of the swig 1.3 bindings, and {somebody who needs the other
binding} generates it for the other." As SBAPI is additive only, this
should generally be fine as the worst case I can think of that would happen
would be failure to see new SBAPI in Python for a very brief time. Since
maintainers will be writing Python tests to check their new SBAPIs, failure
to do the explicit generation step will be immediately obvious as a test
failure. (The challenge here will likely be the swig 1.3.x requirement).
If generating and testing new binding content with the right swig (i.e.
swig 1.3.x) becomes a real issue, we may be able to support a "please use
my local swig, whatever it is, but don't check in the static binding), with
a handshake that says "somebody with swig 1.3, please generate the modified
binding and check in). We'll see if this becomes an issue. I don't see
this as insurmountable.
* Clean up the swig generation scripts
These look to have been implemented as direct ports of the older OS X style
bash scripts. This Python script is very much the essence of using the
paradigms of one language in another, and being the worse for it. It
implements features that are already present in the standard Python lib,
and is more verbose than it needs to be.
Also, it is likely the script needs to be broken out into a few parts. The
scripts don't just generate the python binding using swig, they also setup
(for OS X) some packaging and other bits. Right now none of that is
clearly broken out. When we move to an explicit binding generation mode,
this does need to be broken out better.
* Get OS X Xcode build using the same bindings machinery as others.
I tried this a while back (having Xcode adopt the Python-based swig wrapper
handling code), but gave up after hitting a few bugs where the translated
behavior was incorrect for Xcode. I will move over to adopting this on
Xcode if possible while going through these changes.
The primary goal here is to remove the requirement of having swig on the
system (e.g. for builders and most developers), shifting that burden a bit
more to those who actually modify the Python binding.
As a potential added benefit, this opens us up to easier modification of
that binding generation step, which may prove to be useful later.
Let me know if you have any feedback before I dive into this.
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] swig generation
On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi all,
>
> I'd like to do a few things with our swig generation and handling:
>
> * Create a maintainer-mode style setup where the swig Python bindings are
> generated and checked into the repo (I'll call it the static python
> binding).
>
> This will be used by default, removing the need for most people and all
> builders/bots from having swig on their system just for lldb. In the event
> that Windows needs a different version (e.g. for, say, Python 3.5 support
> that is incompatible with the swig-1.3.40-generated bindings), we can
> support multiple source bindings, or we can post process the swig-1.3.x
> generated bindings. We'll keep them by swig-{swig-major}-{swig-minor}.
> Internally over at Apple, we will stick with the swig-1.x bindings. I
> don't think we will care about the dot release (1.3.40 vs. 1.3.39, for
> example). We'll just make sure to use the latest for a
> {swig-major}.{swig-minor}. As always, SB API changes generated by swig
> need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of
> generating usable Python wrappers).
>
I know you said you plan to stay on 1.x, but in this world of having SWIG
bindings checked in, does that open the door to potentially moving beyond
SWIG 1.x for the upstream? I feel like the SWIG 1.x requirement holds the
upstream back, because there are a lot of hacks to workaround bugs and
limitations in SWIG, and it only understands the absolute most basic C /
C++ language constructs. So we end up being limited in how we can design
SB APIs, all for reasons that having nothing to do with the upstream
project requirements, which is kind of a bummer. It seems like there could
be a path here for the upstream to move forward, and anyone who is forced
to stay on an earlier version of SWIG could maintain whatever changes are
necessary to make this possible in a local repository.
>
> * Clean up the swig generation scripts
>
> These look to have been implemented as direct ports of the older OS X
> style bash scripts. This Python script is very much the essence of using
> the paradigms of one language in another, and being the worse for it. It
> implements features that are already present in the standard Python lib,
> and is more verbose than it needs to be.
>
Ugh, +1000. Every time I have to crack these files open my head explodes.
More than happy to help with whatever porting is necessary.
>
> Also, it is likely the script needs to be broken out into a few parts.
> The scripts don't just generate the python binding using swig, they also
> setup (for OS X) some packaging and other bits. Right now none of that is
> clearly broken out. When we move to an explicit binding generation mode,
> this does need to be broken out better.
>
>
> * Get OS X Xcode build using the same bindings machinery as others.
>
Yay.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] swig generation
On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner wrote:
> On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I'd like to do a few things with our swig generation and handling:
>>
>> * Create a maintainer-mode style setup where the swig Python bindings are
>> generated and checked into the repo (I'll call it the static python
>> binding).
>>
>> This will be used by default, removing the need for most people and all
>> builders/bots from having swig on their system just for lldb. In the event
>> that Windows needs a different version (e.g. for, say, Python 3.5 support
>> that is incompatible with the swig-1.3.40-generated bindings), we can
>> support multiple source bindings, or we can post process the swig-1.3.x
>> generated bindings. We'll keep them by swig-{swig-major}-{swig-minor}.
>> Internally over at Apple, we will stick with the swig-1.x bindings. I
>> don't think we will care about the dot release (1.3.40 vs. 1.3.39, for
>> example). We'll just make sure to use the latest for a
>> {swig-major}.{swig-minor}. As always, SB API changes generated by swig
>> need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of
>> generating usable Python wrappers).
>>
> I know you said you plan to stay on 1.x, but in this world of having SWIG
> bindings checked in, does that open the door to potentially moving beyond
> SWIG 1.x for the upstream? I feel like the SWIG 1.x requirement holds the
> upstream back, because there are a lot of hacks to workaround bugs and
> limitations in SWIG, and it only understands the absolute most basic C /
> C++ language constructs. So we end up being limited in how we can design
> SB APIs, all for reasons that having nothing to do with the upstream
> project requirements, which is kind of a bummer. It seems like there could
> be a path here for the upstream to move forward, and anyone who is forced
> to stay on an earlier version of SWIG could maintain whatever changes are
> necessary to make this possible in a local repository.
>
>
I may leave Greg to discuss that aspect (w/r/t using newer features). The
SB API itself is intended to be a very bare-bones linkage environment that
does not break linkage requirements in ways that typical C++ binary
libraries do (i.e. it does not use virtuals and follows a number of rules
about data members so that it remains binary compatible across
compiler/linker changes).
>
>
>>
>> * Clean up the swig generation scripts
>>
>> These look to have been implemented as direct ports of the older OS X
>> style bash scripts. This Python script is very much the essence of using
>> the paradigms of one language in another, and being the worse for it. It
>> implements features that are already present in the standard Python lib,
>> and is more verbose than it needs to be.
>>
> Ugh, +1000. Every time I have to crack these files open my head
> explodes. More than happy to help with whatever porting is necessary.
>
>
Haha that's exactly how I feel :-)
>
>> Also, it is likely the script needs to be broken out into a few parts.
>> The scripts don't just generate the python binding using swig, they also
>> setup (for OS X) some packaging and other bits. Right now none of that is
>> clearly broken out. When we move to an explicit binding generation mode,
>> this does need to be broken out better.
>>
>>
>> * Get OS X Xcode build using the same bindings machinery as others.
>>
> Yay.
>
>
--
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] swig generation
On Fri, Nov 13, 2015 at 10:24 AM, Todd Fiala wrote:
>
>
> On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner
> wrote:
>
>> On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to do a few things with our swig generation and handling:
>>>
>>> * Create a maintainer-mode style setup where the swig Python bindings
>>> are generated and checked into the repo (I'll call it the static python
>>> binding).
>>>
>>> This will be used by default, removing the need for most people and all
>>> builders/bots from having swig on their system just for lldb. In the event
>>> that Windows needs a different version (e.g. for, say, Python 3.5 support
>>> that is incompatible with the swig-1.3.40-generated bindings), we can
>>> support multiple source bindings, or we can post process the swig-1.3.x
>>> generated bindings. We'll keep them by swig-{swig-major}-{swig-minor}.
>>> Internally over at Apple, we will stick with the swig-1.x bindings. I
>>> don't think we will care about the dot release (1.3.40 vs. 1.3.39, for
>>> example). We'll just make sure to use the latest for a
>>> {swig-major}.{swig-minor}. As always, SB API changes generated by swig
>>> need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of
>>> generating usable Python wrappers).
>>>
>> I know you said you plan to stay on 1.x, but in this world of having SWIG
>> bindings checked in, does that open the door to potentially moving beyond
>> SWIG 1.x for the upstream? I feel like the SWIG 1.x requirement holds the
>> upstream back, because there are a lot of hacks to workaround bugs and
>> limitations in SWIG,
>>
>
We do have the ability to post-process this any way we want after the swig
generation. I see no reason why we couldn't get move advanced with what we
post-process, especially since that can be limited to the
maintainer-mode-style "update the static checked-in product after
generating the bindings" step).
> and it only understands the absolute most basic C / C++ language
>> constructs. So we end up being limited in how we can design SB APIs, all
>> for reasons that having nothing to do with the upstream project
>> requirements, which is kind of a bummer. It seems like there could be a
>> path here for the upstream to move forward, and anyone who is forced to
>> stay on an earlier version of SWIG could maintain whatever changes are
>> necessary to make this possible in a local repository.
>>
>>
> I may leave Greg to discuss that aspect (w/r/t using newer features). The
> SB API itself is intended to be a very bare-bones linkage environment that
> does not break linkage requirements in ways that typical C++ binary
> libraries do (i.e. it does not use virtuals and follows a number of rules
> about data members so that it remains binary compatible across
> compiler/linker changes).
>
>
>>
>>
>>>
>>> * Clean up the swig generation scripts
>>>
>>> These look to have been implemented as direct ports of the older OS X
>>> style bash scripts. This Python script is very much the essence of using
>>> the paradigms of one language in another, and being the worse for it. It
>>> implements features that are already present in the standard Python lib,
>>> and is more verbose than it needs to be.
>>>
>> Ugh, +1000. Every time I have to crack these files open my head
>> explodes. More than happy to help with whatever porting is necessary.
>>
>>
>
> Haha that's exactly how I feel :-)
>
>
>>
>>> Also, it is likely the script needs to be broken out into a few parts.
>>> The scripts don't just generate the python binding using swig, they also
>>> setup (for OS X) some packaging and other bits. Right now none of that is
>>> clearly broken out. When we move to an explicit binding generation mode,
>>> this does need to be broken out better.
>>>
>>>
>>> * Get OS X Xcode build using the same bindings machinery as others.
>>>
>> Yay.
>>
>>
>
>
> --
> -Todd
>
--
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] swig generation
I will probably tackle this as two phases:
Phase 1:
* Python script modernization (the python swig wrapper generation)
* Move Xcode onto it.
Phase 2:
* The maintainer-mode, static Python binding generation changes for cmake
and Xcode.
I want to make sure we have proven, still-functional Python from the new
Python script before we move forward. I will also probably turn on the
Green Dragon OS X public builder's test running at this stage so we can
also see that.
And I want to work out any issues with the current script logic and what OS
X was doing before shifting any of this around.
On Fri, Nov 13, 2015 at 9:02 AM, Todd Fiala wrote:
> Hi all,
>
> I'd like to do a few things with our swig generation and handling:
>
> * Create a maintainer-mode style setup where the swig Python bindings are
> generated and checked into the repo (I'll call it the static python
> binding).
>
> This will be used by default, removing the need for most people and all
> builders/bots from having swig on their system just for lldb. In the event
> that Windows needs a different version (e.g. for, say, Python 3.5 support
> that is incompatible with the swig-1.3.40-generated bindings), we can
> support multiple source bindings, or we can post process the swig-1.3.x
> generated bindings.
>
> We'll keep them by swig-{swig-major}-{swig-minor}. Internally over at
> Apple, we will stick with the swig-1.x bindings. I don't think we will
> care about the dot release (1.3.40 vs. 1.3.39, for example). We'll just
> make sure to use the latest for a {swig-major}.{swig-minor}. As always, SB
> API changes generated by swig need to remain swig-1.3 compatible (i.e.
> swig-1.3 must be capable of generating usable Python wrappers).
>
> Ideally we don't need more than one set of bindings so we can avoid
> needing to generate multiple ones when we do it.
>
>
> * Add an explicit Python binding generation step.
>
> This would only be used by those who are touching the bindings (adding SB
> API or adjusting the documentation of existing SB API). In the event that
> we need two bindings, we may just need a handshake that says "okay, we'll
> take care of the swig 1.3 bindings, and {somebody who needs the other
> binding} generates it for the other." As SBAPI is additive only, this
> should generally be fine as the worst case I can think of that would happen
> would be failure to see new SBAPI in Python for a very brief time. Since
> maintainers will be writing Python tests to check their new SBAPIs, failure
> to do the explicit generation step will be immediately obvious as a test
> failure. (The challenge here will likely be the swig 1.3.x requirement).
>
> If generating and testing new binding content with the right swig (i.e.
> swig 1.3.x) becomes a real issue, we may be able to support a "please use
> my local swig, whatever it is, but don't check in the static binding), with
> a handshake that says "somebody with swig 1.3, please generate the modified
> binding and check in). We'll see if this becomes an issue. I don't see
> this as insurmountable.
>
>
> * Clean up the swig generation scripts
>
> These look to have been implemented as direct ports of the older OS X
> style bash scripts. This Python script is very much the essence of using
> the paradigms of one language in another, and being the worse for it. It
> implements features that are already present in the standard Python lib,
> and is more verbose than it needs to be.
>
> Also, it is likely the script needs to be broken out into a few parts.
> The scripts don't just generate the python binding using swig, they also
> setup (for OS X) some packaging and other bits. Right now none of that is
> clearly broken out. When we move to an explicit binding generation mode,
> this does need to be broken out better.
>
>
> * Get OS X Xcode build using the same bindings machinery as others.
>
> I tried this a while back (having Xcode adopt the Python-based swig
> wrapper handling code), but gave up after hitting a few bugs where the
> translated behavior was incorrect for Xcode. I will move over to adopting
> this on Xcode if possible while going through these changes.
>
> The primary goal here is to remove the requirement of having swig on the
> system (e.g. for builders and most developers), shifting that burden a bit
> more to those who actually modify the Python binding.
>
> As a potential added benefit, this opens us up to easier modification of
> that binding generation step, which may prove to be useful later.
>
> Let me know if you have any feedback before I dive into this.
>
> -Todd
>
--
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Two CLs requiring changes to the Xcode project
Looks like everything was covered. Thanks, all! On Thu, Nov 12, 2015 at 7:07 PM, Zachary Turner wrote: > Thanks! I actually forgot, there's one more file for the lldb-gtest > target. It's PythonExceptionStateTests.cpp. > > Thanks for the help > > On Thu, Nov 12, 2015 at 6:05 PM Jason Molenda wrote: > >> Ah, my bad. It's the lldb-gtest target. >> >> >> > On Nov 12, 2015, at 5:49 PM, Zachary Turner wrote: >> > >> > Hmm, can you ask Todd about it? He said he added one, but I'm not sure >> how it works. >> > >> > On Thu, Nov 12, 2015 at 5:46 PM Jason Molenda >> wrote: >> > Done in r252998. >> > >> > I didn't see anything in the xcode project file about a gtest target. >> > >> > J >> > >> > > On Nov 12, 2015, at 5:39 PM, Zachary Turner via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> > > >> > > Hi all, >> > > >> > > I submitted r252993 and 252994. These changes will require a >> corresponding change in the Xcode workspace. Would anyone mind making >> those changes for me? It should be pretty simple, just need to add a .cpp >> and .h file to the gtest target for ScriptInterpreterPythonTests, and add >> PythonExceptionState.cpp to Plugins/ScriptInterpreter/Python >> > > ___ >> > > lldb-dev mailing list >> > > lldb-dev@lists.llvm.org >> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > >> >> -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] swig generation
On Fri, Nov 13, 2015 at 10:24 AM Todd Fiala wrote:
> On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner
> wrote:
>
>> On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to do a few things with our swig generation and handling:
>>>
>>> * Create a maintainer-mode style setup where the swig Python bindings
>>> are generated and checked into the repo (I'll call it the static python
>>> binding).
>>>
>>> This will be used by default, removing the need for most people and all
>>> builders/bots from having swig on their system just for lldb. In the event
>>> that Windows needs a different version (e.g. for, say, Python 3.5 support
>>> that is incompatible with the swig-1.3.40-generated bindings), we can
>>> support multiple source bindings, or we can post process the swig-1.3.x
>>> generated bindings. We'll keep them by swig-{swig-major}-{swig-minor}.
>>> Internally over at Apple, we will stick with the swig-1.x bindings. I
>>> don't think we will care about the dot release (1.3.40 vs. 1.3.39, for
>>> example). We'll just make sure to use the latest for a
>>> {swig-major}.{swig-minor}. As always, SB API changes generated by swig
>>> need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of
>>> generating usable Python wrappers).
>>>
>> I know you said you plan to stay on 1.x, but in this world of having SWIG
>> bindings checked in, does that open the door to potentially moving beyond
>> SWIG 1.x for the upstream? I feel like the SWIG 1.x requirement holds the
>> upstream back, because there are a lot of hacks to workaround bugs and
>> limitations in SWIG, and it only understands the absolute most basic C /
>> C++ language constructs. So we end up being limited in how we can design
>> SB APIs, all for reasons that having nothing to do with the upstream
>> project requirements, which is kind of a bummer. It seems like there could
>> be a path here for the upstream to move forward, and anyone who is forced
>> to stay on an earlier version of SWIG could maintain whatever changes are
>> necessary to make this possible in a local repository.
>>
>>
> I may leave Greg to discuss that aspect (w/r/t using newer features). The
> SB API itself is intended to be a very bare-bones linkage environment that
> does not break linkage requirements in ways that typical C++ binary
> libraries do (i.e. it does not use virtuals and follows a number of rules
> about data members so that it remains binary compatible across
> compiler/linker changes).
>
There's a couple of examples that come to mind. C++11 is completely out,
for example. In general this isn't a huge deal. Nobody's going to be
passing rvalue references through the SB API or anything. But even simple
things like enum classes are out. 1.x also doesn't support specifying the
underlying type of an enum, because it can't parse it. In other words,
SWIG won't accept this:
enum Foo : unsigned {
};
This is actually important in MSVC because its algorithm for choosing the
underlying type and size of the enum differs from other compilers. We've
got hundreds of warnings silenced in CMake because of this, and there's no
solution except upgrade SWIG.
We're also forced to use the archaic "const char* str, int len" syntax for
every single string, when we could be passing std strings or llvm
StringRefs.
No nested classes, namespace support doesn't work, and also missing out on
a ton of bugfixes and performance improvements of generated code. Many
languages like Go aren't supported in 1.x, etc. If I check the release
notes I could probably come up with more examples.
I don't mean to say that we have to do this with haste or anything, but I
think at some point there should probably be a path off of 1.x for the
upstream
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Is there a way to inspect signaled stack?
Hi, I am running on Ubuntu Linux. I am using a custom debugger built upon LLDB C++ API using version 3.7. The target program issues a lot of "legitimate" SIGSEGV signals that it handles itself. Its signal handler runs on a separate stack (it uses sigaltstack() and SA_ONSTACK). Now, sometimes a bug in the program causes SIGSEGV that the handler cannot deal with and it crashes. Now, when I load the core, I see stack frames for the signal handler stack, but what I really need are frames for the signaled stack. Of course, I have access to siginfo_t and ucontext_t, so I can try to use some unwind library, but that approach is far from ideal - the LLDB already has the unwinder. So, what should I do to get the set of SBFrame's that I can query about local variables, etc.? I mean, something like .cxr command in Windbg would be really handy... Thanks,Eugene ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to disassemble a section (python api)?
Currently you can't disassemble a section, nor would you probably want to since
there are padding bytes in between functions.
The easiest way is to get all SBSymbol objects and ask each one for the
instructions if they are code:
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> module = lldb.target.module['a.out']
>>> num_symbols = module.GetNumSymbols()
>>> for i in range(num_symbols):
... symbol = module.GetSymbolAtIndex(i)
... if symbol.GetType() == lldb.eSymbolTypeCode:
... print symbol
... instructions = symbol.GetInstructions(lldb.target)
... for inst in instructions:
... print inst
...
id = {0x0004}, range = [0x00010f00-0x00010f20),
name="foo(float)", mangled="_Z3foof"
a.out[0x10f00]: pushq %rbp
a.out[0x10f01]: movq %rsp, %rbp
a.out[0x10f04]: movss %xmm0, -0x4(%rbp)
a.out[0x10f09]: cvttss2si -0x4(%rbp), %eax
a.out[0x10f0e]: shll $0x1, %eax
a.out[0x10f11]: popq %rbp
a.out[0x10f12]: retq
a.out[0x10f13]: nopw %cs:(%rax,%rax)
id = {0x0008}, range = [0x00010f20-0x00010f40),
name="foo(int)", mangled="_Z3fooi"
a.out[0x10f20]: pushq %rbp
a.out[0x10f21]: movq %rsp, %rbp
a.out[0x10f24]: movl %edi, -0x4(%rbp)
a.out[0x10f27]: movl -0x4(%rbp), %edi
a.out[0x10f2a]: shll $0x2, %edi
a.out[0x10f2d]: movl %edi, %eax
a.out[0x10f2f]: popq %rbp
a.out[0x10f30]: retq
a.out[0x10f31]: nopw %cs:(%rax,%rax)
id = {0x000c}, range = [0x00010f40-0x00010f90), name="main"
a.out[0x10f40]: pushq %rbp
a.out[0x10f41]: movq %rsp, %rbp
a.out[0x10f44]: subq $0x30, %rsp
a.out[0x10f48]: movss 0x40(%rip), %xmm0
a.out[0x10f50]: movl $0x0, -0x4(%rbp)
a.out[0x10f57]: movl %edi, -0x8(%rbp)
a.out[0x10f5a]: movq %rsi, -0x10(%rbp)
a.out[0x10f5e]: movq %rdx, -0x18(%rbp)
a.out[0x10f62]: movss %xmm0, -0x1c(%rbp)
a.out[0x10f67]: movl $0x4d2, -0x20(%rbp)
a.out[0x10f6e]: movss -0x1c(%rbp), %xmm0
a.out[0x10f73]: callq 0x10f00
a.out[0x10f78]: movl -0x20(%rbp), %edi
a.out[0x10f7b]: movl %eax, -0x24(%rbp)
a.out[0x10f7e]: callq 0x10f20
a.out[0x10f83]: movl -0x24(%rbp), %edi
a.out[0x10f86]: addl %eax, %edi
a.out[0x10f88]: movl %edi, %eax
a.out[0x10f8a]: addq $0x30, %rsp
a.out[0x10f8e]: popq %rbp
a.out[0x10f8f]: retq
>>>
If you want the symbols only from a specific section you can get the section
from the symbol's start address and compare that to a given name:
section_name = ".text"
for i in range(num_symbols):
symbol = module.GetSymbolAtIndex(i)
if symbol.GetType() == lldb.eSymbolTypeCode:
symbol_section = symbol.GetStartAddress().GetSection()
if symbol_section.GetName() == section_name:
print symbol
instructions = symbol.GetInstructions(lldb.target)
for inst in instructions:
print inst
> On Nov 12, 2015, at 2:13 PM, kwadwo amankwa via lldb-dev
> wrote:
>
> Hi
> I'm writing a small script and need to disassemble a whole section , what
> would be the correct way to go about it ?
>
> Cheers Que,
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to disassemble a section (python api)?
On 13/11/15 19:31, Greg Clayton wrote:
Currently you can't disassemble a section, nor would you probably want to since
there are padding bytes in between functions.
The easiest way is to get all SBSymbol objects and ask each one for the
instructions if they are code:
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
module = lldb.target.module['a.out']
num_symbols = module.GetNumSymbols()
for i in range(num_symbols):
... symbol = module.GetSymbolAtIndex(i)
... if symbol.GetType() == lldb.eSymbolTypeCode:
... print symbol
... instructions = symbol.GetInstructions(lldb.target)
... for inst in instructions:
... print inst
...
id = {0x0004}, range = [0x00010f00-0x00010f20), name="foo(float)",
mangled="_Z3foof"
a.out[0x10f00]: pushq %rbp
a.out[0x10f01]: movq %rsp, %rbp
a.out[0x10f04]: movss %xmm0, -0x4(%rbp)
a.out[0x10f09]: cvttss2si -0x4(%rbp), %eax
a.out[0x10f0e]: shll $0x1, %eax
a.out[0x10f11]: popq %rbp
a.out[0x10f12]: retq
a.out[0x10f13]: nopw %cs:(%rax,%rax)
id = {0x0008}, range = [0x00010f20-0x00010f40), name="foo(int)",
mangled="_Z3fooi"
a.out[0x10f20]: pushq %rbp
a.out[0x10f21]: movq %rsp, %rbp
a.out[0x10f24]: movl %edi, -0x4(%rbp)
a.out[0x10f27]: movl -0x4(%rbp), %edi
a.out[0x10f2a]: shll $0x2, %edi
a.out[0x10f2d]: movl %edi, %eax
a.out[0x10f2f]: popq %rbp
a.out[0x10f30]: retq
a.out[0x10f31]: nopw %cs:(%rax,%rax)
id = {0x000c}, range = [0x00010f40-0x00010f90), name="main"
a.out[0x10f40]: pushq %rbp
a.out[0x10f41]: movq %rsp, %rbp
a.out[0x10f44]: subq $0x30, %rsp
a.out[0x10f48]: movss 0x40(%rip), %xmm0
a.out[0x10f50]: movl $0x0, -0x4(%rbp)
a.out[0x10f57]: movl %edi, -0x8(%rbp)
a.out[0x10f5a]: movq %rsi, -0x10(%rbp)
a.out[0x10f5e]: movq %rdx, -0x18(%rbp)
a.out[0x10f62]: movss %xmm0, -0x1c(%rbp)
a.out[0x10f67]: movl $0x4d2, -0x20(%rbp)
a.out[0x10f6e]: movss -0x1c(%rbp), %xmm0
a.out[0x10f73]: callq 0x10f00
a.out[0x10f78]: movl -0x20(%rbp), %edi
a.out[0x10f7b]: movl %eax, -0x24(%rbp)
a.out[0x10f7e]: callq 0x10f20
a.out[0x10f83]: movl -0x24(%rbp), %edi
a.out[0x10f86]: addl %eax, %edi
a.out[0x10f88]: movl %edi, %eax
a.out[0x10f8a]: addq $0x30, %rsp
a.out[0x10f8e]: popq %rbp
a.out[0x10f8f]: retq
If you want the symbols only from a specific section you can get the section
from the symbol's start address and compare that to a given name:
section_name = ".text"
for i in range(num_symbols):
symbol = module.GetSymbolAtIndex(i)
if symbol.GetType() == lldb.eSymbolTypeCode:
symbol_section = symbol.GetStartAddress().GetSection()
if symbol_section.GetName() == section_name:
print symbol
instructions = symbol.GetInstructions(lldb.target)
for inst in instructions:
print inst
On Nov 12, 2015, at 2:13 PM, kwadwo amankwa via lldb-dev
wrote:
Hi
I'm writing a small script and need to disassemble a whole section , what would
be the correct way to go about it ?
Cheers Que,
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to disassemble a section (python api)?
Nice one ,
Cheers mate
On 13/11/15 23:30, kwadwo amankwa wrote:
Nice one ,
Cheers mate
On 13/11/15 19:31, Greg Clayton wrote:
Currently you can't disassemble a section, nor would you probably
want to since there are padding bytes in between functions.
The easiest way is to get all SBSymbol objects and ask each one for
the instructions if they are code:
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or
Ctrl-D.
module = lldb.target.module['a.out']
num_symbols = module.GetNumSymbols()
for i in range(num_symbols):
... symbol = module.GetSymbolAtIndex(i)
... if symbol.GetType() == lldb.eSymbolTypeCode:
... print symbol
... instructions = symbol.GetInstructions(lldb.target)
... for inst in instructions:
... print inst
...
id = {0x0004}, range = [0x00010f00-0x00010f20),
name="foo(float)", mangled="_Z3foof"
a.out[0x10f00]: pushq %rbp
a.out[0x10f01]: movq %rsp, %rbp
a.out[0x10f04]: movss %xmm0, -0x4(%rbp)
a.out[0x10f09]: cvttss2si -0x4(%rbp), %eax
a.out[0x10f0e]: shll $0x1, %eax
a.out[0x10f11]: popq %rbp
a.out[0x10f12]: retq
a.out[0x10f13]: nopw %cs:(%rax,%rax)
id = {0x0008}, range = [0x00010f20-0x00010f40),
name="foo(int)", mangled="_Z3fooi"
a.out[0x10f20]: pushq %rbp
a.out[0x10f21]: movq %rsp, %rbp
a.out[0x10f24]: movl %edi, -0x4(%rbp)
a.out[0x10f27]: movl -0x4(%rbp), %edi
a.out[0x10f2a]: shll $0x2, %edi
a.out[0x10f2d]: movl %edi, %eax
a.out[0x10f2f]: popq %rbp
a.out[0x10f30]: retq
a.out[0x10f31]: nopw %cs:(%rax,%rax)
id = {0x000c}, range = [0x00010f40-0x00010f90),
name="main"
a.out[0x10f40]: pushq %rbp
a.out[0x10f41]: movq %rsp, %rbp
a.out[0x10f44]: subq $0x30, %rsp
a.out[0x10f48]: movss 0x40(%rip), %xmm0
a.out[0x10f50]: movl $0x0, -0x4(%rbp)
a.out[0x10f57]: movl %edi, -0x8(%rbp)
a.out[0x10f5a]: movq %rsi, -0x10(%rbp)
a.out[0x10f5e]: movq %rdx, -0x18(%rbp)
a.out[0x10f62]: movss %xmm0, -0x1c(%rbp)
a.out[0x10f67]: movl $0x4d2, -0x20(%rbp)
a.out[0x10f6e]: movss -0x1c(%rbp), %xmm0
a.out[0x10f73]: callq 0x10f00
a.out[0x10f78]: movl -0x20(%rbp), %edi
a.out[0x10f7b]: movl %eax, -0x24(%rbp)
a.out[0x10f7e]: callq 0x10f20
a.out[0x10f83]: movl -0x24(%rbp), %edi
a.out[0x10f86]: addl %eax, %edi
a.out[0x10f88]: movl %edi, %eax
a.out[0x10f8a]: addq $0x30, %rsp
a.out[0x10f8e]: popq %rbp
a.out[0x10f8f]: retq
If you want the symbols only from a specific section you can get the
section from the symbol's start address and compare that to a given
name:
section_name = ".text"
for i in range(num_symbols):
symbol = module.GetSymbolAtIndex(i)
if symbol.GetType() == lldb.eSymbolTypeCode:
symbol_section = symbol.GetStartAddress().GetSection()
if symbol_section.GetName() == section_name:
print symbol
instructions = symbol.GetInstructions(lldb.target)
for inst in instructions:
print inst
On Nov 12, 2015, at 2:13 PM, kwadwo amankwa via lldb-dev
wrote:
Hi
I'm writing a small script and need to disassemble a whole section ,
what would be the correct way to go about it ?
Cheers Que,
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
