Re: [lldb-dev] [Release-testers] [9.0.0 Release] Release Candidate 4 is here

[Dimitry Andric via lldb-dev]

On 10 Sep 2019, at 12:26, Hans Wennborg via Release-testers 
 wrote:
> 
> 9.0.0-rc4 was just tagged from the release_90 branch at r371490. In
> the Git monorepo, it's tagged as llvmorg-9.0.0-rc4.

For this rc, I used two patches, from:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, 
Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link 
flag for dynamic ASan tests

Uploaded:

SHA256 (clang+llvm-9.0.0-rc4-amd64-unknown-freebsd11.tar.xz) = 
e3ec34f97c26b0cae6833f8c565b011c3a111880da5191f131e2491bcace6960
SHA256 (clang+llvm-9.0.0-rc4-i386-unknown-freebsd11.tar.xz) = 
39e9d341838d8966c187ad4baccc2f7ddc45cb3d0dbb76f46098e1963c4b9f31

Main test results on amd64-freebsd11:

  
  Unexpected Passing Tests (6):
  AddressSanitizer-i386-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  AddressSanitizer-x86_64-freebsd-dynamic :: 
TestCases/interception_failure_test.cc
  lldb-Suite :: api/multiple-targets/TestMultipleTargets.py
  lldb-Suite :: 
functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py
  lldb-Suite :: lang/cpp/namespace/TestNamespaceLookup.py
  lldb-Suite :: python_api/thread/TestThreadAPI.py

  
  Failing Tests (402):
  AddressSanitizer-Unit :: 
./Asan-i386-calls-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-Unit :: 
./Asan-i386-inline-Dynamic-Test/AddressSanitizer.ShadowGapTest
  AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc
  AddressSanitizer-i386-freebsd-dynamic :: TestCases/Posix/fread_fwrite.cc
  Builtins-i386-freebsd :: floatundixf_test.c
  LLDB :: ExecControl/StopHook/stop-hook-threads.test
  LLDB :: ExecControl/StopHook/stop-hook.test
  LLDB :: Expr/TestIRMemoryMap.test
  LLDB :: SymbolFile/DWARF/debug-names-compressed.cpp
  LLDB :: SymbolFile/DWARF/find-basic-variable.cpp
  LLDB :: SymbolFile/DWARF/find-function-regex.cpp
  LLDB :: SymbolFile/DWARF/find-inline-method.s
  LLDB :: SymbolFile/DWARF/find-variable-dwo.cpp
  LLVM :: tools/yaml2obj/elf-override-shoffset.yaml
  LLVM :: tools/yaml2obj/elf-override-shsize.yaml
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer.valloc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.bind_getsockname
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.confstr
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.mbrtowc
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.swprintf
  MemorySanitizer-Unit :: 
./Msan-x86_64-with-call-Test/MemorySanitizer.valloc
  MemorySanitizer-X86_64 :: dtls_test.c
  Profile-x86_64 :: Posix/instrprof-gcov-fork.test
  SanitizerCommon-asan-i386-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-asan-i386-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-asan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-msan-x86_64-FreeBSD :: Posix/weak_hook_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/capsicum.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: FreeBSD/fdevname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/arc4random.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dedup_token_length_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/devname_r.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/dump_instruction_bytes.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fpe.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputc_putc_putchar.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fputs_puts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fseek.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/fts.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/funopen.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getfsent.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getmntinfo.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getpass.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/getusershell.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/illegal_read_test.cc
  SanitizerCommon-tsan-x86_64-FreeBSD :: Posix/il

Re: [lldb-dev] lldb access in Emacs via realgud

[Rocky Bernstein via lldb-dev]

Your guess is as good as mine. The one you project link you give looks more
akin to what I was looking for.

At any rate, rather than try to fix up lldb-mi, I'd put my (limited)
resources into using one of these and beefing it up if it needs
improvement.

On Thu, Sep 12, 2019 at 10:33 PM Adrian Prantl  wrote:

>
>
> On Sep 12, 2019, at 4:45 PM, Rocky Bernstein  wrote:
>
>
>
> On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl  wrote:
>
>>
>>
>> > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein  wrote:
>> >
>> >
>> >
>> > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl 
>> wrote:
>> >>
>> >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >> >
>> >> >
>> >> > Hi - I just wanted to mention that if there are emacs users there is
>> an interface to lldb via realgud. See
>> https://github.com/realgud/realgud-lldb
>> >> >
>> >> > A MELPA package and ELPA packageElpa package are available too
>> >>
>> >> Nice. It's always exciting to see wider adoption through better editor
>> integration. Out of curiosity, how does this compare to regular gud.el? (
>> https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html
>> )
>> >
>> > "Regular" gud? The most recent copyright on that link is 2008. I see a
>> gud.el in 26.2 and in the GNU savannah git sources, but neither mentions
>> lldb. Assuming that file is really from 2008, has lldb changed since then?
>> (This is a rhetorical question).  But the broader question is really who is
>> maintaining that file you link, clearly it is not the GNU Emacs community.
>> And how easy is it to do so? I see an "arch" tag on the file, so I guess
>> this in version control somewhere. But if there is a bug in this file, what
>> does one do? (This is not a rhetorical question; if you know the answer, I
>> am interested.)
>>
>> I think this file is effectively abandoned as it is neither part of the
>> LLDB repository nor is it shipping with emacs in macOS any longer.
>>
>> > Adapted from https://github.com/realgud/realgud/blob/master/realgud.el
>> >
>> >> Here we make use of more modern programming practices, more numerous
>> and smaller files, unit tests, and better use of Emacs primitives, e.g.
>> buffer marks, buffer-local variables, structures, rings, hash tables.
>> Although there is still much to be desired, this code is more scalable and
>> suitable as a common base for an Emacs front-end to modern debuggers.
>> >> Oh, and because global variables are largely banned, we can support
>> several simultaneous debug sessions.
>>
>> > gdb-mi has a nicer multi-frame display,  but you were linking to gud.el
>> which doesn't have that as far as I know. realgud-lldb at this point
>> probably knows more about lldb. But you guys can probably verify that, and
>> if realgud-lldb is lacking, I'd be interested to learn what should be added.
>>
>> >
>> > gud has always been a bit too monolithic - it contains every debugger
>> (including some obsolete ones - does anyone really still use dbx, and if so
>> inside Emacs?). All of this is in that one several-thousand-line file. I
>> find this ironic because the principal author is wrote something about
>> "Cathedral versus Bazaar" and this is clearly Cathedral style.
>> >
>> > It took me quite a while to be able to break realgud into several
>> distinct files. In fact I had to write my own nodejs-like "require" package
>> to be able to do internal or relative module linking. And then after that,
>> more work was done to split off the debuggers from the core debugger module
>> into separate github projects.
>>
>> Thanks for explaining the differences!
>>
>> Is realgud scraping lldb's console output like gud was or is it using the
>> LLDB scripting API? If it isn't already you might want to consider using
>> the scripting API since LLDB's console output is not necessarily stable,
>> but the scripting API is.
>>
>
> Yes, it scrapes console output and that is a problem. A big problem.
>
> I looked at the LLDB API and that seems pretty extensive and seems to
> cover a lot more of what interaction from Emacs would like and is currently
> missing.
>
> However as is in its current state, this isn't going to cut it because
> Emacs uses its own Lisp, not Python.
>
> I have toyed with the idea of hooking into something more standard, and as
> I said, there are so many to choose from. For example, the V8 debugger
> protcol works over a websocket,  and speaking over a websocket is something
> you can expect IDEs to grok.  Python LLDB's API to say Microsoft's Debug
> Adaptor Protocol  makes
> sense, and https://github.com/vadimcn/vscode-lldb/blob/v1.3.0/MANUAL.md seems
> to get pretty close to that.
>
>
> [Adding Greg to the conversation]
>
> What's the relation between that project and
> https://github.com/llvm/llvm-project/tree/master/lldb/tools/lldb-vscode? From
> the comments it looks like this is actually implementing the Debug Adaptor
> Protocol?
>

Re: [lldb-dev] lldb access in Emacs via realgud

[Adrian Prantl via lldb-dev]

> On Sep 12, 2019, at 4:45 PM, Rocky Bernstein  wrote:
> 
> 
> 
> On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl  > wrote:
> 
> 
> > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein  > > wrote:
> > 
> > 
> > 
> > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl  > > wrote:
> >> 
> >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev 
> >> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >> > 
> >> > 
> >> > Hi - I just wanted to mention that if there are emacs users there is an 
> >> > interface to lldb via realgud. See 
> >> > https://github.com/realgud/realgud-lldb 
> >> > 
> >> > 
> >> > A MELPA package and ELPA packageElpa package are available too 
> >> 
> >> Nice. It's always exciting to see wider adoption through better editor 
> >> integration. Out of curiosity, how does this compare to regular gud.el? 
> >> (https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html
> >>  
> >> )
> > 
> > "Regular" gud? The most recent copyright on that link is 2008. I see a 
> > gud.el in 26.2 and in the GNU savannah git sources, but neither mentions 
> > lldb. Assuming that file is really from 2008, has lldb changed since then? 
> > (This is a rhetorical question).  But the broader question is really who is 
> > maintaining that file you link, clearly it is not the GNU Emacs community. 
> > And how easy is it to do so? I see an "arch" tag on the file, so I guess 
> > this in version control somewhere. But if there is a bug in this file, what 
> > does one do? (This is not a rhetorical question; if you know the answer, I 
> > am interested.)
> 
> I think this file is effectively abandoned as it is neither part of the LLDB 
> repository nor is it shipping with emacs in macOS any longer.
> 
> > Adapted from https://github.com/realgud/realgud/blob/master/realgud.el 
> > 
> > 
> >> Here we make use of more modern programming practices, more numerous and 
> >> smaller files, unit tests, and better use of Emacs primitives, e.g. buffer 
> >> marks, buffer-local variables, structures, rings, hash tables. Although 
> >> there is still much to be desired, this code is more scalable and suitable 
> >> as a common base for an Emacs front-end to modern debuggers.
> >> Oh, and because global variables are largely banned, we can support 
> >> several simultaneous debug sessions.
> 
> > gdb-mi has a nicer multi-frame display,  but you were linking to gud.el 
> > which doesn't have that as far as I know. realgud-lldb at this point 
> > probably knows more about lldb. But you guys can probably verify that, and 
> > if realgud-lldb is lacking, I'd be interested to learn what should be 
> > added. 
> > 
> > gud has always been a bit too monolithic - it contains every debugger 
> > (including some obsolete ones - does anyone really still use dbx, and if so 
> > inside Emacs?). All of this is in that one several-thousand-line file. I 
> > find this ironic because the principal author is wrote something about 
> > "Cathedral versus Bazaar" and this is clearly Cathedral style. 
> > 
> > It took me quite a while to be able to break realgud into several distinct 
> > files. In fact I had to write my own nodejs-like "require" package to be 
> > able to do internal or relative module linking. And then after that, more 
> > work was done to split off the debuggers from the core debugger module into 
> > separate github projects.
> 
> Thanks for explaining the differences!
> 
> Is realgud scraping lldb's console output like gud was or is it using the 
> LLDB scripting API? If it isn't already you might want to consider using the 
> scripting API since LLDB's console output is not necessarily stable, but the 
> scripting API is.
> 
> Yes, it scrapes console output and that is a problem. A big problem.
> 
> I looked at the LLDB API and that seems pretty extensive and seems to cover a 
> lot more of what interaction from Emacs would like and is currently missing.
> 
> However as is in its current state, this isn't going to cut it because Emacs 
> uses its own Lisp, not Python.
> 
> I have toyed with the idea of hooking into something more standard, and as I 
> said, there are so many to choose from. For example, the V8 debugger protcol 
> works over a websocket,  and speaking over a websocket is something you can 
> expect IDEs to grok.  Python LLDB's API to say Microsoft's Debug Adaptor 
> Protocol  makes sense, 
> and https://github.com/vadimcn/vscode-lldb/blob/v1.3.0/MANUAL.md 
>  seems to get 
> pretty close to that. 
> 

[Adding Greg to the conversation]

What's the relation between that project and 
https://github.com/llvm/llvm-project/tree/master/lldb/too

Re: [lldb-dev] lldb access in Emacs via realgud

[Rocky Bernstein via lldb-dev]

On Thu, Sep 12, 2019 at 5:51 PM Adrian Prantl  wrote:

>
>
> > On Sep 12, 2019, at 2:24 PM, Rocky Bernstein  wrote:
> >
> >
> >
> > On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl  wrote:
> >>
> >> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >> >
> >> >
> >> > Hi - I just wanted to mention that if there are emacs users there is
> an interface to lldb via realgud. See
> https://github.com/realgud/realgud-lldb
> >> >
> >> > A MELPA package and ELPA packageElpa package are available too
> >>
> >> Nice. It's always exciting to see wider adoption through better editor
> integration. Out of curiosity, how does this compare to regular gud.el? (
> https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html
> )
> >
> > "Regular" gud? The most recent copyright on that link is 2008. I see a
> gud.el in 26.2 and in the GNU savannah git sources, but neither mentions
> lldb. Assuming that file is really from 2008, has lldb changed since then?
> (This is a rhetorical question).  But the broader question is really who is
> maintaining that file you link, clearly it is not the GNU Emacs community.
> And how easy is it to do so? I see an "arch" tag on the file, so I guess
> this in version control somewhere. But if there is a bug in this file, what
> does one do? (This is not a rhetorical question; if you know the answer, I
> am interested.)
>
> I think this file is effectively abandoned as it is neither part of the
> LLDB repository nor is it shipping with emacs in macOS any longer.
>
> > Adapted from https://github.com/realgud/realgud/blob/master/realgud.el
> >
> >> Here we make use of more modern programming practices, more numerous
> and smaller files, unit tests, and better use of Emacs primitives, e.g.
> buffer marks, buffer-local variables, structures, rings, hash tables.
> Although there is still much to be desired, this code is more scalable and
> suitable as a common base for an Emacs front-end to modern debuggers.
> >> Oh, and because global variables are largely banned, we can support
> several simultaneous debug sessions.
>
> > gdb-mi has a nicer multi-frame display,  but you were linking to gud.el
> which doesn't have that as far as I know. realgud-lldb at this point
> probably knows more about lldb. But you guys can probably verify that, and
> if realgud-lldb is lacking, I'd be interested to learn what should be
> added.
> >
> > gud has always been a bit too monolithic - it contains every debugger
> (including some obsolete ones - does anyone really still use dbx, and if so
> inside Emacs?). All of this is in that one several-thousand-line file. I
> find this ironic because the principal author is wrote something about
> "Cathedral versus Bazaar" and this is clearly Cathedral style.
> >
> > It took me quite a while to be able to break realgud into several
> distinct files. In fact I had to write my own nodejs-like "require" package
> to be able to do internal or relative module linking. And then after that,
> more work was done to split off the debuggers from the core debugger module
> into separate github projects.
>
> Thanks for explaining the differences!
>
> Is realgud scraping lldb's console output like gud was or is it using the
> LLDB scripting API? If it isn't already you might want to consider using
> the scripting API since LLDB's console output is not necessarily stable,
> but the scripting API is.
>

Yes, it scrapes console output and that is a problem. A big problem.

I looked at the LLDB API and that seems pretty extensive and seems to cover
a lot more of what interaction from Emacs would like and is currently
missing.

However as is in its current state, this isn't going to cut it because
Emacs uses its own Lisp, not Python.

I have toyed with the idea of hooking into something more standard, and as
I said, there are so many to choose from. For example, the V8 debugger
protcol works over a websocket,  and speaking over a websocket is something
you can expect IDEs to grok.  Python LLDB's API to say Microsoft's Debug
Adaptor Protocol  makes
sense, and https://github.com/vadimcn/vscode-lldb/blob/v1.3.0/MANUAL.md seems
to get pretty close to that.


> >> >
> >> > A question: what ever became of the effort to port the Emacs gdb-mi
> to lldb?
> >>
> >> We recently removed lldb-mi from the LLDB repository because nobody in
> the community was willing to maintain it. In particular the tests were so
> unreliable that most bots disabled them wholesale because they were so
> noisy. We had a GSoC student a year ago who was able to rewrite many of the
> tests in a more reliable fashion, but there were still a lot of issues
> outstanding after the project was completed. If you are interested in
> picking this up, it may be worthwhile to think about implementing lldb-mi
> 2.0 as thin python layer using the python SBAPI. Python may be a better
> choice for the kind of text-heavy glue-code 

Re: [lldb-dev] lldb access in Emacs via realgud

[Adrian Prantl via lldb-dev]

> On Sep 12, 2019, at 2:24 PM, Rocky Bernstein  wrote:
> 
> 
> 
> On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl  wrote:
>> 
>> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev 
>> >  wrote:
>> > 
>> > 
>> > Hi - I just wanted to mention that if there are emacs users there is an 
>> > interface to lldb via realgud. See https://github.com/realgud/realgud-lldb
>> > 
>> > A MELPA package and ELPA packageElpa package are available too 
>> 
>> Nice. It's always exciting to see wider adoption through better editor 
>> integration. Out of curiosity, how does this compare to regular gud.el? 
>> (https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html)
> 
> "Regular" gud? The most recent copyright on that link is 2008. I see a gud.el 
> in 26.2 and in the GNU savannah git sources, but neither mentions lldb. 
> Assuming that file is really from 2008, has lldb changed since then? (This is 
> a rhetorical question).  But the broader question is really who is 
> maintaining that file you link, clearly it is not the GNU Emacs community. 
> And how easy is it to do so? I see an "arch" tag on the file, so I guess this 
> in version control somewhere. But if there is a bug in this file, what does 
> one do? (This is not a rhetorical question; if you know the answer, I am 
> interested.)

I think this file is effectively abandoned as it is neither part of the LLDB 
repository nor is it shipping with emacs in macOS any longer.

> Adapted from https://github.com/realgud/realgud/blob/master/realgud.el
> 
>> Here we make use of more modern programming practices, more numerous and 
>> smaller files, unit tests, and better use of Emacs primitives, e.g. buffer 
>> marks, buffer-local variables, structures, rings, hash tables. Although 
>> there is still much to be desired, this code is more scalable and suitable 
>> as a common base for an Emacs front-end to modern debuggers.
>> Oh, and because global variables are largely banned, we can support several 
>> simultaneous debug sessions.

> gdb-mi has a nicer multi-frame display,  but you were linking to gud.el which 
> doesn't have that as far as I know. realgud-lldb at this point probably knows 
> more about lldb. But you guys can probably verify that, and if realgud-lldb 
> is lacking, I'd be interested to learn what should be added. 
> 
> gud has always been a bit too monolithic - it contains every debugger 
> (including some obsolete ones - does anyone really still use dbx, and if so 
> inside Emacs?). All of this is in that one several-thousand-line file. I find 
> this ironic because the principal author is wrote something about "Cathedral 
> versus Bazaar" and this is clearly Cathedral style. 
> 
> It took me quite a while to be able to break realgud into several distinct 
> files. In fact I had to write my own nodejs-like "require" package to be able 
> to do internal or relative module linking. And then after that, more work was 
> done to split off the debuggers from the core debugger module into separate 
> github projects.

Thanks for explaining the differences!

Is realgud scraping lldb's console output like gud was or is it using the LLDB 
scripting API? If it isn't already you might want to consider using the 
scripting API since LLDB's console output is not necessarily stable, but the 
scripting API is.

>> > 
>> > A question: what ever became of the effort to port the Emacs gdb-mi to 
>> > lldb? 
>> 
>> We recently removed lldb-mi from the LLDB repository because nobody in the 
>> community was willing to maintain it. In particular the tests were so 
>> unreliable that most bots disabled them wholesale because they were so 
>> noisy. We had a GSoC student a year ago who was able to rewrite many of the 
>> tests in a more reliable fashion, but there were still a lot of issues 
>> outstanding after the project was completed. If you are interested in 
>> picking this up, it may be worthwhile to think about implementing lldb-mi 
>> 2.0 as thin python layer using the python SBAPI. Python may be a better 
>> choice for the kind of text-heavy glue-code that lldb-mi is. Alternatively 
>> it also shouldn't be hard at all to revive the existing C++ code. It's 
>> written in a different style than most of LLDB or LLVM (and IMO it should 
>> have never been accepted upstream in this form), but it shouldn't be hard to 
>> get building since it (thanks to the GSoC project!) is using only the stable 
>> public SBAPI.
> 
> 
> The great thing about standards is that there are so many to choose from!  

It sounds like you are very much invested in realgud, but if anyone else is 
reading this and interested in taking up maintainership for lldb-mi, I think 
we'd be happy to welcome it back in tree as long as it is 100% reliably(!) 
tested and maintained.

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

Re: [lldb-dev] lldb access in Emacs via realgud

[Rocky Bernstein via lldb-dev]

On Thu, Sep 12, 2019 at 3:37 PM Adrian Prantl  wrote:

>
> > On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> >
> > Hi - I just wanted to mention that if there are emacs users there is an
> interface to lldb via realgud. See https://github.com/realgud/realgud-lldb
> >
> > A MELPA package and ELPA packageElpa package are available too
>
> Nice. It's always exciting to see wider adoption through better editor
> integration. Out of curiosity, how does this compare to regular gud.el? (
> https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html
> )
>

"Regular" gud? The most recent copyright on that link is 2008. I see a
gud.el in 26.2 and in the GNU savannah git sources, but neither mentions
lldb. Assuming that file is really from 2008, has lldb changed since then?
(This is a rhetorical question).  But the broader question is really who is
maintaining that file you link, clearly it is not the GNU Emacs community.
And how easy is it to do so? I see an "arch" tag on the file, so I guess
this in version control somewhere. But if there is a bug in this file, what
does one do? (This is not a rhetorical question; if you know the answer, I
am interested.)


Adapted from https://github.com/realgud/realgud/blob/master/realgud.el

Here we make use of more modern programming practices, more numerous and
> smaller files, unit tests, and better use of Emacs primitives, e.g. buffer
> marks, buffer-local variables, structures, rings, hash tables. Although
> there is still much to be desired, this code is more scalable and suitable
> as a common base for an Emacs front-end to modern debuggers.
> Oh, and because global variables are largely banned, we can support
> several simultaneous debug sessions.
>

gdb-mi has a nicer multi-frame display,  but you were linking to gud.el
which doesn't have that as far as I know. realgud-lldb at this point
probably knows more about lldb. But you guys can probably verify that, and
if realgud-lldb is lacking, I'd be interested to learn what should be
added.

gud has always been a bit too monolithic - it contains every debugger
(including some obsolete ones - does anyone really still use dbx
, and if so inside Emacs?).
All of this is in that one several-thousand-line file. I find this ironic
because the principal author is wrote something about "Cathedral versus
Bazaar" and this is clearly Cathedral style.

It took me quite a while to be able to break realgud into several distinct
files. In fact I had to write my own nodejs-like "require" package
to be able to do internal
or relative module linking. And then after that, more work was done to
split off the debuggers from the core debugger module into separate github
projects.




> >
> > A question: what ever became of the effort to port the Emacs gdb-mi to
> lldb?
>
> We recently removed lldb-mi from the LLDB repository because nobody in the
> community was willing to maintain it. In particular the tests were so
> unreliable that most bots disabled them wholesale because they were so
> noisy. We had a GSoC student a year ago who was able to rewrite many of the
> tests in a more reliable fashion, but there were still a lot of issues
> outstanding after the project was completed. If you are interested in
> picking this up, it may be worthwhile to think about implementing lldb-mi
> 2.0 as thin python layer using the python SBAPI. Python may be a better
> choice for the kind of text-heavy glue-code that lldb-mi is. Alternatively
> it also shouldn't be hard at all to revive the existing C++ code. It's
> written in a different style than most of LLDB or LLVM (and IMO it should
> have never been accepted upstream in this form), but it shouldn't be hard
> to get building since it (thanks to the GSoC project!) is using only the
> stable public SBAPI.
>


The great thing about standards is that there are so many to choose from!

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

Re: [lldb-dev] lldb access in Emacs via realgud

[Adrian Prantl via lldb-dev]

> On Sep 11, 2019, at 1:08 AM, Rocky Bernstein via lldb-dev 
>  wrote:
> 
> 
> Hi - I just wanted to mention that if there are emacs users there is an 
> interface to lldb via realgud. See https://github.com/realgud/realgud-lldb
> 
> A MELPA package and ELPA packageElpa package are available too 

Nice. It's always exciting to see wider adoption through better editor 
integration. Out of curiosity, how does this compare to regular gud.el? 
(https://opensource.apple.com/source/lldb/lldb-69/utils/emacs/gud.el.auto.html)

> 
> A question: what ever became of the effort to port the Emacs gdb-mi to lldb? 

We recently removed lldb-mi from the LLDB repository because nobody in the 
community was willing to maintain it. In particular the tests were so 
unreliable that most bots disabled them wholesale because they were so noisy. 
We had a GSoC student a year ago who was able to rewrite many of the tests in a 
more reliable fashion, but there were still a lot of issues outstanding after 
the project was completed. If you are interested in picking this up, it may be 
worthwhile to think about implementing lldb-mi 2.0 as thin python layer using 
the python SBAPI. Python may be a better choice for the kind of text-heavy 
glue-code that lldb-mi is. Alternatively it also shouldn't be hard at all to 
revive the existing C++ code. It's written in a different style than most of 
LLDB or LLVM (and IMO it should have never been accepted upstream in this 
form), but it shouldn't be hard to get building since it (thanks to the GSoC 
project!) is using only the stable public SBAPI.

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

[lldb-dev] Compile lldb to wasm

[Z Nguyen-Huu via lldb-dev]

Hello,

For the purpose of debugging wasm code, I am investigating how to compile lldb 
to wasm module.

I am starting with use emconfigure (in emscripten) but it broke so many 
references, have not been able to generate cmake yet.
Has anyone done it before? Do you have any docs/ leads related the build 
systems or the minimal lldb build that I could start with?

Any leads/ideas would be highly appreciated.

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

Re: [lldb-dev] [libcxx-dev] [9.0.0 Release] Release Candidate 4 is here

[Diana Picus via lldb-dev]

Hi,

Uploaded
86efbad6d8677c64d057d92e1dd144988dee68f7a0faa84e5d12f1b59ded0e4f
clang+llvm-9.0.0-rc4-armv7a-linux-gnueabihf.tar.xz
eb37ced0868066fdf21a1539c61081b1b6e87f2fc6da58aa282230728329f80a
clang+llvm-9.0.0-rc4-aarch64-linux-gnu.tar.xz

Both seem fine.

Cheers,
Diana

On Tue, 10 Sep 2019 at 12:26, Hans Wennborg via libcxx-dev
 wrote:
>
> Hello again,
>
> 9.0.0-rc4 was just tagged from the release_90 branch at r371490. In
> the Git monorepo, it's tagged as llvmorg-9.0.0-rc4.
>
> Source code and docs are available at
> https://prereleases.llvm.org/9.0.0/#rc4 Binaries will be added as they
> become available.
>
> There are not a lot of changes from rc3 to rc4, and there are again no
> open release blockers, so I'm hoping this will be the last release
> candidate and that we can tag the final release soon.
>
> Please file bug reports for any issues you find, marking them blocking
> of https://llvm.org/PR42474
>
> Release testers, please run the test script, share your results, and
> upload binaries.
>
> Thanks,
> Hans
> ___
> libcxx-dev mailing list
> libcxx-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev