Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

[Raphael “Teemperor” Isemann via lldb-dev]

I think this is great, thanks for working on this! My only concern is that I 
would prefer if we could limit the Lua tests to just the Lua->C++ calling 
machinery (e.g., that we handle Lua strings correctly and all that jazz) and 
not fragment our test suit. Otherwise Lua seems to require far less maintenance 
work than Python, so I am not worried about the technical debt this adds.

> On 9. Dec 2019, at 01:25, Jonas Devlieghere via lldb-dev 
>  wrote:
> 
> Hi everyone,
> 
> Earlier this year, when I was working on the Python script
> interpreter, I thought it would be interesting to see what it would
> take to support other scripting languages in LLDB. Lua, being designed
> to be embedded, quickly came to mind. The idea remained in the back of
> my head, but I never really got around to it, until now.
> 
> I was pleasantly surprised to see that it only took me a few hours to
> create a basic but working prototype. It supports running single
> commands as well as an interactive interpreter and has access to most
> of the SB API through bindings generated by SWIG. Of course it's far
> from complete.
> 
> Before I invest more time in this, I'm curious to hear what the
> community thinks about adding support for another scripting language
> to LLDB. Do we need both Lua and Python?
> 
> Here are some of the reasons off the top of my head as to why the
> answer might be
> "yes":
> 
> - The cost for having another scripting language is pretty small. The
> Lua script interpreter is very simple and SWIG can reuse the existing
> interfaces to generate the bindings.
> - LLDB is designed to support multiple script interpreters, but in
> reality we only have one. Actually exercising this property ensures
> that we don't unintentionally break that design assumptions.
> - The Python script interpreter is complex. It's hard to figure out
> what's really needed to support another language. The Lua script
> interpreter on the other hand is pretty straightforward. Common code
> can be shared by both.
> - Currently Python support is disabled for some targets, like Android
> and iOS. Lua could enable scripting for these environments where
> having all of Python is overkill or undesirable.
> 
> Reasons why the answer might be "no":
> 
> - Are our users going to use this?
> - Supporting Python is an ongoing pain. Do we really want to risk
> burdening ourselves with another scripting language?
> - The Python API is very well tested. We'd need to add test for the
> Lua bindings as well. It's unlikely this will match the coverage of
> Python, and probably even undesirable, because what's the point of
> testing the same thing twice. Also, do we want to risk fragmenting
> tests across two scripting languages?
> 
> There's probably a bunch more stuff that I didn't even think of. :-)
> 
> Personally I lean towards "yes" because I feel the benefits outweigh
> the costs, but of course that remains to be seen. Please let me know
> what you think!
> 
> If you're curious about what this looks like, you can find the patches
> on my fork on GitHub:
> https://github.com/JDevlieghere/llvm-project/tree/lua
> 
> Cheers,
> Jonas
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Stackoverflow crash when evaluating an invalid expression

[Raphael “Teemperor” Isemann via lldb-dev]

I don’t think we ever received a reproducer for this that would allow us to 
investigate this (or write a fix).

- Raphael

> On 8. Dec 2019, at 23:02, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> Looks like I am hitting the same issue.  Was there a fix checked in for this?
> 
> On Thu, Mar 7, 2019 at 3:05 PM Raphael Isemann via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> You can also dump() the AST to a file on disk if that is easier to
> capture than stderr. See the overload of `dump()` that takes a stream:
> https://clang.llvm.org/doxygen/ASTDumper_8cpp_source.html#l00225 
> 
> 
> - Raphael
> 
> Am Do., 7. März 2019 um 19:20 Uhr schrieb Ben Ruthig  >:
> >
> > Hey Raphael,
> >
> > Yes, you did advise me to drop a D->dumpColor() call in to 
> > getASTRecordLayout().  For frustrating reasons I still haven't been able to 
> > capture those logs but when I do I will report back.
> >
> > Thanks so much for your help and quick response!
> >
> > Ben
> >
> > On Thu, Mar 7, 2019 at 12:56 PM Raphael Isemann  > > wrote:
> >>
> >> Hi Ben,
> >>
> >> I think I already answered this last week:
> >> http://lists.llvm.org/pipermail/lldb-dev/2019-February/014789.html 
> >> 
> >>
> >> I don't think you'll get an answer here without posting the
> >> problematic source or giving any more information as I described in my
> >> mail.
> >>
> >> Cheers,
> >> - Raphael
> >>
> >> Am Do., 7. März 2019 um 18:13 Uhr schrieb Ben Ruthig via lldb-dev
> >> mailto:lldb-dev@lists.llvm.org>>:
> >> >
> >> > Hello all,
> >> >
> >> > I am currently investigating an issue where LLDB is crashing due to a 
> >> > stack overflow when attempting to evaluate an expression.  I have seen 
> >> > the same issue in 6.0.1 and have reproduced it in 7.0.1.  Any help to 
> >> > diagnose and fix would be greatly appreciated as I am trying to meet a 
> >> > release deadline early next week!
> >> >
> >> > The facts:
> >> > - The expression being evaluated is not a valid expression in the C++ 
> >> > domain. For example the expression is a datatype like 'Foobar'.  (For 
> >> > reasons unexplained I am constrained to supporting this use case.)
> >> > - The crash occurs when using the C++ LLDB API but not when trying to 
> >> > evaluate the expression via the LLDB shell or the LLDB Python script 
> >> > shell.  However, when doing 'expr Foobar' there is no output and the 
> >> > operation is completely silent.  It is similar when trying to do 
> >> > 'lldb.frame.EvaluateExpression("Foobar")' in the Python shell as well.  
> >> > I would expect to get some error output or an SbValue in an error state 
> >> > but no such luck.
> >> > - I was able to capture a stack trace (attached) and it seems to be a 
> >> > recursive loop bottoming out.  For brevity two 'loops' of stacktrace are 
> >> > included here:
> >> >
> >> > 3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> >> > clang::RecordDecl * D) Line 2965C++
> >> > 3388.  liblldb.dll!`anonymous 
> >> > namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216
> >> > C++
> >> > 3389.  liblldb.dll!`anonymous 
> >> > namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext 
> >> > & Context, const clang::CXXRecordDecl * Class) Line 172C++
> >> > 3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> >> > clang::RecordDecl * D) Line 2965C++
> >> > 3391.  liblldb.dll!`anonymous 
> >> > namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216
> >> > C++
> >> > 3392.  liblldb.dll!`anonymous 
> >> > namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext 
> >> > & Context, const clang::CXXRecordDecl * Class) Line 172C++
> >> > 3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> >> > clang::RecordDecl * D) Line 2965C++
> >> >
> >> > Help please :S
> >> >
> >> > Thanks,
> >> > Ben
> >> >
> >> >
> >> > ___
> >> > lldb-dev mailing list
> >> > lldb-dev@lists.llvm.org 
> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> >> > 
> >
> >
> >
> > --
> > "Sometimes I've believed as many as six impossible things before breakfast" 
> > - Alice in Wonderland
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.l

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

[Pavel Labath via lldb-dev]

I think this would be a very interesting project, and would allow us to
flesh out the details of the script interpreter interface.

A lot of the complexity in our python code comes from the fact that
python can be (a) embedded into lldb and (b) lldb can be embedded into
python. It's been a while since I worked with lua, but from what I
remember, lua was designed to make (a) easy., and I don't think (b) was
ever a major goal (though it can always be done ways, of course)..

Were you intending to implement both of these directions or just one of
them ((a), I guess)?

The reason I am asking this is because doing only (a) will definitely
make lua support simpler than python, but it will also mean it won't be
a "python-lite".

Both of these options are fine -- I just want to understand where you're
going with this. It also has some impact on the testing strategy, as our
existing python tests are largely using mode (b).

Another question I'm interested in is how deeply will this
multi-interpreter thing go? Will it be a build time option, will it be
selectable at runtime, but we'll have only one script interpreter per
SBDebugger, or will we be able to freely mix'n'match scripting languages?

I think the last option would be best because of data formatters
(otherwise one would have a problem is some of his data formatters are
written in python and others in lua), but it would also create a lot
more of new api surface, as one would have to worry about consistency of
the lua and python views of lldb, etc.

On 09/12/2019 01:25, Jonas Devlieghere via lldb-dev wrote:
> Hi everyone,
> 
> Earlier this year, when I was working on the Python script
> interpreter, I thought it would be interesting to see what it would
> take to support other scripting languages in LLDB. Lua, being designed
> to be embedded, quickly came to mind. The idea remained in the back of
> my head, but I never really got around to it, until now.
> 
> I was pleasantly surprised to see that it only took me a few hours to
> create a basic but working prototype. It supports running single
> commands as well as an interactive interpreter and has access to most
> of the SB API through bindings generated by SWIG. Of course it's far
> from complete.
> 
> Before I invest more time in this, I'm curious to hear what the
> community thinks about adding support for another scripting language
> to LLDB. Do we need both Lua and Python?
> 
> Here are some of the reasons off the top of my head as to why the
> answer might be
> "yes":
> 
>  - The cost for having another scripting language is pretty small. The
> Lua script interpreter is very simple and SWIG can reuse the existing
> interfaces to generate the bindings.
>  - LLDB is designed to support multiple script interpreters, but in
> reality we only have one. Actually exercising this property ensures
> that we don't unintentionally break that design assumptions.
>  - The Python script interpreter is complex. It's hard to figure out
> what's really needed to support another language. The Lua script
> interpreter on the other hand is pretty straightforward. Common code
> can be shared by both.
>  - Currently Python support is disabled for some targets, like Android
> and iOS. Lua could enable scripting for these environments where
> having all of Python is overkill or undesirable.
> 
> Reasons why the answer might be "no":
> 
>  - Are our users going to use this?
>  - Supporting Python is an ongoing pain. Do we really want to risk
> burdening ourselves with another scripting language?
>  - The Python API is very well tested. We'd need to add test for the
> Lua bindings as well. It's unlikely this will match the coverage of
> Python, and probably even undesirable, because what's the point of
> testing the same thing twice. Also, do we want to risk fragmenting
> tests across two scripting languages?
> 
> There's probably a bunch more stuff that I didn't even think of. :-)
> 
> Personally I lean towards "yes" because I feel the benefits outweigh
> the costs, but of course that remains to be seen. Please let me know
> what you think!
> 
> If you're curious about what this looks like, you can find the patches
> on my fork on GitHub:
> https://github.com/JDevlieghere/llvm-project/tree/lua
> 
> Cheers,
> Jonas
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

On 09/12/2019 09:33, Raphael “Teemperor” Isemann via lldb-dev wrote:
> I think this is great, thanks for working on this! My only concern
> is that I would prefer if we could limit the Lua tests to just the
> Lua->C++ calling machinery (e.g., that we handle Lua strings
> correctly and all that jazz) and not fragment our test suit.
> Otherwise Lua seems to require far less maintenance work than
> Python, so I am not worried about the technical debt this adds.
I agree -- I think our position should be (at least until lua support is
very mature) is that the p

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

[Kamil Rytarowski via lldb-dev]

Python is in general a no-go for a BSD basesystem (micropython can be an
exception.. but Python is so large today that we can reevaluate this
statement at some point). This is why we need to either disable certain
features in LLDB or split LLDB between everything without Python in the
base and the rest (like data formatters) through 3rd party packaging system.

Once we will finish our goals for LLDB/NetBSD we will work on this
separation in order to include LLDB in the basesystem.

Lua is a part of the NetBSD and FreeBSD basesystem so all the scripting
issues can be gone. I cannot speak for Darwin or Windows basesystem, but
I can imagine that Lua is a smaller issue than Python.

Personally, I am interested in another [today] niche scripting language
(Tcl), but adding Lua support should make LLDB easier for scripting in
general. Switching Lua bindings to other language is simple, so this is
another benefit in my eyes, especially since Python bindings are machine
generated today.

On 09.12.2019 10:57, Pavel Labath via lldb-dev wrote:
> I think this would be a very interesting project, and would allow us to
> flesh out the details of the script interpreter interface.
> 
> A lot of the complexity in our python code comes from the fact that
> python can be (a) embedded into lldb and (b) lldb can be embedded into
> python. It's been a while since I worked with lua, but from what I
> remember, lua was designed to make (a) easy., and I don't think (b) was
> ever a major goal (though it can always be done ways, of course)..
> 
> Were you intending to implement both of these directions or just one of
> them ((a), I guess)?
> 
> The reason I am asking this is because doing only (a) will definitely
> make lua support simpler than python, but it will also mean it won't be
> a "python-lite".
> 
> Both of these options are fine -- I just want to understand where you're
> going with this. It also has some impact on the testing strategy, as our
> existing python tests are largely using mode (b).
> 
> Another question I'm interested in is how deeply will this
> multi-interpreter thing go? Will it be a build time option, will it be
> selectable at runtime, but we'll have only one script interpreter per
> SBDebugger, or will we be able to freely mix'n'match scripting languages?
> 
> I think the last option would be best because of data formatters
> (otherwise one would have a problem is some of his data formatters are
> written in python and others in lua), but it would also create a lot
> more of new api surface, as one would have to worry about consistency of
> the lua and python views of lldb, etc.
> 
> On 09/12/2019 01:25, Jonas Devlieghere via lldb-dev wrote:
>> Hi everyone,
>>
>> Earlier this year, when I was working on the Python script
>> interpreter, I thought it would be interesting to see what it would
>> take to support other scripting languages in LLDB. Lua, being designed
>> to be embedded, quickly came to mind. The idea remained in the back of
>> my head, but I never really got around to it, until now.
>>
>> I was pleasantly surprised to see that it only took me a few hours to
>> create a basic but working prototype. It supports running single
>> commands as well as an interactive interpreter and has access to most
>> of the SB API through bindings generated by SWIG. Of course it's far
>> from complete.
>>
>> Before I invest more time in this, I'm curious to hear what the
>> community thinks about adding support for another scripting language
>> to LLDB. Do we need both Lua and Python?
>>
>> Here are some of the reasons off the top of my head as to why the
>> answer might be
>> "yes":
>>
>>  - The cost for having another scripting language is pretty small. The
>> Lua script interpreter is very simple and SWIG can reuse the existing
>> interfaces to generate the bindings.
>>  - LLDB is designed to support multiple script interpreters, but in
>> reality we only have one. Actually exercising this property ensures
>> that we don't unintentionally break that design assumptions.
>>  - The Python script interpreter is complex. It's hard to figure out
>> what's really needed to support another language. The Lua script
>> interpreter on the other hand is pretty straightforward. Common code
>> can be shared by both.
>>  - Currently Python support is disabled for some targets, like Android
>> and iOS. Lua could enable scripting for these environments where
>> having all of Python is overkill or undesirable.
>>
>> Reasons why the answer might be "no":
>>
>>  - Are our users going to use this?
>>  - Supporting Python is an ongoing pain. Do we really want to risk
>> burdening ourselves with another scripting language?
>>  - The Python API is very well tested. We'd need to add test for the
>> Lua bindings as well. It's unlikely this will match the coverage of
>> Python, and probably even undesirable, because what's the point of
>> testing the same thing twice. Also, do we want to risk fragmenting
>> tests across two scripting

Re: [lldb-dev] [llvm-dev] LLVM 9.0.1-rc2 has been tagged

[Hans Wennborg via lldb-dev]

On Sat, Dec 7, 2019 at 4:03 AM Tom Stellard via llvm-dev
 wrote:
>
> Hi,
>
> I've tagged LLVM 9.0.1-rc2.  Testers can begin testing and uploading binaries.
> If all goes well, this will be the last -rc.

Windows looks good.

$ sha256sum LLVM-9.0.1-rc2*.exe
131aa6b03a0c090ee9a5a9cd5e31fb27241e344c26380c83adb2f53b2e929f5a
LLVM-9.0.1-rc2-win32.exe
4ba66e7ea09d433dc6f41ebdb26510427ddeb3377224498fbdb839472d7505ce
LLVM-9.0.1-rc2-win64.exe

It was built with the attached batch file.

Thanks,
Hans


build_llvm_901-rc2._bat_
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 27795] TestWatchLocation.py fails with a unicode decode error

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=27795

Omair Javaid  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #1 from Omair Javaid  ---
Works TOT llvm tested today

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 44160] TestSteppingOutWithArtificialFrames.py fails on AArch64 Ubuntu

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=44160

Omair Javaid  changed:

   What|Removed |Added

 CC||omair.jav...@linaro.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Omair Javaid  ---
Seems to be fixed now.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 27883] TestConstVariables.py fails on arm/aarch64 linux targets failing frame variable type lookup

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=27883

Omair Javaid  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #1 from Omair Javaid  ---
Works tot llvm tested today.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 37301] Unable to display statically initialized pointers on arm64 (linux?) without a running process

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=37301

Omair Javaid  changed:

   What|Removed |Added

 CC||omair.jav...@linaro.org
 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Omair Javaid  ---
This works TOT as of today on arm/aarch64 linux.

Tested on Ubuntu Bionic and Xenial.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

[Jonas Devlieghere via lldb-dev]

On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath  wrote:
>
> I think this would be a very interesting project, and would allow us to
> flesh out the details of the script interpreter interface.
>
> A lot of the complexity in our python code comes from the fact that
> python can be (a) embedded into lldb and (b) lldb can be embedded into
> python. It's been a while since I worked with lua, but from what I
> remember, lua was designed to make (a) easy., and I don't think (b) was
> ever a major goal (though it can always be done ways, of course)..
>
> Were you intending to implement both of these directions or just one of
> them ((a), I guess)?

Thanks for pointing this out. Indeed, my goal is only to support (a)
for exactly the reasons you brought up.

> The reason I am asking this is because doing only (a) will definitely
> make lua support simpler than python, but it will also mean it won't be
> a "python-lite".
>
> Both of these options are fine -- I just want to understand where you're
> going with this. It also has some impact on the testing strategy, as our
> existing python tests are largely using mode (b).

That's part of my motivation for *not* doing (b). I really don't want
to create/maintain another (Lua driven) test suite.

> Another question I'm interested in is how deeply will this
> multi-interpreter thing go? Will it be a build time option, will it be
> selectable at runtime, but we'll have only one script interpreter per
> SBDebugger, or will we be able to freely mix'n'match scripting languages?

There is one script interpreter per debugger. As far as I can tell
from the code this is already enforced.

> I think the last option would be best because of data formatters
> (otherwise one would have a problem is some of his data formatters are
> written in python and others in lua), but it would also create a lot
> more of new api surface, as one would have to worry about consistency of
> the lua and python views of lldb, etc.

That's an interesting problem I didn't think of. I'm definitely not
excited about having the same data formatter implemented in both
scripting languages. Mixing scripting languages makes sense for when
your LLDB is configured to support both Python and Lua, but what do
you do for people that want only Lua? They might still want to
re-implement some data formatters they care about... Anyway, given
that we don't maintain/ship data formatters in Python ourselves, maybe
this isn't that big of an issue at all?

> On 09/12/2019 01:25, Jonas Devlieghere via lldb-dev wrote:
> > Hi everyone,
> >
> > Earlier this year, when I was working on the Python script
> > interpreter, I thought it would be interesting to see what it would
> > take to support other scripting languages in LLDB. Lua, being designed
> > to be embedded, quickly came to mind. The idea remained in the back of
> > my head, but I never really got around to it, until now.
> >
> > I was pleasantly surprised to see that it only took me a few hours to
> > create a basic but working prototype. It supports running single
> > commands as well as an interactive interpreter and has access to most
> > of the SB API through bindings generated by SWIG. Of course it's far
> > from complete.
> >
> > Before I invest more time in this, I'm curious to hear what the
> > community thinks about adding support for another scripting language
> > to LLDB. Do we need both Lua and Python?
> >
> > Here are some of the reasons off the top of my head as to why the
> > answer might be
> > "yes":
> >
> >  - The cost for having another scripting language is pretty small. The
> > Lua script interpreter is very simple and SWIG can reuse the existing
> > interfaces to generate the bindings.
> >  - LLDB is designed to support multiple script interpreters, but in
> > reality we only have one. Actually exercising this property ensures
> > that we don't unintentionally break that design assumptions.
> >  - The Python script interpreter is complex. It's hard to figure out
> > what's really needed to support another language. The Lua script
> > interpreter on the other hand is pretty straightforward. Common code
> > can be shared by both.
> >  - Currently Python support is disabled for some targets, like Android
> > and iOS. Lua could enable scripting for these environments where
> > having all of Python is overkill or undesirable.
> >
> > Reasons why the answer might be "no":
> >
> >  - Are our users going to use this?
> >  - Supporting Python is an ongoing pain. Do we really want to risk
> > burdening ourselves with another scripting language?
> >  - The Python API is very well tested. We'd need to add test for the
> > Lua bindings as well. It's unlikely this will match the coverage of
> > Python, and probably even undesirable, because what's the point of
> > testing the same thing twice. Also, do we want to risk fragmenting
> > tests across two scripting languages?
> >
> > There's probably a bunch more stuff that I didn't even think of. :-)
> >
> > Personall

[lldb-dev] [Bug 44259] New: lldb crashes because of stack overflow in clang::ASTContext::getASTRecordLayout

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=44259

Bug ID: 44259
   Summary: lldb crashes because of stack overflow in
clang::ASTContext::getASTRecordLayout
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: vadi...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

lldb was built from top of the master (d5acc83a), but the same happens with
lldb-7.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Supporting Lua Scripting in LLDB

[Jonas Devlieghere via lldb-dev]

Given that the response so far has been positive, I've put up the
patches for review:

https://reviews.llvm.org/D71232
https://reviews.llvm.org/D71234
https://reviews.llvm.org/D71235

Jonas

On Mon, Dec 9, 2019 at 9:27 AM Jonas Devlieghere  wrote:
>
> On Mon, Dec 9, 2019 at 1:55 AM Pavel Labath  wrote:
> >
> > I think this would be a very interesting project, and would allow us to
> > flesh out the details of the script interpreter interface.
> >
> > A lot of the complexity in our python code comes from the fact that
> > python can be (a) embedded into lldb and (b) lldb can be embedded into
> > python. It's been a while since I worked with lua, but from what I
> > remember, lua was designed to make (a) easy., and I don't think (b) was
> > ever a major goal (though it can always be done ways, of course)..
> >
> > Were you intending to implement both of these directions or just one of
> > them ((a), I guess)?
>
> Thanks for pointing this out. Indeed, my goal is only to support (a)
> for exactly the reasons you brought up.
>
> > The reason I am asking this is because doing only (a) will definitely
> > make lua support simpler than python, but it will also mean it won't be
> > a "python-lite".
> >
> > Both of these options are fine -- I just want to understand where you're
> > going with this. It also has some impact on the testing strategy, as our
> > existing python tests are largely using mode (b).
>
> That's part of my motivation for *not* doing (b). I really don't want
> to create/maintain another (Lua driven) test suite.
>
> > Another question I'm interested in is how deeply will this
> > multi-interpreter thing go? Will it be a build time option, will it be
> > selectable at runtime, but we'll have only one script interpreter per
> > SBDebugger, or will we be able to freely mix'n'match scripting languages?
>
> There is one script interpreter per debugger. As far as I can tell
> from the code this is already enforced.
>
> > I think the last option would be best because of data formatters
> > (otherwise one would have a problem is some of his data formatters are
> > written in python and others in lua), but it would also create a lot
> > more of new api surface, as one would have to worry about consistency of
> > the lua and python views of lldb, etc.
>
> That's an interesting problem I didn't think of. I'm definitely not
> excited about having the same data formatter implemented in both
> scripting languages. Mixing scripting languages makes sense for when
> your LLDB is configured to support both Python and Lua, but what do
> you do for people that want only Lua? They might still want to
> re-implement some data formatters they care about... Anyway, given
> that we don't maintain/ship data formatters in Python ourselves, maybe
> this isn't that big of an issue at all?
>
> > On 09/12/2019 01:25, Jonas Devlieghere via lldb-dev wrote:
> > > Hi everyone,
> > >
> > > Earlier this year, when I was working on the Python script
> > > interpreter, I thought it would be interesting to see what it would
> > > take to support other scripting languages in LLDB. Lua, being designed
> > > to be embedded, quickly came to mind. The idea remained in the back of
> > > my head, but I never really got around to it, until now.
> > >
> > > I was pleasantly surprised to see that it only took me a few hours to
> > > create a basic but working prototype. It supports running single
> > > commands as well as an interactive interpreter and has access to most
> > > of the SB API through bindings generated by SWIG. Of course it's far
> > > from complete.
> > >
> > > Before I invest more time in this, I'm curious to hear what the
> > > community thinks about adding support for another scripting language
> > > to LLDB. Do we need both Lua and Python?
> > >
> > > Here are some of the reasons off the top of my head as to why the
> > > answer might be
> > > "yes":
> > >
> > >  - The cost for having another scripting language is pretty small. The
> > > Lua script interpreter is very simple and SWIG can reuse the existing
> > > interfaces to generate the bindings.
> > >  - LLDB is designed to support multiple script interpreters, but in
> > > reality we only have one. Actually exercising this property ensures
> > > that we don't unintentionally break that design assumptions.
> > >  - The Python script interpreter is complex. It's hard to figure out
> > > what's really needed to support another language. The Lua script
> > > interpreter on the other hand is pretty straightforward. Common code
> > > can be shared by both.
> > >  - Currently Python support is disabled for some targets, like Android
> > > and iOS. Lua could enable scripting for these environments where
> > > having all of Python is overkill or undesirable.
> > >
> > > Reasons why the answer might be "no":
> > >
> > >  - Are our users going to use this?
> > >  - Supporting Python is an ongoing pain. Do we really want to risk
> > > burdening ourselves with another scripting langu