[lldb-dev] [Bug 23560] lldb does not understand gcc-4.9 function prologues
https://llvm.org/bugs/show_bug.cgi?id=23560 abhiinnit...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from abhiinnit...@gmail.com --- This Bug is resolved by r253026. -- You are receiving this mail because: You are on the CC list for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Is it possible to set a python script handler for a signal stop in lldb?
I believe there is no such thing at the moment. It might be interesting to add one though, to enable "conditional" signal handling. E.g., when an application handles it's own SIGSEGVs, and you want to pass those quietly, but you want to stop for real problems (for some definition of "real"). pl On 16 November 2015 at 04:07, Jay Wang via lldb-dev wrote: > LLDB tutorial tells the way to set a python script handler for a breakpoint. > see http://lldb.llvm.org/scripting.html > > But is there a way to set one for a signal stop? > > > ___ > 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] Is there a way to inspect signaled stack?
Hi Eugene, the libc signal trampoline should have .eh_frame unwind info (I am assuming this is x86_64 btw), and last time I looked at it, it seemed that it should be able to handle sigaltstack(). However, I have never tested this, so it's quite possible there is still some bug hidden there. Could you file a bug with a small repro case and attach the output of (thread backtrace) with logging enabled (log enable lldb unwind). We'll try to look at it. thanks, pl On 13 November 2015 at 19:22, Eugene Birukov via lldb-dev wrote: > 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 > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback
Hi guys and thank you for the excellent community project!
Recently I've stumbled on a pesky, but trivial Invalid iterator dereference bug
in SymbolContext and TypeMap implementations at revisions
https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
and
https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
>From the code below it is obvious that TypeMap::ForEach calls the
>pre-increment operator on m_types iterator right after it has been invalidated
>by m_types.erase
SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list ) const
{
TypeMaptoList callbackM2L (type_map, type_list);
type_map.ForEach(callbackM2L);
return ;
}
void
TypeMap::ForEach (std::function const &callback)
{
for (auto pos = m_types.begin(), end = m_types.end(); pos != end; ++pos)
{
if (!callback(pos->second))
break;
}
}
bool
TypeMap::RemoveTypeWithUID (user_id_t uid)
{
iterator pos = m_types.find(uid);
if (pos != m_types.end())
{
m_types.erase(pos);
return true;
}
return false;
}
class TypeMaptoList
{
public:
TypeMaptoList(TypeMap &typem, TypeList &typel) :
type_map(typem),type_list(typel)
{
}
bool
operator() (const lldb::TypeSP& type)
{
if(type)
{
type_list.Insert(type);
type_map.RemoveTypeWithUID(type->GetID());
if (type_map.Empty())
return false;
}
return true;
}
private:
TypeMap &type_map;
TypeList &type_list;
};
Regards,
Mikhail Filimonov
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback
Thanks for the heads-up Mikhail.
Ravi,
this looks like your code. Could you take a look at this?
pl
On 16 November 2015 at 16:24, Mikhail Filimonov via lldb-dev
wrote:
> Hi guys and thank you for the excellent community project!
>
>
>
> Recently I’ve stumbled on a pesky, but trivial Invalid iterator dereference
> bug in SymbolContext and TypeMap implementations at revisions
>
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
>
> and
>
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
>
>
>
> From the code below it is obvious that TypeMap::ForEach calls the
> pre-increment operator on m_types iterator right after it has been
> invalidated by m_types.erase
>
>
>
> SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list ) const
>
> {
>
> TypeMaptoList callbackM2L (type_map, type_list);
>
> type_map.ForEach(callbackM2L);
>
> return ;
>
> }
>
>
>
> void
>
> TypeMap::ForEach (std::function const
> &callback)
>
> {
>
> for (auto pos = m_types.begin(), end = m_types.end(); pos != end; ++pos)
>
> {
>
> if (!callback(pos->second))
>
> break;
>
> }
>
> }
>
>
>
> bool
>
> TypeMap::RemoveTypeWithUID (user_id_t uid)
>
> {
>
> iterator pos = m_types.find(uid);
>
>
>
> if (pos != m_types.end())
>
> {
>
> m_types.erase(pos);
>
> return true;
>
> }
>
> return false;
>
> }
>
>
>
> class TypeMaptoList
>
> {
>
> public:
>
> TypeMaptoList(TypeMap &typem, TypeList &typel) :
>
> type_map(typem),type_list(typel)
>
> {
>
> }
>
>
>
> bool
>
> operator() (const lldb::TypeSP& type)
>
> {
>
> if(type)
>
> {
>
> type_list.Insert(type);
>
> type_map.RemoveTypeWithUID(type->GetID());
>
> if (type_map.Empty())
>
> return false;
>
> }
>
> return true;
>
> }
>
>
>
> private:
>
> TypeMap &type_map;
>
> TypeList &type_list;
>
> };
>
>
>
> Regards,
>
> Mikhail Filimonov
>
>
>
>
>
>
>
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential information. Any unauthorized review, use, disclosure
> or distribution is prohibited. If you are not the intended recipient,
> please contact the sender by reply email and destroy all copies of the
> original message.
>
>
> ___
> 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] Is there a way to inspect signaled stack?
You are right, it does work - sorry for false alarm. > From: lab...@google.com > Date: Mon, 16 Nov 2015 11:26:10 + > Subject: Re: [lldb-dev] Is there a way to inspect signaled stack? > To: eugen...@hotmail.com > CC: lldb-dev@lists.llvm.org > > Hi Eugene, > > the libc signal trampoline should have .eh_frame unwind info (I am > assuming this is x86_64 btw), and last time I looked at it, it seemed > that it should be able to handle sigaltstack(). However, I have never > tested this, so it's quite possible there is still some bug hidden > there. Could you file a bug with a small repro case and attach the > output of (thread backtrace) with logging enabled (log enable lldb > unwind). We'll try to look at it. > > thanks, > pl > > > On 13 November 2015 at 19:22, Eugene Birukov via lldb-dev > wrote: > > 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 > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Is it possible to set a python script handler for a signal stop in lldb?
lldb has "target stop-hook"s that you can use to add LLDB command-line commands to react to any sort of stop. The intent is to also allow Python stop hooks, then you could switch on the thread's stop reason and do signal specific stuff for a signal stop. But nobody has gotten around to adding Python stop hooks yet. Jim > On Nov 15, 2015, at 8:07 PM, Jay Wang via lldb-dev > wrote: > > LLDB tutorial tells the way to set a python script handler for a breakpoint. > see http://lldb.llvm.org/scripting.html > > But is there a way to set one for a signal stop? > > ___ > 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] swig generation
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.
>
I've begun this process. I've got Xcode build (and the Xcode build only)
wired up to scripts/prepare_bindings.py. This, and the Python-specific
binding preparation script, are considerably shorter than the older
implementation. It also addresses the bugs that prevented the former from
working with the Xcode build. The new scripts are pylint clean (with
stock configuration) except for a small handful of places that I intend to
revisit when I have a few cycles to really tidy things up. (Right now I'm
just going for the 90% wins).
Tomorrow I will fix up the tail end (the finalization) in a similar manner
and plug it into the Xcode build. I'll also try it locally on Linux and
work out any issues there.
I'll be tackling the static binding area (and will put up for review) only
after I know the cleaned up binding preparation scripts are working
properly everywhere. I just didn't want to tackle that until I really
understood what the scripts were already doing and it was in a state I felt
I could maintain.
>
> 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
Re: [lldb-dev] swig generation
On Mon, Nov 16, 2015 at 11:28 PM, Todd Fiala wrote:
>
>
> 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.
>>
>
> I've begun this process.
>
With r253317, that is.
> I've got Xcode build (and the Xcode build only) wired up to
> scripts/prepare_bindings.py. This, and the Python-specific binding
> preparation script, are considerably shorter than the older
> implementation. It also addresses the bugs that prevented the former from
> working with the Xcode build. The new scripts are pylint clean (with
> stock configuration) except for a small handful of places that I intend to
> revisit when I have a few cycles to really tidy things up. (Right now I'm
> just going for the 90% wins).
>
> Tomorrow I will fix up the tail end (the finalization) in a similar manner
> and plug it into the Xcode build. I'll also try it locally on Linux and
> work out any issues there.
>
> I'll be tackling the static binding area (and will put up for review) only
> after I know the cleaned up binding preparation scripts are working
> properly everywhere. I just didn't want to tackle that until I really
> understood what the scripts were already doing and it was in a state I felt
> I could maintain.
>
>
>> 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 Pytho
