Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

Our buildbot runs the test suite with a selection of compilers, one of which is clang ToT (test3, test4). You should get an email from it if anything breaks. pl On 20 October 2016 at 00:24, Eric Christopher via lldb-dev wrote: >

Re: [lldb-dev] Regenerating public API reference documentation

As nobody had any objection I committed in the regeneration of the docs as rL284725 For generating it automatically it would be great but as far as I know currently the LLDB docs and the LLVM docs are generated and distributed in a very different ways so it might be challenging to integrate (in ca

[lldb-dev] [Bug 30603] Python reference documentation is out of date

https://llvm.org/bugs/show_bug.cgi?id=30603 Tamas Berghammer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[lldb-dev] lldb tracepoint support

Hi, Is it in plan to support trace point commands in the near future, similar way as the gdb does? https://sourceware.org/gdb/onlinedocs/gdb/Set-Tracepoints.html#Set-Tracepoints Thanks, Andras National Instruments Romania S.R.L. -- B-dul 21 De

[lldb-dev] LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

Has LLDB considered adding per-binary support for LLDB python scripts, eg. for adding custom type summaries? This is the equivalent GDB feature https://sourceware.org/gdb/onlinedocs/gdb/dotdebug_005fgdb_005fscripts-section.html GDB can load a custom python script from either a side-installed file

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

Got it, thanks! On Thu, Oct 20, 2016, 2:26 AM Pavel Labath wrote: > Our buildbot < > http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake> > runs the test suite with a selection of compilers, one of which is > clang ToT (test3, test4). You should get an email from it if anything > br

Re: [lldb-dev] LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

We currently have the ability to support this for ELf. It is only currently hooked up for Mach-O binaries when you have a dSYM (stand alone debug info bundle). You will want to implement this for your platform: FileSpecList Platform::LocateExecutableScriptingResources(Target *target, Module &mod

Re: [lldb-dev] LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

LLDB has a similar feature, except: a) it tries to load python scripts from dSYM bundles. If you have debug info stored in foo.dSYM, it will look for foo.dSYM/Contents/Resources/Python/foo.py As far as I know, dSYMs only exist on Apple systems, so clearly you would need to design something else

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

I think a hardcoded value of 1 for maximum_operations_per_instruction will work like it does today – 1 linetable entry per Hexagon packet, which may have 1-4 instructions in it. Hexagon executes 1 packet at a time, so anywhere from 1-4 instructions at once. At O0, the compiler doesn’t packet

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

IIRC, the only reason the LLDB python test suite uses the in-tree compiler (Scenario 1) was so to test sanitizers before they were available in the system compiler. If that's the case, then using Xcode 8 on the builder will allow both the LLDB build and tests to use the system compiler. As I under

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

Building LLDB with cmake is already supported on all operating systems (including Darwin) for a while so that shouldn't be a blocker. On Thu, Oct 20, 2016 at 8:09 PM Tim Hammerquist via lldb-dev < lldb-dev@lists.llvm.org> wrote: > IIRC, the only reason the LLDB python test suite uses the in-tree

Re: [lldb-dev] llvm changing line table info from DWARF 2 to DWARF 4

> On Oct 20, 2016, at 1:00 PM, Tamas Berghammer via lldb-dev > wrote: > > Building LLDB with cmake is already supported on all operating systems > (including Darwin) for a while so that shouldn't be a blocker. While this is technically true, the LLDB test suite makes a lot of assumptions tha