[lldb-dev] [6.0.0 Release] Release Candidate 3 source, docs and binaries available
Hi everyone, The source, docs and binaries for LLVM-6.0.0-rc3 are now available at http://prereleases.llvm.org/6.0.0/#rc3 More binaries will be added as they become available. Please report any problems you find as bugs marked blocking http://llvm.org/PR35804 If this looks good, the final tag will go in real soon now. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36490] Segmentation fault when accessing any Python script object
https://bugs.llvm.org/show_bug.cgi?id=36490 Evgeny Morozov changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|REOPENED --- Comment #5 from Evgeny Morozov --- OK, it turns out there is a version of libsosplugin.so that works with later LLDB versions. I still get a Segmentation fault in 5.0 (but not 3.9 or 4.0): $ lldb-5.0 (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> lldb >>> Segmentation fault (core dumped) Sometimes it works the first time, but crashes the second time: (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> lldb >>> >>> lldb Segmentation fault (core dumped) -- 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
[lldb-dev] FreeBSD LLDB buildbot
Years ago there was a FreeBSD LLDB buildbot managed by Galina; it was decommissioned quite some time ago. I've been running one since then, but it was never set up to run tests, only build. Over the weekend I tried to get it to run tests, but ended up with a broken installation. I've started over in a clean FreeBSD jail and have it configured again, but it appears that FreeBSD now has a newer version of the buildbot worker package (0.9.11) in the package collection that is not compatible with the server; the Python 3 version reported: remoteFailed: [Failure instance: Traceback from remote host -- Traceback unavailable buildbot_worker.base.UnknownCommand: unrecognized WorkerCommand 'b'shell'' ] I installed the Python 2 buildbot-worker 0.9.11 and it reports: exceptions.AssertionError: Unexpected usePTY argument value: 'slave-config'. Expected boolean. exceptions.AssertionError: Unexpected usePTY argument value: 'slave-config'. Expected boolean. It seems there's a number of interop problems between different Buildbot versions and Python 2 / Python 3. What is the best way to install a compatible buildbot worker? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36525] New: std::bad_alloc : Process::ReadModuleFromMemory is passed bogus size_to_read when "target modules load" libart.so
https://bugs.llvm.org/show_bug.cgi?id=36525 Bug ID: 36525 Summary: std::bad_alloc : Process::ReadModuleFromMemory is passed bogus size_to_read when "target modules load" libart.so Product: lldb Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: anthony.louis.e...@gmail.com CC: llvm-b...@lists.llvm.org (lldb) thread backtrace all * thread #1, name = 'lldb', stop reason = signal SIGABRT * frame #0: 0x749d2860 libc.so.6`__GI_raise + 272 frame #1: 0x749d3ec9 libc.so.6`__GI_abort + 457 frame #2: 0x74de3d57 libstdc++.so.6`__gnu_cxx::__verbose_terminate_handler() at vterminate.cc:95 frame #3: 0x74de18c6 libstdc++.so.6`__cxxabiv1::__terminate(handler=)()) at eh_terminate.cc:47 frame #4: 0x74de1913 libstdc++.so.6`std::terminate() at eh_terminate.cc:57 frame #5: 0x74de1b68 libstdc++.so.6`__cxxabiv1::__cxa_throw(obj=, tinfo=, dest=)(void *)) at eh_throw.cc:93 frame #6: 0x74de20cf libstdc++.so.6`operator new(sz=) at new_op.cc:54 frame #7: 0x7588f8c4 liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long, unsigned char) [inlined] __gnu_cxx::new_allocator::allocate(this=, (null)=, __n=) at new_allocator.h:111 frame #8: 0x7588f8be liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long, unsigned char) [inlined] std::allocator_traits >::allocate(__a=, __n=) at alloc_traits.h:436 frame #9: 0x7588f8be liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long, unsigned char) at stl_vector.h:172 frame #10: 0x7588f8be liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long, unsigned char) [inlined] std::_Vector_base >::_M_create_storage(__n=13151649335953326080, this=) at stl_vector.h:187 frame #11: 0x7588f8be liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long, unsigned char) [inlined] _ZNSt12_Vector_baseIhSaIhEEC4EmRKS0_(__a=0x55dbfd48, __n=13151649335953326080, this=) at stl_vector.h:138 frame #12: 0x7588f8be liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long, unsigned char) [inlined] _ZNSt6vectorIhSaIhEEC4EmRKhRKS0_(__a=0x55dbfd48, __value=, __n=13151649335953326080, this=) at stl_vector.h:297 frame #13: 0x7588f8be liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long, unsigned char) at vector.tcc:242 frame #14: 0x7588f8be liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(unsigned long, unsigned char) [inlined] std::vector >::assign(__val=, __n=13151649335953326080, this=0x55dbfd48) at stl_vector.h:502 frame #15: 0x7588f8be liblldb.so.5`lldb_private::DataBufferHeap::DataBufferHeap(this=0x55dbfd40, n=13151649335953326080, ch=) at DataBufferHeap.cpp:30 frame #16: 0x756615fd liblldb.so.5`lldb_private::Module::GetMemoryObjectFile(std::shared_ptr const&, unsigned long, lldb_private::Status&, unsigned long) [inlined] std::enable_if::value), std::unique_ptr > >::type llvm::make_unique((null)=, (null)=) at STLExtras.h:944 frame #17: 0x756615e6 liblldb.so.5`lldb_private::Module::GetMemoryObjectFile(this=0x55dbfff0, process_sp=std::__shared_ptr::element_type @ 0x5591fc20, header_addr=3068708324, error=0x7fffc2a0, size_to_read=13151649335953326080) at Module.cpp:333 frame #18: 0x7580384f liblldb.so.5`lldb_private::Process::ReadModuleFromMemory(this=0x5591fc20, file_spec=, header_addr=3068708324, size_to_read=13151649335953326080) at Process.cpp:2632 frame #19: 0x759a8e9b liblldb.so.5`bool JITLoaderGDB::ReadJITDescriptorImpl(this=0x5596cb60, all_entries=true) at JITLoaderGDB.cpp:318 frame #20: 0x759a7485 liblldb.so.5`JITLoaderGDB::SetJITBreakpoint(lldb_private::ModuleList&) at JITLoaderGDB.cpp:202 frame #21: 0x759a72fd liblldb.so.5`JITLoaderGDB::SetJITBreakpoint(this=0x5596cb60, module_list=) frame #22: 0x7587f6d0 liblldb.so.5`lldb_private::JITLoaderList::ModulesDidLoad(this=0x55967760, module_list=0x7fffc790) at JITLoaderList.cpp:55 frame #23: 0x7580853f liblldb.so.5`lldb_private::Process::ModulesDidLoad(this=0x5591fc20, module_list=0x7fffc790) at Process.cpp:5899 frame #24: 0x75ab259a liblldb.so.5`lldb_private::process_gdb_remote::ProcessGDBRemote::ModulesDidLoad(this=0x5591fc20, module_list=) at ProcessGDBRemote.cpp:4763 frame #25: 0x7583e69a liblldb.so.5`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] lldb_private::Target::ModulesDidLoad(module_list=0x7fffc790, this=0x5
[lldb-dev] [Bug 36527] New: test_*int*_t_dwarf failing on FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=36527
Bug ID: 36527
Summary: test_*int*_t_dwarf failing on FreeBSD
Product: lldb
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: ema...@freebsd.org
CC: llvm-b...@lists.llvm.org
test_{,u}int{8,16,32,64}_t_dwarf tests are failing on FreeBSD. I intend to
enable tests on the FreeBSD buildbot worker soon so track these failures in a
PR. Further details will be added as they become available.
(see test results snapshot at
http://lists.llvm.org/pipermail/lldb-dev/2018-February/013318.html)
--
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
Re: [lldb-dev] FreeBSD LLDB buildbot
Hi Ed, Please try to install pip to get buildslave v0.8.12. Something like this should work: pip install 'buildbot-slave <= 0.8.12' Thanks Galina On Mon, Feb 26, 2018 at 10:26 AM, Ed Maste wrote: > Years ago there was a FreeBSD LLDB buildbot managed by Galina; it was > decommissioned quite some time ago. I've been running one since then, > but it was never set up to run tests, only build. > > Over the weekend I tried to get it to run tests, but ended up with a > broken installation. I've started over in a clean FreeBSD jail and > have it configured again, but it appears that FreeBSD now has a newer > version of the buildbot worker package (0.9.11) in the package > collection that is not compatible with the server; the Python 3 > version reported: > > remoteFailed: [Failure instance: Traceback from remote host -- > Traceback unavailable > buildbot_worker.base.UnknownCommand: unrecognized WorkerCommand 'b'shell'' > ] > > I installed the Python 2 buildbot-worker 0.9.11 and it reports: > > exceptions.AssertionError: Unexpected usePTY argument value: > 'slave-config'. Expected boolean. > exceptions.AssertionError: Unexpected usePTY argument value: > 'slave-config'. Expected boolean. > > It seems there's a number of interop problems between different > Buildbot versions and Python 2 / Python 3. What is the best way to > install a compatible buildbot worker? > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] March LLVM bay-area social is this Thursday!
We'll be at Tied House as usual, starting on Thursday the 1st at 7pm! If you can, help us plan and RSVP here: https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyxfbcb/ See everyone there! ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FreeBSD LLDB buildbot
On 26 February 2018 at 18:46, Galina Kistanova wrote: > Hi Ed, > > Please try to install pip to get buildslave v0.8.12. > Something like this should work: > pip install 'buildbot-slave <= 0.8.12' Thanks Galina. I now have a jail running FreeBSD 11.1-Release hosting the original lldb-amd64-ninja-freebsd11 configuration, so we're at least back to a green build-only FreeBSD buildbot. http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11 For reference (most likely for my future self, when I have to set up another instance), this is how I set it up: 1. Create a FreeBSD 11.1-Release jail as described in https://www.freebsd.org/doc/handbook/jails-build.html. (As an aside, I found some outdated information in the FreeBSD handbook jails section; changes are in progress but noted in case anyone else wants to try.) 2. Install required packages: # pkg install cmake ninja swig30 subversion py27-pip 3. installed buildbot-slave via pip, as described above. This jail is used exclusively for this buildbot instance so there is no concern installing to the system-wide location. 4. Recreate buildbot.tac $ buildslave create-slave /usr/home/buildbot/scratch/ lab.llvm.org:9990 lldb-amd64-ninja-freebsd11 5. I copied the scripts (updateScripts.sh, checkoutSource.sh, etc.) from the previous buildbot installation (into scratch/scripts/). I think we should host all scripts for the builders in either the lldb or zorg repo - is there a reason they're not? 6. Add updateScripts.sh to path (I symlinked it into ~/bin). 7. Start the buildbot worker process $ buildslave start The host is running a FreeBSD 12-CURRENT kernel and to enable tests I expect I'll create a new FreeBSD 12 builder, which can be initially connected to the staging master. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Adding D language demangling support
I made it work:
https://github.com/llvm-mirror/lldb/pull/3
(note: also requires the D plugin on D side which I can submit to
another repo separately, and which is small)
not sure if lldb accepts github PR's but that's the simplest I could do
On Sun, Feb 25, 2018 at 3:53 PM, Timothee Cour wrote:
> update:
>
> * D now correctly prefixes its symbols with an extra underscore on OSX
> (cf https://dlang.org/changelog/2.079.0.html#fix8207) and gdb
> correctly demangles D symbols
> * in https://github.com/dlang/druntime/pull/2083 I had a PR to support
> demangling C++ symbols along with D symbols for D programs via runtime
> loading (dlopen) of libc++ ; could we use a similar technique for lldb
> by allowing user to dlopen a shared library that would customize
> demangling?
>
>
>
>
>
> On Mon, Sep 26, 2016 at 8:50 AM, Greg Clayton wrote:
>> Just did, and it looks good.
>>
>>> On Sep 26, 2016, at 3:49 AM, Johan Engelen wrote:
>>>
>>> Timothee, do you intend to work on this?
>>> What can I do to help?
>>>
>>> In the meanwhile, I'd appreciate it if someone could take a look at
>>> https://reviews.llvm.org/D24794 (currently, debugging D code is very much
>>> broken without that change).
>>>
>>> -Johan
>>>
>>>
>>> On Thu, Sep 22, 2016 at 7:21 PM, Greg Clayton via lldb-dev
>>> wrote:
>>> I like the JSON approach. We might need to include the mangled name for the
>>> function or specify where arguments go if we aren't going to expect a
>>> canned function to be in each dylib. That is a bit harder, but something we
>>> should think about.
>>>
>>> If we look at __cxa_demangle:
>>>
>>>
>>> char* abi::__cxa_demangle(const char *mangled_name, char *output_buffer,
>>> size_t *length, int *status);
>>>
>>> I am not sure how we would logically specify this in the JSON... Where to
>>> put the name to demangle, how to call it etc...
>>>
>>> > On Sep 22, 2016, at 9:56 AM, Timothee Cour
>>> > wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Sep 21, 2016 at 4:13 PM, Greg Clayton via lldb-dev
>>> > wrote:
>>> > You could have a setting that allows you to specify prefix as the key
>>> > with a dylib path as a value. Would you expect a function with certain
>>> > name or would you need to specify the function name (probably mangled) as
>>> > well? Let me know what you are thinking?
>>> >
>>> >
>>> > whatever works it doesn't really matter so long there's something to get
>>> > started, I was going for something simple to start with but if you want
>>> > this level of flexibility how about using a json config file:
>>> >
>>> > export LLDB_DEMANGLE_CONFIG_FILE="~/.lldbl.demangle.conf"
>>> >
>>> > cat ~/.lldbl.demangle.conf
>>> >
>>> > {"demangle":
>>> > ["D": {"prefix" : "_D", "shared_libary_file" :
>>> > "/path/libdemangled.dylib", "mangled_name", "_demangle_custom_D"}],
>>> > ["nim": /* same for nim language */ ],
>>> > }
>>> >
>>> > Greg
>>> >
>>> > > On Sep 21, 2016, at 3:50 PM, Timothee Cour
>>> > > wrote:
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Sep 21, 2016 at 3:35 PM, Greg Clayton via lldb-dev
>>> > > wrote:
>>> > > Sounds like you could then make a setting that is a dictionary where
>>> > > you say what the prefix is (like maybe "_D") and the value is the path
>>> > > to the tool to use? This would be easy to implement. Demangling does
>>> > > tend to be one of the most expensive parts of symbol file and debug
>>> > > info parsing, so if you do this, you will want to make sure the shell
>>> > > tool can be spawned and kept running maybe?
>>> > >
>>> > > Greg
>>> > >
>>> > >
>>> > > where in the lldb code would be such entry point?
>>> > >
>>> > > instead of a binary it can just be a library dynamically loaded via
>>> > > dlopen (as i wrote, though I should've called it LLDB_DEMANGLER_LIB
>>> > > instead of LLDB_DEMANGLER_EXE), and the dynamically loaded symbol be
>>> > > cached to make sure it's dlopen'd at most once per process.
>>> > >
>>> > > Then it's easy enough for us to write a demangleCustom that is fast on
>>> > > the D side of things. It can also work with a binary instead of a dllib
>>> > > but would be a bit slower (could have a client server model, but that's
>>> > > more complex than the simple dllib solution i was proposing).
>>> > >
>>> > > yes, we could use a prefix for that as well.
>>> > >
>>> > >
>>> > > > On Sep 21, 2016, at 3:30 PM, Timothee Cour
>>> > > > wrote:
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Wed, Sep 21, 2016 at 3:10 PM, Greg Clayton
>>> > > > wrote:
>>> > > > There is no external demangling plug-in infrastructure at the moment,
>>> > > > but you could add functionality that would allow it. No one is going
>>> > > > to have D installed by default. Where do you expect your demangler
>>> > > > dylib to live?
>>> > > > Would you just add code that tries to locate the dylib in N places on
>>> > > > the current system and try to dlopen it? Avoiding duplication and
>>> > > > just not having the functionality at all unless something else is
>>> > > > might n
[lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'
https://github.com/llvm-mirror/lldb/pull/3 it would be *really* nice if llvm or lldb accepted industry standard github PR's, at least as an option. Would make contributing so much easier for outsiders ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Adding D language demangling support
On Mon, Feb 26, 2018 at 8:45 PM, Timothee Cour via lldb-dev wrote: > I made it work: > https://github.com/llvm-mirror/lldb/pull/3 > (note: also requires the D plugin on D side which I can submit to > another repo separately, and which is small) > > not sure if lldb accepts github PR's but that's the simplest I could do > > No, llvm/lldb is still on svn so we don't really accept pull requests yet. You can submit a new review on Phabricator though. That said, thank you for your contribution. For new languages, we want to have a high quality barrier for entry. I really appareciate the fact that you took the time to split in multiple patches. Every change that needs to be committed to lldb needs to have a test associated. You may consider taking a look at the tests in `lit/` or the ones in `test/` and add tests for your changes. Don't hesitate to ask if you get stuck/have other questions. Thank you, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] lldb python API in Ubuntu
Hi All,
I am running lldb python API in Ubuntu 16.04 LTS. The debugger can launch
any process inside python; and I always got the following SBProcess state:
SBProcess: pid = 0, state =launching, threads = 0, executable = test
I ran the same python code in MacOS X, the process get launched
successfully. Do I need some special configuration on Ubuntu? I have
attached python code below:
import lldb
debugger = lldb.SBDebugger.Create()
debugger.SetAsync(False)
target = debugger.CreateTargetWithFileAndArch ("test",
lldb.LLDB_ARCH_DEFAULT)
target.BreakpointCreateByLocation("test.c", 12)
process = target.LaunchSimple (None, None, os.getcwd())
print process
Thanks,
Guolong
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] how do i submit my patch for 'Support demangling for D symbols via dlopen'
On Mon, Feb 26, 2018 at 9:01 PM, Timothee Cour via lldb-dev wrote: > https://github.com/llvm-mirror/lldb/pull/3 > > it would be *really* nice if llvm or lldb accepted industry standard > github PR's, at least as an option. Would make contributing so much > easier for outsiders See the other thread as well. https://llvm.org/docs/Phabricator.html Thanks, -- Davide ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
