Re: [lldb-dev] [llvm-dev] [Release-testers] [6.0.0 Release] Release Candidate 1 tagged
Thanks! On Sat, Jan 20, 2018 at 1:32 PM, Dimitry Andric wrote: > On 19 Jan 2018, at 17:11, Hans Wennborg wrote: >> >> On Thu, Jan 18, 2018 at 7:27 PM, Dimitry Andric wrote: >>> On 18 Jan 2018, at 15:03, Jonas Hahnfeld wrote: Am 2018-01-18 14:55, schrieb Dimitry Andric via llvm-dev: > On 17 Jan 2018, at 18:53, Hans Wennborg via Release-testers > wrote: >> Start your engines; 6.0.0-rc1 was just tagged. >> I know there are still open blockers and it's early in the process in >> a way, but I'd like to find out where we are. Please run the test >> script, let me know the results, and upload binaries. > At the moment I can't compile openmp, since it errors out on libomptarget: > /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:50:10: > error: use of undeclared identifier 'malloc' > rc = malloc(size); >^ > /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:76:5: > error: use of undeclared identifier 'free' > free(device_ptr); > ^ > /home/dim/llvm-6.0.0/rc1/llvm.src/projects/openmp/libomptarget/src/api.cpp:163:20: > error: use of undeclared identifier 'malloc' > void *buffer = malloc(length); > ^ > I'm trying a local fix here, namely including at the top of the > file. Argh, I have missed that header. Adding sounds like the right solution, can you submit a patch or directly commit to SVN if it works for you? >>> >>> I added to api.cpp, interface.cpp and rtl.cpp, in r322869. Hans, >>> could you please merge it to release_60, or shall I do it? >> >> Go ahead if you're set up, otherwise let me know and I'll do it. > > Done in r323037. I have also taken the liberty of merging r322875 and > r322879, in which I added a '-no-libcxxabi' option to the test-release.sh > script. > > -Dimitry > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Anybody using the Go/Java debugger plugins?
Hi, during my wandering I stumbled upon the `Go` and the `Java` plugins in the lldb source tree. They seem to not have been touched in a while, and I'm not necessarily sure they're in a working state. Keeping them in tree is a maintenance burden, so unless somebody is actively using them or somebody is willing to step up as maintainers, I'm not necessarily sure we should pay this price. An alternative would be that of having a pluggable mechanism to add language support (I haven't fleshed out the details of this yet, but it should be possible, somehow). Other languages which have out of tree support might benefit from this (e.g. Swift/Rust). Thoughts? -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Anybody using the Go/Java debugger plugins?
The Go support for added by Ryan as a 20% project. Now that he's no longer working for Google, it's pretty much abandoned. The Java support was added by us (android folks) to support java debugging (to a certain extent). However, we never really finished the project, so we're not using that code now. We're hoping to come back to it one day, but I agree we should not burden everyone else while we make up our mind on that. So I don't think anybody would shout at us if we removed them right now, but maybe we should make some effort to find a maintainer for them before removal? E.g. publicly declare that they are going to be deleted on date unless a maintainer steps up to take care of them (we can define the minimum level of support we'd expect from such a maintainer). Then I can e.g. forward the email to the Google Go folks and see if anyone of them wants to take that up. As for Java, I'm going to bring up the desire to remove the Java plugin on our team's meeting this week and get back to you with the result. In general I think that a clear deprecation/removal process would be nice to have. I have a couple of things I think are broken/unused (PlatformKalimba? non-stop mode?) but I haven't brought them up because I was unsure how to handle it. On 22 January 2018 at 15:28, Davide Italiano wrote: > Hi, > during my wandering I stumbled upon the `Go` and the `Java` plugins in > the lldb source tree. > They seem to not have been touched in a while, and I'm not necessarily > sure they're in a working state. Keeping them in tree is a maintenance > burden, so unless somebody is actively using them or somebody is > willing to step up as maintainers, I'm not necessarily sure we should > pay this price. > > An alternative would be that of having a pluggable mechanism to add > language support (I haven't fleshed out the details of this yet, but > it should be possible, somehow). Other languages which have out of > tree support might benefit from this (e.g. Swift/Rust). > > Thoughts? > > -- > Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Anybody using the Go/Java debugger plugins?
To Davide's alternative: LLDB does handle loading plugins that use the SB API's (for things like data formatters.) But there's not currently an SB interface to support writing a full language plugin, and we don't export the lldb_private API's from the lldb binary. So there's no current mechanism to provide out-of-tree language plugins. It would be great to enable out-of-tree language support mechanisms but we would have to design an SB interface for that purpose. I see occasional questions about using Go with lldb on stack overflow and the like. It might be good to put out a more general "anybody interested in supporting this" call for Go, but I'm not sure the lldb-dev list is the best place to find an owner. Is there some Go dev list we can ask to see if anybody cares to support this? Non-stop never actually worked, it was just a promise, and the code for it was pretty thin. I would be okay with pulling that out unless somebody is actually getting good use out of it. Jim > On Jan 22, 2018, at 10:17 AM, Pavel Labath via lldb-dev > wrote: > > The Go support for added by Ryan as a 20% project. Now that he's no > longer working for Google, it's pretty much abandoned. > The Java support was added by us (android folks) to support java > debugging (to a certain extent). However, we never really finished the > project, so we're not using that code now. We're hoping to come back > to it one day, but I agree we should not burden everyone else while we > make up our mind on that. > > So I don't think anybody would shout at us if we removed them right > now, but maybe we should make some effort to find a maintainer for > them before removal? E.g. publicly declare that they are going to be > deleted on date unless a maintainer steps up to take care of them > (we can define the minimum level of support we'd expect from such a > maintainer). Then I can e.g. forward the email to the Google Go folks > and see if anyone of them wants to take that up. > > As for Java, I'm going to bring up the desire to remove the Java > plugin on our team's meeting this week and get back to you with the > result. > > > In general I think that a clear deprecation/removal process would be > nice to have. I have a couple of things I think are broken/unused > (PlatformKalimba? non-stop mode?) but I haven't brought them up > because I was unsure how to handle it. > > > On 22 January 2018 at 15:28, Davide Italiano wrote: >> Hi, >> during my wandering I stumbled upon the `Go` and the `Java` plugins in >> the lldb source tree. >> They seem to not have been touched in a while, and I'm not necessarily >> sure they're in a working state. Keeping them in tree is a maintenance >> burden, so unless somebody is actively using them or somebody is >> willing to step up as maintainers, I'm not necessarily sure we should >> pay this price. >> >> An alternative would be that of having a pluggable mechanism to add >> language support (I haven't fleshed out the details of this yet, but >> it should be possible, somehow). Other languages which have out of >> tree support might benefit from this (e.g. Swift/Rust). >> >> Thoughts? >> >> -- >> Davide > ___ > 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] LLDB Future Directions BoF
Hi all, I'm interested in understanding the why of LLDB, for that i'd love to be able to read any meeting notes or slides of the BoF on the future of LLDB and if possible make it available at [1] . I'd also would like any indication of reading materials on the internals of a debugger, preferabbly including something for begginers as the excelent chapther for LLVM on the The Architecture of Open Source Applications book [2]. And finally I'd ask why you chose to create LLDB when GDB was already there, the idea of reusing LLVM components (the c++ parser and AST ?) was proven benefical? Over the months of reading this list I've seen that there's significant attrition on what LLVM and LLDB require of their components and there are several cases of copying entire files with diverging changes between each project, is there a simply reason on why or is it a matter of needing more time to conciliate these disparate needs ? Thx for any and all responses. [1] http://llvm.org/devmtg/2017-10/#bof7 [2] http://www.aosabook.org/en/llvm.html ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36048] New: TestDataFormatterLibcxxVector.py and TestDataFormatterLibcxxVector.py fail with -fmodules
https://bugs.llvm.org/show_bug.cgi?id=36048 Bug ID: 36048 Summary: TestDataFormatterLibcxxVector.py and TestDataFormatterLibcxxVector.py fail with -fmodules Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: v...@apple.com CC: llvm-b...@lists.llvm.org These tests were not actually ever building with -fmodules because in Makefile.rules, we strip out -fmodules for c++11 tests. If we stop doing that, we see: 1: test_with_run_command_dsym (TestDataFormatterLibcxxVector.LibcxxVectorDataFormatterTestCase) Test that that file and class static variables display correctly. ... ok 2: test_with_run_command_dwarf (TestDataFormatterLibcxxVector.LibcxxVectorDataFormatterTestCase) Test that that file and class static variables display correctly. ... ok 3: test_with_run_command_gmodules (TestDataFormatterLibcxxVector.LibcxxVectorDataFormatterTestCase) Test that that file and class static variables display correctly. ... FAILURE The symptoms are that the data formatters print the wrong summaries for the vector/list containers. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
