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 d

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] [Reproducers] SBReproducer RFC

Thanks Pavel for looping me in. I haven't looked into the actual implementation of the prototype yet but reading your description I have some concern regarding the amount of data you capture as I feel it isn't sufficient to reproduce a set of usecases. One problem is when the behavior of LLDB is n

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 o

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] 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 Mon,

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 ste

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 -DLLVM_TARGETS_TO_BUI

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

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 more

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 gdbserver

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 ru

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

I seen a similar issue when trying to debug an application with a lot of shared libraries (1000+) and in that case the problem was that lldb-server was too slow to respond what caused a connection timeout in lldb. Increasing plugin.process.gdb-remote.packet-timeout fixed the problem for me but it w

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

If the process is restarted by lldb-server then "posix ptrace" should have some indication about it. Also "posix process" and "posix thread" can be useful to understand the bigger picture (all of them in lldb-server). Note: You can enable them by setting LLDB_SERVER_LOG_CHANNELS and LLDB_DEBUGSERV

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 your

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 effecte

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] 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 hav

Re: [lldb-dev] Debugging ELF relocatable files using LLDB

I uploaded a CL for review what fixes the crash you are experimenting at https://reviews.llvm.org/D30251 (we are mapping the files into memory as read only and then trying to write into it) but I think nobody tests LLDB with relocable object files so you might run into a lot of bugs in the way. Als

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] 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 bran

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

Hi Jason, I thought about this situation when implemented the original branch following code and haven't been able to come up with a really good solution. My only idea is the same what you mentioned. We should try to recognize all unconditional branches and returns (but not calls) and then if the

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

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 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 API reference documentation available a

[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] 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 '{t=length($0);su

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 featu

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

What type of binaries do you want to commit in? Generally we don't like putting binaries to the repository because they are not human readable so it is hard to review/diff them and they will only run on a single platform and a single architecture while we support a lot of different configuration.

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 < lld

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 On Fri, Apr 29, 2016 at

Re: [lldb-dev] Bug fixes for release_38 branch

Is there any reason you want to use the release_38 branch specifically? As far as I know nobody tested it or using it in the LLDB community so it is approximately as good as any random commit on master. If you are looking for a reasonably stable LLDB then I think you are better off with asking for

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 and

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 st

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

We try to keep all of our bugs in the public LLVM bug tracker (llvm.org/bugs) under OS=Linux so if you are looking for issues to work on that is a good place to start (the other option is to look for expectedFailures in the test suit). In general most of the issue we have are present on Linux and v

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: * On

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

files 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 wrote: > > On Feb 23, 2016, at 10:31 AM, Nico Weber wrote: > > > > On Tue, Feb 23, 2016 at 1:21 PM, Tamas Berghammer via lldb-dev < > lldb-dev@l

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 t

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 decision

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 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 n

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] 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 Turner

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 dec

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 t

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 spe

Re: [lldb-dev] How to load core on a different machine?

I would try to set target.exec-search-paths (before loading the core file) to the directory containing the binaries downloaded from the server. Then lldb should start searching for the shared libraries in the listed directories. On Wed, Jan 6, 2016 at 7:03 PM Eugene Birukov via lldb-dev < lldb-dev

Re: [lldb-dev] [Bug 25896] New: Hide stack frames from specific source files

We are not working on this feature for android at the moment and if we ever implement it we will most likely do it in the UI side (inside Android Studio) the same way Jason described in https://llvm.org/bugs/show_bug.cgi?id=25896#c1 On Sun, Dec 20, 2015 at 9:01 PM Todd Fiala via lldb-dev < lldb-de

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 Dec

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 specif

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 O

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

+Ying Chen Ying, what do we have to do on the build bot side to support a change in the default test result summary formatter? On Wed, Dec 9, 2015 at 4:00 PM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi all, > > Per a previous thread on this, I've made all the changes I intend

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 might have recompiled "liba.so", but >> not

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

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 Berghammer via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> I don't know how JIT debugging shou

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 it

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

In theory you don't have to do anything special to debug some JIT-ed code as everything should just work (based on the gdb jit interface). In practice I tried it out a few days ago and it wasn't working at all even in the case when the application is launched under LLDB (not with attach). LLDB was

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 < lldb-dev@lists.l

Re: [lldb-dev] Moving pexpect and unittest2 to lldb/third_party

Hi Zach, I think nobody is using the "if __name__ == '__main__'" block as executing a test file directly isn't working at the moment (the "import lldb" command fails). If you plan to change all test file then I would prefer to remove the reference to unittest2 from them for simplicity if nobody ha

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 chec

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 th

Re: [lldb-dev] Question on assert

Hi Todd, The 64 bit ID of a DIE is built up in the following way: * The offset of the DIE is in the lower 32 bit * If we are using SymbolFileDWARF then the higher 32 bit is the offset of the compile unit this DIE belongs to * If we are using SymbolFileDWARFDwo then the higher 32 bit is the offset

Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling

If we are trying to unwind from a non call site (frame 0 or signal handler) then the current implementation first try to use the non call site unwind plan (usually assembly emulation) and if that one fails then it will fall back to the call site unwind plan (eh_frame, compact unwind info, etc.) ins

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] 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 li

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

Yes, you are reading it correctly (for totclang we mean the totclang at the time when the test suit was run). The cmake builder runs in GCE and it uploads all test logs to Google Cloud Storage (including full host logs and server logs). I used a python script (running also in GCE) to download this

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] test results look typical?

In theory the test should be skipped when you are using gcc (cc is an alias for it) but we detect the type of the compiler based on the executable name and in case of cc we don't recognize that it is a gcc, so we don't skip the test. On Tue, Aug 25, 2015 at 5:45 PM Chaoren Lin via lldb-dev < lldb-

Re: [lldb-dev] test results look typical?

Hi Todd, I am using a clang-3.5 build release LLDB to debug an other clang-3.5 build debug LLDB on Linux x86_64 and it works pretty well for me (works better then using GDB). The most issue I am hitting is around expression evaluation when I can't execute very small functions in std:: objects, but

Re: [lldb-dev] test results look typical?

Going back to the original question I think you have more test failures then expected. As Chaoren mentioned all TestDataFormatterLibc* tests are failing because of a missing dependency, but I think the rest of the tests should pass (I wouldn't expect them to depend on libc++-dev). You can see the

Re: [lldb-dev] [RFC] Simplifying logging code

Thank you for the link to the previous discussion and the description of the Windows logging. I like the idea of the macro based logging on Windows but agree that the explicit log channel definition is a bit too verbose. Currently I would prefer a mixed solution with 'Log* log = ...; LOG_IF(log, "

Re: [lldb-dev] [RFC] Simplifying logging code

rmat, which is essentially the > exact same as we have now. > > Was there not a decision to stick with what we have now when this came up > a few weeks ago? Clean and easy to understand over verbose any day of the > week in my view. > > Colin > > > > On 12/08/2015 11:52, Tam

[lldb-dev] [RFC] Simplifying logging code

Hi All, At the moment logging in LLDB done in the following way: Log* log = GetLogIfAllCategoriesSet(...); if (log) log->Printf(...); This approach is clean and easy to understand but have the disadvantage of being a bit verbose. What is the general opinion about changing it to something like