Re: [lldb-dev] [BUG?] Confusion between translation units?

I seen very similar error messages when debugging an application compiled with fission (split/dwo) debug info on Linux with a release version of LLDB compiled from ToT. When I tested the same with a debug or with a release+assert build I hit some assertion inside clang. It might worth a try to

Re: [lldb-dev] Apple LLDB OS X build bot

Hi Todd, Thank you for setting up the new buildbot. I have a few questions about it: * Is it running the test suit or only do a build? * If the test suit is run then where can we see the result of the tests? Thanks, Tamas On Wed, Oct 28, 2015 at 2:03 PM Todd Fiala via lldb-dev <

Re: [lldb-dev] TestRaise.py test_restart_bug flakey stats

The expected flakey works a bit differently then you are described: * Run the tests * If it passes, it goes as a successful test and we are done * Run the test again * If it is passes the 2nd time then record it as expected failure (IMO expected falkey would be a better result, but we don't have

Re: [lldb-dev] Digging into Linux unexpected successes

Hi Todd, I attached the statistic of the last 100 test run on the Linux x86_64 builder (http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake). The data might be a little bit noisy because of the actual test failures happening because of a temporary regression, but they should give you

Re: [lldb-dev] Digging into Linux unexpected successes

Unfortunately the GCE logs aren't public at the moment and the amount of them isn't make it easy to make them accessible in any way (~30MB/build) and they aren't much more machine parsable then the stdout from the build. I think downloading data with the json API won't help because it will only

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

One more point to Zachary's comment is that currently if LLDB crashes for a test we report the test failure somewhat correctly (not perfectly). With a multi threaded approach I would expect an LLDB crash to take down the full test run what isn't something we want. On Tue, Sep 22, 2015 at 12:03 AM

Re: [lldb-dev] BasicResultsFormatter - new test results summary

Thank you for making the experiment. It looks reasonable. For the ERROR the buildbot detected it and it will fail the build but it isn't listed in the list of failing tests what should be fixed. After this experiment I think it is fine to change the default output formatter from our side. Tamas

Re: [lldb-dev] Passing as argument an array in a function call

I verified and LLDB also works correctly in case of arm and aarch64 on android (using lldb-server). My guess is that it is a MIPS specific but in the SysV ABI but I haven't verified it. Tamas On Wed, Dec 16, 2015 at 6:37 PM Greg Clayton via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > > On

Re: [lldb-dev] BasicResultsFormatter - new test results summary

HI Todd, You changed the way the test failure list is printed in a way that now we only print the name of the test function failing with the name of the test file in parenthesis. Can we add back the name of the test class to this list? There are 2 reason I am asking for it: * To run only a

Re: [lldb-dev] [BUG] Many lookup failures

On Tue, Dec 1, 2015 at 2:11 AM David Blaikie via lldb-dev < lldb-dev@lists.llvm.org> wrote: > On Mon, Nov 30, 2015 at 6:04 PM, Ramkumar Ramachandra > wrote: > >> On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton wrote: >> > When we debug "a.out" again, we

Re: [lldb-dev] reply: reply： lldb debug jit-compiled code with llvm on windows

t; "< > haifen...@foxmail.com>; "lldb-dev"<lldb-dev@lists.llvm.org>; > *Title:* Re: [lldb-dev] reply： lldb debug jit-compiled code with llvm on > windows > > Can you also try clang-cl and see if it works? > > On Fri, Nov 20, 2015 at 3:02 AM Tamas Bergha

Re: [lldb-dev] reply： lldb debug jit-compiled code with llvm on windows

I don't know how JIT debugging should work on WIndows with MSVC but I don't think LLDB support it in any way. What I wrote should be true on Linux (and on some related) systems. You might be able to get the same results on Windows if you use lli (LLVM based JIT runner) but I have no knowledge if

Re: [lldb-dev] Running a single test

Zachary's solution will work as well but that one won't make debugging the test too easy (still using several processes). If you want to run just 1 test then you have to specify --no-multiprocess and then you can use the same flags as before (-p, -f) On Tue, Feb 9, 2016 at 10:19 PM Zachary

Re: [lldb-dev] LLDB does some deep recursion into external modules to resolve name lookups

Hi Sean, Can you gave us some more context on this because without access to the referenced rdar bug I don't really understand your previous e-mail (and I think I am not alone with this) Thanks, Tamas On Wed, Feb 10, 2016 at 2:54 AM Sean Callanan via lldb-dev < lldb-dev@lists.llvm.org> wrote:

Re: [lldb-dev] MSVC 2013 w/ Python 2.7 is moving to an unsupported toolchain

Hi Zachary, We are still using MSVC 2013 and Python 2.7 to compile LLDB on Windows for Android Studio and we also have a buildbot what is testing this configuration (without sending e-mail at the moment) here: http://lab.llvm.org:8011/builders/lldb-windows7-android We are in the discussion to

Re: [lldb-dev] Inquiry for performance monitors

If you want to go with the path to implement it outside LLDB then I would suggest to implement it with an out of tree plugin written in C++. You can use the SB API the same way as you can from python and additionally it have a few advantages: * You have a C/C++ API what makes it easy to integrate

Re: [lldb-dev] Module Cache improvements - RFC

from the device but unfortunately its speed is only ~4-5MB/s on most device. On Tue, Feb 23, 2016 at 9:23 PM Greg Clayton <gclay...@apple.com> wrote: > > On Feb 23, 2016, at 10:31 AM, Nico Weber <tha...@chromium.org> wrote: > > > > On Tue, Feb 23, 2016 at 1:21 PM,

Re: [lldb-dev] Module Cache improvements - RFC

Yes we already have a disk cache on the host. I agree with you that waiting 30s at the first startup shouldn't be an issue in general (Pavel isn't sharing my opinion). The only catch is that in case of iOS there are only a few different builds released so if you downloaded the modules once then I

Re: [lldb-dev] Ubuntu version-based fail/skip

I think recently we are trying to reduce the number of decorators we are having so adding a few new Ubuntu specific decorators might not be a good idea. My suggestion would be to move on a little bit to the functional programming style with adding a new option to @expetedFailureAll where we can

Re: [lldb-dev] Interest in enabling -Werror by default

I would be happy if we can keep lldb warning free but I don't think enabling -Werror is a good idea for 2 reasons: * We are using a lot of different compiler and keeping the codebase warning free on all of them might not be feasible especially for the less used, older gcc versions. * Neither llvm

Re: [lldb-dev] Interest in enabling -Werror by default

If you want to enable it only on the bots then I think we can decide it on a bot by bot bases. For me the main question is who will be responsible for fixing a warning introduced by a change in llvm or clang causing a build failure because of a warning (especially when the fix is non trivial)? On

Re: [lldb-dev] Interest in enabling -Werror by default

I think the Linux-x86_64 build using clang is mostly warning free (1 warning on http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake) but it isn't true for most of the other configuration. I think -Werror can be enabled on the buildbots on a case by case bases depending on the

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

LLDB supports adding data formatters without modifying the source code and I would strongly prefer to go that way as we don't want each user of LLDB to start adding data formatters to their own custom types. We have a pretty detailed (but possible a bit outdated) description about how they work

Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb

As Pavel mentioned the unreasonable large size for lldb-server is caused by the fact that we are relying on the liker to remove the unused code and it can't do too good job because we have lot of unreasonable dependencies. The size difference between arm and arrahc64 caused by several reason: *

Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support

I think we don't. If we consider them stable enough for enabling them on a buildbot AND we agree to revert changes breaking the unittests then I am happy with enabling them (doing it should take very little effort from our side). Otherwise I would prefer to wait until we can get them to a stable

Re: [lldb-dev] All windows Mutex objects are recursive???

We already use both std::mutex and std::condition_variable in include/lldb/Utility/TaskPool.h for a while (since October) and nobody complained about it so I think we can safely assume that all platform has the necessary STL support. On Wed, May 11, 2016 at 11:44 PM Greg Clayton via lldb-dev <

Re: [lldb-dev] google/stable branch on git mirror?

+Eric Christopher Adding Eric as he was the last person merging changes to the google/stable branch. As far as I know nobody releases LLDB from that branch so I wouldn't rely on it too much (Android Studio release from master) but you can gave it a try if you want. Tamas

Re: [lldb-dev] Add support for OCaml native debugging

Can you upload your patches to http://reviews.llvm.org/differential/ as we do all code reviews in that system? Tamas On Fri, Jul 8, 2016 at 10:53 AM E BOUTALEB via lldb-dev < lldb-dev@lists.llvm.org> wrote: > To be frank, I do not like that either. I could add the test the DWARF > emission

Re: [lldb-dev] DWARF v5 unit headers

As far as I know the only dwarf v5 functionality currently implemented in LLDB is the split dwarf support so I don't expect it to work with the new dwarf v5 data but as long as clang emits dwarf v4 (or older) by default it shouldn't cause any immediate problem with the test suite (we will still

Re: [lldb-dev] LLDB Evolution

You can grep for " {$". With this regex I see no false positives and 272 case with 40 or more leading spaces On Sun, 28 Aug 2016, 17:59 Zachary Turner via lldb-dev, < lldb-dev@lists.llvm.org> wrote: > Here it is > > > grep -n '^ \+' . -r -o | awk

Re: [lldb-dev] A problem with the arm64 unwind plans I'm looking at

Based on your comments I have one more idea for a good heuristic. What if we detect a dynamic branch (e.g. "br ", "tbb ...", etc...) and store the register state for that place. Then when we find a block with no unwind info for the first instruction then we use the one we saved for the dynamic

[lldb-dev] Regenerating public API reference documentation

Hi All, The current LLDB API reference documentation available at http://lldb.llvm.org/python_reference/ and at http://lldb.llvm.org/cpp_reference/html/ but it haven't been updated since July 2013. I am planning to regenerate it next week using

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] Regenerating public API reference documentation

(in case of LLDB the HTML files are checked into the main lldb repository). Tamas On Fri, Oct 14, 2016 at 4:50 PM Mehdi Amini <mehdi.am...@apple.com> wrote: On Oct 14, 2016, at 6:44 AM, Tamas Berghammer via lldb-dev < lldb-dev@lists.llvm.org> wrote: Hi All, The current LLDB A

Re: [lldb-dev] LLDB failed to locate source when dwarf symbols are inside compile unit on Linux

Hi Jeffrey, For the source code locating issue based on your info my guess is that LLDB doesn't able to resolve the relative file name path specified in your symbol files to the absolute path required to load the file from disk. Can you try running "target modules dump line-table " where the file

Re: [lldb-dev] std::vector formatter question

The libstdc++ one is defined in examples/synthetic/gnu_libstdcpp.py while the libc++ one is defined in source/Plugins/Language/CPlusPlus/LibCxxVector.cpp and both of them is registered in source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp by specifying a type name regex to identify the

Re: [lldb-dev] C++ method declaration parsing

A random idea: Instead of parsing demangled C++ method names what people think about writing or reusing a demangler what can gave back both the demangled name and the parsed name in some form? My guess is that it would be both more efficient (we already have most of information during demangling)

Re: [lldb-dev] Linux issues where I am not getting breakpoints...

See https://bugs.llvm.org/show_bug.cgi?id=25806 for details about why we can't set breakpoint in the static initializer (it is an LLDB bug). For your investigation a few pointers/guesses (assuming it is not some stdout displaying issue what I consider unlikely based on your description): * Do

Re: [lldb-dev] Running check-lldb

AFAIK the Ubuntu 14.04 cmake builder runs tests using ToT clang (built on the build bot) as step test3 and test4 and it seems to be green so if you are seeing different result then I would expect it to be caused by a configuration difference between the setup the bot has and you have (or the bot

Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"

Few more addition to the above: How are you running lldb-server on your device? For remote debugging running lldb-server in platform mode (and then using remote-linux or similar as the selected platform in LLDB) will give you a significantly better performance over running lldb-server in

Re: [lldb-dev] Prologue instructions having line information

Hi Carlos, Thank your for looking into the LLDB failure. I looked into it briefly and the issue is that we have have 2 function f and g where g is inlined into f as the first call and this causes the first non-prologue line entry of f to be inside the address range of g what means that when we

Re: [lldb-dev] lldb-server link failure with shared library configuration

Hi Peeter, Why do you have to make the dependency conditional on BUILD_SHARED_LIBS? If lldbExpression depends on LLVMRuntimeDyld it should depend on it independently of the build config. Also I gave it a try to build lldb using shared libraries locally and I haven't hit any issue when I used the

Re: [lldb-dev] lldb-server link failure with shared library configuration

I tried to build using the following command what should be a reasonably close approximation to the one you used (I don't have ICU installed at the moment) and it still links fine for me: CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake -G Ninja ../../llvm -DBUILD_SHARED_LIBS=true

Re: [lldb-dev] lldb-server link failure with shared library configuration

Hi All, We are trying to keep the size of lldb-server as small as possible as it have to be copied over to the android device for every debug session. The way we currently achieve this is by using linker garbage collection to get rid of the unused code. In the log term it would be nice to be

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

Hi Anton and Jim, What do you think about storing the mangled type name or the mangled vtable symbol name somewhere in DWARF in the DW_AT_MIPS_linkage_name attribute? We are already doing it for the mangled names of functions so extending it to types shouldn't be too controversial. Tamas On

Re: [lldb-dev] Resolving dynamic type based on RTTI fails in case of type names inequality in DWARF and mangled symbols

Hi, I thought most compiler still emits DW_AT_MIPS_linkage_name instead of the standard DW_AT_linkage_name but I agree that if we can we should use the standard one. Regarding performance we have 2 different scenarios. On Apple platforms we have the apple accelerator tables to improve load time

Re: [lldb-dev] Anybody using the Go/Java debugger plugins?

Originally I added the Java support to work with the Android ART runtime and it has some pretty hard beaked in dependencies on the debug info ART generates and on the version of ART available at that time (Android N) even though I don't think this limitation is communicated clearly in source code

Re: [lldb-dev] LLDB bot health

+Pavel Labath Pavel and Me was owning the following bots: lldb-x86_64-ubuntu-14.04-buildserver: Builds lldb-server for various andoird architectures (doesn't run tests) lldb-x86_64-ubuntu-14.04-cmake : Runs lldb tests with 6 different compilers on Linux (clang-3.5, gcc-4.9.4, clang HEAD) *

Re: [lldb-dev] [RFC] Fast Conditional Breakpoints (FCB)

It is great that you are looking at supporting these fast breakpoints but I am concerned about the instruction moving code along the same lines Pavel mentioned. Copying instructions from 1 location to another is fairly complicated even without considering the issue of jump targets and jump target