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

[Tamas Berghammer via lldb-dev]

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 detection makes it even harder.

For reference, I implemented a similar system to do code shifting only
on prologue instructions using LLVM what you might find useful for
reference at 
https://github.com/google/gapid/tree/master/gapii/interceptor-lib/cc
(Apache v2 license) in case you decide to go down this path.

That system doesn't try to detect jump targets and only handles a
small subset of the instructions but I think shows the general
complexity. On X86_64 I think the number of instructions needs
rewriting are relatively small as most of them aren't PC relative but
for example on ARM where (almost) any instruction can take PC as a
register it will be a monumental task that is very hard to test (I
would expect AArch64 to be somewhere between X86_64 and ARM in terms
of complexity due to PC relative instructions but no general purpose
PC register).

In my view this discussion leads to the question of how we trade
performance for accuracy/reliability. We can easily gain a lot of
performance by being a bit sloppy and assume that we can safely insert
trampolines into the middle of the function but I would want my
debugger to "never lie" or crash my program.

Tamas

On Tue, Aug 20, 2019 at 8:46 AM Pavel Labath via lldb-dev
 wrote:
>
> On 20/08/2019 00:11, Ismail Bennani wrote:
> >> On Aug 19, 2019, at 2:30 PM, Frédéric Riss  wrote:
> >>
> >>
> >>
> >>> On Aug 16, 2019, at 11:13 AM, Ismail Bennani via lldb-dev 
> >>>  wrote:
> >>>
> >>> Hi Pavel,
> >>>
> >>> Thanks for all your feedbacks.
> >>>
> >>> I’ve been following the discussion closely and find your approach quite 
> >>> interesting.
> >>>
> >>> As Jim explained, I’m also trying to have a conditional breakpoint, that 
> >>> is able to stop a specific thread (name or id) when the condition 
> >>> expression evaluates to true.
> >>>
> >>> I feel like stacking up options with your approach would imply doing more 
> >>> context switches.
> >>> But it’s definitely a better fallback mechanism than the current one. 
> >>> I’ll try to make a prototype to see the performance difference for both 
> >>> approaches.
> >>>
> >>>
>  On Aug 15, 2019, at 10:10 AM, Pavel Labath  wrote:
> 
>  Hello Ismail, and wellcome to LLDB. You have a very interesting (and not 
>  entirely trivial) project, and I wish you the best of luck in your work. 
>  I think this will be a very useful addition to lldb.
> 
>  It sounds like you have researched the problem very well, and the 
>  overall direction looks good to me. However, I do have some ideas 
>  suggestions about possible tweaks/improvements that I would like to hear 
>  your thoughts on. Please find my comments inline.
> 
>  On 14/08/2019 22:52, Ismail Bennani via lldb-dev wrote:
> > Hi everyone,
> > I’m Ismail, a compiler engineer intern at Apple. As a part of my 
> > internship,
> > I'm adding Fast Conditional Breakpoints to LLDB, using code patching.
> > Currently, the expressions that power conditional breakpoints are 
> > lowered
> > to LLVM IR and LLDB knows how to interpret a subset of it. If that 
> > fails,
> > the debugger JIT-compiles the expression (compiled once, and re-run on 
> > each
> > breakpoint hit). In both cases LLDB must collect all program state used 
> > in
> > the condition and pass it to the expression.
> > The goal of my internship project is to make conditional breakpoints 
> > faster by:
> > 1. Compiling the expression ahead-of-time, when setting the breakpoint 
> > and
> >inject into the inferior memory only once.
> > 2. Re-route the inferior execution flow to run the expression and check 
> > whether
> >it needs to stop, in-process.
> > This saves the cost of having to do the context switch between debugger 
> > and
> > the inferior program (about 10 times) to compile and evaluate the 
> > condition.
> > This feature is described on the [LLDB Project 
> > page](https://lldb.llvm.org/status/projects.html#use-the-jit-to-speed-up-conditional-breakpoint-evaluation).
> > The goal would be to have it working for most languages and 
> > architectures
> > supported by LLDB, however my original implementation will be for 
> > C-based
> > languages targeting x86_64. It will be extended to AArch64 afterwards.
> > Note the way my prototype is implemented makes it fully extensible for 
> > other
> > languages and architectures.
> > ## High Level Design
> > Every time a breakpoint that holds a condition is hit, multiple context
> > switches are needed in order to compile and evaluate the condition.
> > 

Re: [lldb-dev] LLDB bot health

[Tamas Berghammer via lldb-dev]

+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) * (i386, x86_64)
lldb-x86_64-darwin-13.4 : Building lldb on darwin using
cmake+ninja and running remote debugging tests for android (AFAIK devices
have been removed since)
lldb-windows7-android   : Building lldb for windows using
cmake+ninja and running remote debugging tests for android (using an i386
andoird emulator)
lldb-x86_64-ubuntu-14.04-android: Building lldb for linu and running
remote debugging tests for android (AFAIK devices have been removed since)

My opinion is that we should leave lldb-x86_64-ubuntu-14.04-buildserver on
as it provides at least build coverage for android and it is very stable
and easy to fix when it breaks. If people have interest maintaining Linux
support (I hope they do) then having lldb-x86_64-ubuntu-14.04-cmake on and
green could be useful and I can help out with general bot maintenance but
won't have bandwidth to actually look into test failures. For the rest of
the bots I would propose to just turn them on unless somebody from
Google/Android steps forward to maintain them as they occasionally require
physical access and at the moment they are located in a lab in the Google
MTV office. Will send an e-mail to a few interested parties to check if
there is any takers.

Cheers,
Tamas

On Fri, Jan 11, 2019 at 11:18 PM Stella Stamenova via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> If you look at the bot online, there's usually an admin listed. For
> example:
>
> http://lab.llvm.org:8011/buildslaves
>
> I've CC'd the admins of the bots from Paul's list that are failing.
>
> Thanks,
> -Stella
>
> -Original Message-
> From: Davide Italiano 
> Sent: Friday, January 11, 2019 3:12 PM
> To: Stella Stamenova 
> Cc: Robinson, Paul ; Pavel Labath ;
> Zachary Turner ; LLDB 
> Subject: Re: [lldb-dev] LLDB bot health
>
> On Fri, Jan 11, 2019 at 3:07 PM Stella Stamenova 
> wrote:
> >
> > Thanks Davide,
> >
> > I think several of these bots have not been maintained for a while. One
> thing we could do is try to ping the owners and see if it's possible to
> update the bots or if they're no longer useful, then remove them.
> >
>
> I agree. I don't know who owns these bots, is there an easy way to find?
> (or just cc: them to these e-mail).
> We can then ask Galina to just remove the bots if nobody maintains them.
>
> Thanks,
>
> --
> 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

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

[Tamas Berghammer via lldb-dev]

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
or in code reviews. Considering that AFAIK it haven't been tested with
Android O and haven't seen any bugfix for a while I would assume it is
mostly unused so I am happy to get it removed. And as Pavel said if
somebody want to use it again we can always add it back in with a better
testing strategy and long term plan.

Generally for new language support I think we should have a similar policy
then what LLVM have for new backends. They should be developed out of tree
first without us providing a stable API (developer can fork a specific
version of LLDB, preferably upstream language independent bugfixes and then
pull in new changes once in a while) and if they are mature enough both in
terms of testing and maintenance commitment then they can be pulled into
the main LLDB source tree.

Tamas

On Tue, Jan 30, 2018 at 11:52 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Right, so, independently of this thread here, we've had an internal
> discussion about reviving java support. However, it is still very
> uncertain that this will actually happen , so I'm not opposed to
> removing it as we can always add it back later (with better testing,
> hopefully).
>
> Regardless of what happens here (and in light of the rust thread), I
> think a clearer bar for what we expect from new language support
> plugin would be useful for everyone.
>
> pl
>
> On 22 January 2018 at 20:13, Jim Ingham  wrote:
> > 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 <
> lldb-dev@lists.llvm.org> 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, 

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

[Tamas Berghammer via lldb-dev]

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 (might work on
FreeBsd as well) while on other platforms we Index the DWARF data
(DWARFCompileUnit::Index) to effectively generate accelerator tables in
memory what is a faster process then fully parsing the DWARF (currently we
only parse function DIEs and we don't build the clang types). I think an
ideal solution would be to have the vtable name stored in DWARF so the
DWARF data is standalone and then have some accelerator tables to be able
to do fast lookup from mangled symbol name to DIE offset. I am not too
familiar with the apple accelerator tables but if we have anything what
maps from mangled name to DIE offset then we can add a few entry to it to
map from mangled vtable name to type DIE or vtable DIE.

Tamas

On Mon, Dec 18, 2017 at 9:02 PM xgsa  wrote:

> Hi Tamas,
>
> First, why DW_AT_MIPS_linkage_name, but not just DW_AT_linkage_name? The
> later is standartized and currently generated by clang at least on x64.
>
> Second, this doesn't help to solve the issue, because this will require
> parsing all the DWARF types during startup to build a map that breaks DWARF
> lazy load, performed by lldb. Or am I missing something?
>
> Thanks,
> Anton.
>
> 18.12.2017, 22:59, "Tamas Berghammer" :
>
> 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, 18 Dec 2017, 17:29 xgsa via lldb-dev, 
> wrote:
>
> Thank you for clarification, Jim, you are right, I misunderstood a little
> bit what lldb actually does.
>
> It is not that the compiler can't be fixed, it's about the fact that
> relying on correspondence of mangled and demangled forms are not reliable
> enough, so we are looking for more robust alternatives. Moreover, I am not
> sure that such fuzzy matching could be done just basing on class name, so
> it will require reading more DIEs. Taking into account that, for instance,
> in our project there are quite many such types, it could noticeable slow
> down the debugger.
>
> Thus, I'd like to mention one more alternative and get your feedback, if
> possible. Actually, what is necessary is the correspondence of mangled and
> demangled vtable symbol. Possibly, it worth preparing a separate section
> during compilation (like e.g. apple_types), which would store this
> correspondence? It will work fast and be more reliable than the current
> approach, but certainly, will increase debug info size (however, cannot
> estimate which exact increase will be, e.g. in persent).
>
> What do you think? Which solution is preferable?
>
> Thanks,
> Anton.
>
> 15.12.2017, 23:34, "Jim Ingham" :
> > First off, just a technical point. lldb doesn't use RTTI to find dynamic
> types, and in fact works for projects like lldb & clang that turn off RTTI.
> It just uses the fact that the vtable symbol for an object demangles to:
> >
> > vtable for CLASSNAME
> >
> > That's not terribly important, but I just wanted to make sure people
> didn't think lldb was doing something fancy with RTTI... Note, gdb does (or
> at least used to do) dynamic detection the same way.
> >
> > If the compiler can't be fixed, then it seems like your solution [2] is
> what we'll have to try.
> >
> > As it works now, we get the CLASSNAME from the vtable symbol and look it
> up in the the list of types. That is pretty quick because the type names
> are indexed, so we can find it with a quick search in the index. Changing
> this over to a method where we do some additional string matching rather
> than just using the table's hashing is going to be a fair bit slower
> because you have to run over EVERY type name. But this might not be that
> bad. You would first look it up by exact CLASSNAME and only fall back on
> your fuzzy match if this fails, so most dynamic type lookups won't see any
> slowdown. And if you know the cases where you get into this problem you can
> probably further restrict when you need to do this work so you don't suffer
> this penalty for every lookup where we don't have debug info for the
> dynamic type. And you could keep a side-table of mangled-name -> DWARF
> name, and maybe a black-list for unfound names, so you only have to do this
> once.
> >
> > This estimation is based on the assumption that you can do your work
> just on the type names, without having to get more type information out of
> the DWARF for each candidate match. A solution that relies on realizing
> every class in lldb so you can get 

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

[Tamas Berghammer via lldb-dev]

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, 18 Dec 2017, 17:29 xgsa via lldb-dev, 
wrote:

> Thank you for clarification, Jim, you are right, I misunderstood a little
> bit what lldb actually does.
>
> It is not that the compiler can't be fixed, it's about the fact that
> relying on correspondence of mangled and demangled forms are not reliable
> enough, so we are looking for more robust alternatives. Moreover, I am not
> sure that such fuzzy matching could be done just basing on class name, so
> it will require reading more DIEs. Taking into account that, for instance,
> in our project there are quite many such types, it could noticeable slow
> down the debugger.
>
> Thus, I'd like to mention one more alternative and get your feedback, if
> possible. Actually, what is necessary is the correspondence of mangled and
> demangled vtable symbol. Possibly, it worth preparing a separate section
> during compilation (like e.g. apple_types), which would store this
> correspondence? It will work fast and be more reliable than the current
> approach, but certainly, will increase debug info size (however, cannot
> estimate which exact increase will be, e.g. in persent).
>
> What do you think? Which solution is preferable?
>
> Thanks,
> Anton.
>
> 15.12.2017, 23:34, "Jim Ingham" :
> > First off, just a technical point. lldb doesn't use RTTI to find dynamic
> types, and in fact works for projects like lldb & clang that turn off RTTI.
> It just uses the fact that the vtable symbol for an object demangles to:
> >
> > vtable for CLASSNAME
> >
> > That's not terribly important, but I just wanted to make sure people
> didn't think lldb was doing something fancy with RTTI... Note, gdb does (or
> at least used to do) dynamic detection the same way.
> >
> > If the compiler can't be fixed, then it seems like your solution [2] is
> what we'll have to try.
> >
> > As it works now, we get the CLASSNAME from the vtable symbol and look it
> up in the the list of types. That is pretty quick because the type names
> are indexed, so we can find it with a quick search in the index. Changing
> this over to a method where we do some additional string matching rather
> than just using the table's hashing is going to be a fair bit slower
> because you have to run over EVERY type name. But this might not be that
> bad. You would first look it up by exact CLASSNAME and only fall back on
> your fuzzy match if this fails, so most dynamic type lookups won't see any
> slowdown. And if you know the cases where you get into this problem you can
> probably further restrict when you need to do this work so you don't suffer
> this penalty for every lookup where we don't have debug info for the
> dynamic type. And you could keep a side-table of mangled-name -> DWARF
> name, and maybe a black-list for unfound names, so you only have to do this
> once.
> >
> > This estimation is based on the assumption that you can do your work
> just on the type names, without having to get more type information out of
> the DWARF for each candidate match. A solution that relies on realizing
> every class in lldb so you can get more information out of the type
> information to help with the match will defeat all our attempts at lazy
> DWARF reading. This can cause quite long delays in big programs. So I would
> be much more worried about a solution that requires this kind of work.
> Again, if you can reject most potential candidates by looking at the name,
> and only have to realize a few likely types, the approach might not be that
> slow.
> >
> > Jim
> >
> >>  On Dec 15, 2017, at 7:11 AM, xgsa via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >>  Sorry, I probably shouldn't have used HTML for that message. Converted
> to plain text.
> >>
> >>   Original message 
> >>  15.12.2017, 18:01, "xgsa" :
> >>
> >>  Hi,
> >>
> >>  I am working on issue that in C++ program for some complex cases with
> templates showing dynamic type based on RTTI in lldb doesn't work properly.
> Consider the following example:
> >>  enum class TagType : bool
> >>  {
> >> Tag1
> >>  };
> >>
> >>  struct I
> >>  {
> >> virtual ~I() = default;
> >>  };
> >>
> >>  template 
> >>  struct Impl : public I
> >>  {
> >>  private:
> >> int v = 123;
> >>  };
> >>
> >>  int main(int argc, const char * argv[]) {
> >> Impl impl;
> >> I& i = impl;
> >> return 0;
> >>  }
> >>
> >>  For this example clang generates type name "Impl" in
> DWARF and "__ZTS4ImplIL7TagType0EE" when mangling symbols (which lldb
> demangles to Impl<(TagType)0>). Thus when in
> ItaniumABILanguageRuntime::GetTypeInfoFromVTableAddress() lldb tries to
> resolve the type, it is unable 

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

[Tamas Berghammer via lldb-dev]

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 step info f from
outside we will end up inside g instead. Previously the first line entry
for f matched with the start address of the inlined copy of g where LLDB
was able to handle the stepping properly.

For the concrete example you should compile
https://github.com/llvm-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/packages/Python/lldbsuite/test/functionalities/inline-stepping/calling.cpp
with
"/mnt/ssd/ll/git/build/host-release/bin/clang-5.0 -std=c++11 -g -O0
-fno-builtin -m32 --driver-mode=g++ calling.cpp" and then observe
that caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the
inlined inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the
first line entry after "Set prologue_end to true" is at 0x8048796 while
previously it was at 0x8048793.

Tamas

On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> I have been working on a compiler issue, where instructions associated to
> the function prolog are assigned line information, causing the debugger to
> show incorrectly the beginning of the function body.
>
> For a full description, please see:
>
> https://reviews.llvm.org/D37625
> https://reviews.llvm.org/rL313047
>
> The submitted patch caused some LLDB tests to fail. I have attached the
> log failure.
>
> I have no knowledge about the test framework used by LLDB.
>
> What is the best way to proceed in this case?
>
> Thanks very much for your feedback.
>
> Carlos Enciso
>
>
>
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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_BUILD='X86'
-DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=TRUE
-DLLVM_OPTIMIZED_TABLEGEN=ON

It would be great to understand what exactly causes the difference between
the 2 cases by some sort of bisecting as I see nothing in the source code
what would explain this. If changing from -DCMAKE_BUILD_TYPE=Debug to
-DCMAKE_BUILD_TYPE=Release
fixes the issue then it would be nice to diff the ninja build graph and the
different cmake caches to try to figure out where the different starts.

Tamas

On Wed, Aug 30, 2017 at 12:17 PM Peeter Joot 
wrote:

> Hi Tamas,
>
> It looks like lldb-server only fails if I build with a Debug
> configuration, which I didn't realize until now.  In Release configuration,
> I don't need any changes to CMakefiles and lldb-server links without
> error.  My full build configuration in debug mode was:
>
> mkdir lldb50.1708110153
>
> cd lldb50.1708110153
>
> PATH=$PATH:/opt/lzlabs/bin
>
> CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake \
>
> -G \
>
> Ninja \
>
> ../llvm \
>
> -DBUILD_SHARED_LIBS=true \
>
> -DLLVM_TARGETS_TO_BUILD='X86' \
>
> -DCMAKE_BUILD_TYPE=Debug \
>
> -DLLVM_ENABLE_ASSERTIONS=TRUE \
>
> -DCMAKE_INSTALL_PREFIX=/home/pjoot/clang/lldb50.1708110153 \
>
> -DLLVM_OPTIMIZED_TABLEGEN=ON \
>
> -DICU_LIBRARY=/opt/lzlabs/lib64 \
>
> -DICU_INCLUDE_DIR=/opt/lzlabs/include
> Without any changes LLVMRuntimeDyld is not in the lldb-server link list,
> so this is not an ordering issue.  I'm not sure why this ends up as an
> issue only with Debug.
>
> --
> Peeter
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 following command (on Ubuntu
14.04): cmake ../../llvm -G Ninja -DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release
-DBUILD_SHARED_LIBS=true

Are you using some other cmake flags as well? Also can you check the link
command used for the final linking step if it contains LLVMRuntimeDyld
without your change? Can it be just a library ordering issue where some
symbols are dropped before they are used?

Cheers,
Tamas

On Wed, Aug 30, 2017 at 12:50 AM Peeter Joot 
wrote:

> Hi Tamas,
>
> I was able to use your suggestion as follows:
>
> diff --git a/source/Expression/CMakeLists.txt
> b/source/Expression/CMakeLists.txt
>
> index 7d9643a..b53b095 100644
>
> --- a/source/Expression/CMakeLists.txt
>
> +++ b/source/Expression/CMakeLists.txt
>
> @@ -2,6 +2,12 @@ if(NOT LLDB_BUILT_STANDALONE)
>
>set(tablegen_deps intrinsics_gen)
>
>  endif()
>
>
> +set(LLDB_EXP_DEPS)
>
> +
>
> +if(BUILD_SHARED_LIBS)
>
> +  list(APPEND LLDB_EXP_DEPS LLVMRuntimeDyld)
>
> +endif()
>
> +
>
>  add_lldb_library(lldbExpression
>
>DiagnosticManager.cpp
>
>DWARFExpression.cpp
>
> @@ -30,6 +36,7 @@ add_lldb_library(lldbExpression
>
>  lldbTarget
>
>  lldbUtility
>
>  lldbPluginExpressionParserClang
>
> +${LLDB_EXP_DEPS}
>
>
>LINK_COMPONENTS
>
>  Core
>
> and was able to successfully build the lldb-server.
>
> --
> Peeter
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 explicit about the list of
dependencies but currently we don't have clear enough boundaries for doing
that. Pavel and Zachary spent some time on improving it but I think we are
still quite far from that.

For your problem I think a better short term option would be to add
LLVMRuntimeDyld as a dependency for lldbExpression instead of lldb-server
directly (assuming it works). Optionally if you are feeling more
adventurous you can try to replace ${LLDB_PLUGINS} and ${LLDB_SYSTEM_LIBS}
with a more explicit list of dependencies what might remove the dependency
between lldb-server and LLVMRuntimeDyld but I am not certain.

Tamas

On Mon, Aug 28, 2017 at 6:00 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> If we are pulling in the expression parser, that would explain our issues.
> If this currently happens in lldb-server we need to add LLVMRuntimeDyld to
> the link libraries. I know some people at Google have looked into getting
> lldb-server to link against as little as possible, and maybe this is just
> how things are for the time being. We should verify that. It would be nice
> if lldb-server didn't link against the expression parser if possible.
>
> Greg
>
> On Aug 28, 2017, at 9:56 AM, Peeter Joot 
> wrote:
>
> Hi Greg,
>
> IRExecutionUnit.cpp looks like the origin of at least some of the
> undefined symbols:
>
> .../llvm/include/llvm/ExecutionEngine/RTDyldMemoryManager.h:61: undefined
> reference to `vtable for llvm::RTDyldMemoryManager'
>
>
> .../llvm/include/llvm/ExecutionEngine/JITSymbol.h:223: undefined reference
> to `vtable for llvm::JITSymbolResolver'
>
>
> .../llvm/include/llvm/ExecutionEngine/RuntimeDyld.h:96: undefined
> reference to `vtable for llvm::RuntimeDyld::MemoryManager'
>
>
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x90):
> undefined reference to `llvm::RTDyldMemoryManager::deregisterEHFrames()'
>
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0xa8):
> undefined reference to `llvm::RuntimeDyld::MemoryManager::anchor()'
>
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro+0x118):
> undefined reference to `llvm::JITSymbolResolver::anchor()'
>
> lib/liblldbExpression.a(IRExecutionUnit.cpp.o):(.data.rel.ro._ZTVN4llvm18MCJITMemoryManagerE[_ZTVN4llvm18MCJITMemoryManagerE]+0x60):
> undefined reference to `llvm::RuntimeDyld:
>
> :MemoryManager::anchor()'
>
> there are a couple of undefined vtable references in headers (also above),
> but it's not clear to me if these also neccessarily come from
> IRExectionUnix.cpp.
>
> --
> Peeter
>
>
>
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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 mode only and then
selecting remote-gdbserver as your platform in LLDB. The following things
*only apply* to the case when you are running lldb-server in platform mode.

If the target side libraries are backed by files on the target system then
LLDB should download them only once (at first usage) and then cache it on
the host in a module cache (even between LLDB or machine restarts). It
means that the startup time is expected to be quite high the first time you
debug on a specific device but it should be much faster afterwards (as you
already have the libraries on the host). If this is not the case it would
be interesting to see why module cache isn't working for you.

By default LLDB uses the gdb-remote protocol to download the files from the
target device what is known to be very very slow for transferring large
amount of data in bulk. For Android we implemented a faster way to download
the files using ADB what gave us a large performance gain (multiple times
faster, but don't remember exact number). You can see the code at
https://github.com/llvm-mirror/lldb/blob/a4df8399803ba766d05ef7fcd5d04dc0342d2682/source/Plugins/Platform/Android/PlatformAndroid.cpp#L190
I
expect that you can achieve similar gains if you implement
Platform*::GetFile and Platform*::PutFile for your platform based on a
faster method (e.g. scp/rsync)

Tamas

On Tue, May 23, 2017 at 12:23 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> To expand on Jim's message, "target modules search-paths add" can be used
> to help lldb find  the host-side copies of shared libraries when they're
> not in the same directory as on the target system.
>
> For example, if you have libraries in /usr/lib on the target system, and
> have copies on the host system in /local/scratch/work/debuglibs , you can
> say
> target modules search-paths add /usr/lib /local/scratch/work/debuglibs
> and when lldb goes to load (for example) /usr/lib/libc.so, it will try to
> load /local/scratch/work/debuglibs/libc.so from the host machine before
> trying to load through the memory interface.
>
> I found this very helpful when trying to debug dynamic executables on
> Linux running on a Hexagon board, running lldb on x86 Linux or Windows.
>
> Ted
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
> > -Original Message-
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim
> > Ingham via lldb-dev
> > Sent: Monday, May 22, 2017 5:02 PM
> > To: Chunseok Lee 
> > Cc: lldb-dev 
> > Subject: Re: [lldb-dev] lldb command like gdb's "set auto-solib-add off"
> >
> > In general, if lldb can find host-side copies of binaries that match the
> ones it
> > finds on the device, it will do all symbol reading against the host
> copies.  In
> > the case of an OS X host debugging iOS, lldb uses Spotlight and a few
> other
> > tricks to find the host-side binaries.  You can also use
> "add-symbol-file" to
> > manually point lldb at the host-side symbol files.  If you are reading
> symbols
> > from host-side files, then symbol loading doesn't slow down debugging
> > startup that much.
> >
> > Presumably, your symbol files are only on the device, so you are reading
> > them from memory.  "settings set target.memory-module-load-level" is
> > almost what you want, but it applies to ALL shared libraries read from
> > memory.  If you can copy the symbol file that contains the
> > __jit_debug_register_code to the host you are debugging from, and use
> > add-symbol-file to tell lldb about it, then that one should NOT have to
> be
> > read from memory anymore.  Then you could turn "memory-module-load-
> > level" to partial or even mininal, and that should get you starting
> faster.
> >
> > The other option would be to extend the setting, so you can say:
> >
> > set set target.memory-module-load-level [[lib-name level] [lib-name
> level]
> > ...]
> >
> > If there's just one argument, that's equivalent to "all ".
> >
> > Jim
> >
> > > On May 22, 2017, at 2:35 PM, Chunseok Lee 
> > wrote:
> > >
> > >
> > >
> > > Thank you for your help.
> > > It would be really helpful to me.
> > >
> > > The reason behind the question is exactly what you mentioned. I am
> > > wokring on debugging in devices and it seems that shared library
> loading(I
> > do not know lldb loads symbols lazyly) runs very slowly since my testing
> > program depends on so many shared libs.  since I am debuggging with
> gdbjit
> > feature, I do not need shared library loading except one shared lib(which
> > contains 

Re: [lldb-dev] Running check-lldb

[Tamas Berghammer via lldb-dev]

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 runs the tests incorrectly).

On Thu, Apr 20, 2017 at 2:47 PM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On 19 April 2017 at 19:15, Scott Smith 
> wrote:
>
>> A combination of:
>> 1. Updating to a known good release according to buildbot
>> 2. using Ubuntu 14.04
>> 3. compiling release using clang-4.0
>>
> I'd hope that the compiler used to build lldb does not matter. If you see
> any differences due to this factor, please let me know.
>
> 4. using the dotest command line that buildbot uses
>>
> The exact command line the buildbot uses is not important.. The only
> important distinction from the check-lldb target is the compiler used. By
> default it uses the host compiler used to build lldb. As no-one builds
> tests using clang-4.0 it's quite possible that some things may be broken
> (or just not properly annotated).
>
>
>> 5. specifying gcc-4.8 instead of the locally compiled clang
>>
>> has most of the tests passing, with a handful of unexpected successes:
>>
>> UNEXPECTED SUCCESS:
>> TestRegisterVariables.RegisterVariableTestCase.test_and_run_command_dwarf
>> (lang/c/register_variables/TestRegisterVariables.py)
>> UNEXPECTED SUCCESS:
>> TestRegisterVariables.RegisterVariableTestCase.test_and_run_command_dwo
>> (lang/c/register_variables/TestRegisterVariables.py)
>> UNEXPECTED SUCCESS:
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS:
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS:
>> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwarf
>> (functionalities/thread/state/TestThreadStates.py)
>> UNEXPECTED SUCCESS:
>> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwo
>> (functionalities/thread/state/TestThreadStates.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS:
>> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwarf
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS:
>> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwo
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf
>> (lang/cpp/printf/TestPrintf.py)
>> UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwo
>> (lang/cpp/printf/TestPrintf.py)
>>
> The unexpected successes are expected, unfortunately. :) What happens here
> is that the tests are flaky and they fail like 1% of the time, so they are
> marked as xfail.
>
>
>>
>> This looks different than another user's issue:
>> http://lists.llvm.org/pipermail/lldb-dev/2016-February/009504.html
>>
>> I also tried gcc-4.9.4 (via the ubuntu-toolchain-r ppa) and got a
>> different set of problems:
>>
>> FAIL:
>> TestNamespaceDefinitions.NamespaceDefinitionsTestCase.test_expr_dwarf
>> (lang/cpp/namespace_definitions/TestNamespaceDefinitions.py)
>> FAIL: TestNamespaceDefinitions.NamespaceDefinitionsTestCase.test_expr_dwo
>> (lang/cpp/namespace_definitions/TestNamespaceDefinitions.py)
>> FAIL:
>> TestTopLevelExprs.TopLevelExpressionsTestCase.test_top_level_expressions_dwarf
>> (expression_command/top-level/TestTopLevelExprs.py)
>> FAIL:
>> TestTopLevelExprs.TopLevelExpressionsTestCase.test_top_level_expressions_dwo
>> (expression_command/top-level/TestTopLevelExprs.py)
>> UNEXPECTED SUCCESS:
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS:
>> TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo
>> (functionalities/thread/exit_during_break/TestExitDuringBreak.py)
>> UNEXPECTED SUCCESS:
>> TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwarf
>> (functionalities/thread/state/TestThreadStates.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo
>> (functionalities/signal/raise/TestRaise.py)
>> UNEXPECTED SUCCESS:
>> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwarf
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS:
>> TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwo
>> (api/multithreaded/TestMultithreaded.py)
>> UNEXPECTED SUCCESS: 

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

[Tamas Berghammer via lldb-dev]

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 application calls dlopen? It can explain why you see stdout
before some library load events and also I can imagine more issue in that
code path.
* Are you sure LoadModuleAtAddress called from LoadAllCurrentModules in all
4 cases? It can be called from RefreshModules as well what is used when we
get notified about a new library and I expect it to be more likely based on
the output (for the second 2 line).
* I suggest to stop at libc.so'_start and see what libraries are loaded
there (I expect it to be after the first 2 log and before the stdout).
Verify that both shared-library-event breakpoint is resolved at this time
(by "breakpoint list -i") and also set a manual breakpoint there to see
when it triggers. I expect you will hit that breakpoint just after your log
lines are displayed. If that is the case you should get a stacktrace and
see the callstack causing the event to be triggered.
* The libraries you should look out in the log is libc.so and
ld-linux-x86-64.so
(or similar). The dynamic loader integration should work only after these 2
libraries are loaded.

On Tue, Apr 11, 2017 at 3:56 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On Apr 11, 2017, at 5:33 AM, Pavel Labath  wrote:
>
> Are you sure this is not just an artifact of stdio buffering? I tried the
> same experiment, but I placed a real log statement, and I could see that
> all the LoadModuleAtAddress calls happen between the $T and $c packets in
> the gdb-remote packet sequence.
>
> The module loading should be synchronous, so I think the problem lies
> elsewhere.
>
> What is the nature of the breakpoint that is not getting hit? Can you
> provide a repro case? The only bug like this that I am aware of is that we
> fail to hit breakpoints in global constructors in shared libraries, but
> that hasn't worked even in 3.8..
>
>
> I unfortunately can't attach a repro case. I will be able to track this
> down, just need some pointers. I did notice that I wasn't able to hit
> breakpoints in global constructors though... Do we know why? On Mac, we get
> notified of shared libraries as they load so we never miss anything. Why
> are we not able to get the same thing with linux?
>
>
>
> On 10 April 2017 at 22:51, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I have added some logging to a program that is not hitting breakpoints
> with LLDB top of tree SVN. An older lldb 3.8 hits the breakpoint just fine.
> I placed some logging in LLDB:
>
> ModuleSP DynamicLoader::LoadModuleAtAddress(const FileSpec ,
> addr_t link_map_addr,
> addr_t base_addr,
> bool base_addr_is_offset) {
>   printf("%s: lma = 0x%16.16llx, ba = 0x%16.16llx, baio = %i\n",
> file.GetPath().c_str(), link_map_addr, base_addr, base_addr_is_offset);
>
>
> This is called by DynamicLoaderPOSIXDYLD::LoadAllCurrentModules().
>
> My problem is I see:
>
> [vdso]: lma = 0x, ba = 0x77ffa000, baio = 0
> linux-vdso.so.1: lma = 0x77ffe6e0, ba = 0x77ffa000, baio =
> 1
> /tmp/liba.so: lma = 0x77ff66a8, ba = 0x77e3, baio = 1
> 8 locations added to breakpoint 1
> /tmp/libb.so: lma = 0x77e2f000, ba = 0x77d43000, baio = 1
> [==] Running 14 tests from 1 test case.
> [--] Global test environment set-up.
> [--] 14 tests from MyTest
> [ RUN  ] MyTest.Test1
> [   OK ] MyTest.Test1 (0 ms)
> /tmp/libc.so: lma = 0x77e2f000, ba = 0x77d43000, baio = 1
> /tmp/libd.so: lma = 0x77e2f000, ba = 0x77d43000, baio = 1
>
>
> Note that I see program output _during_ the messages that are showing that
> shared libraries are being loaded? I would assume we are loading shared
> libraries synchronously, but the log seems to indicated otherwise.
>
> If anyone knows anything on this subject please let me know...
>
> Greg Clayton
> ___
> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 effected types. If you have a
custom STL or any other costume type I suggest you to write a synthetic
child provider in Python (see https://lldb.llvm.org/varformats.html) as it
can be loaded at runtime so you don't have to fork LLDB.

Tamas

On Fri, Mar 24, 2017 at 4:30 PM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On standalone Hexagon (no OS support), we use Dinkumware for the c/c++
> library. LLDB isn't able to print out values of a vector:
>
> Process 1 stopped
> * thread #1: tid = 0x0001, 0x519c vector.elf`main + 76 at
> vector.cpp:10,
> stop reason = step in
> frame #0: 0x519c vector.elf`main + 76 at vector.c:10
>7vector v;
>8v.push_back(2);
>9v.push_back(1);
> -> 10   cout << v[0] << " " << v[1] << endl;
>11   return 0;
>12   }
>  (lldb) fr v v
> (std::vector) v = size=0 {}
>
> When I run on x86 linux built with gcc, I get:
> (lldb) fr v v
> (std::vector) v = size=2 {
>   [0] = 2
>   [1] = 1
> }
>
>
> My guess is Dinkumware's vector type is just a little bit different from
> libstdc++/libcxx, so the standard formatters don't do the right thing.
> Where
> are the vector formatters defined, and how does LLDB determine which
> one to use?
>
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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) and possibly easier to implement as I expect
less edge cases. Additionally I think it would be a nice library to have as
part of the LLVM project.

Tamas

On Thu, Mar 16, 2017 at 2:43 AM Eugene Zemtsov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Yes, it's a good idea to add cfe-dev.
> It is totally possible that I overlooked something and clang can help with
> this kind of superficial parsing.
>
> As far as I can see even clang-format does it's own parsing
> (UnwrappedLineParser.cpp) and clang-format has very similar need of roughly
> understanding of code without knowing any context.
>
> > are you certain that clang's parser would be unacceptably slow?
>
> I don't have any perf numbers to back it up, but it does look like a lot
> of clang infrastructure needs to be set up before actual parsing begins.
> (see lldb_private::ClangExpressionParser). It's not important though, as at
> this stage I don't see how we can reuse clang at all.
>
>
>
> On Wed, Mar 15, 2017 at 5:03 PM, Zachary Turner 
> wrote:
>
> If there is any way to re-use clang parser for this, it would be
> wonderful.  Even if it means adding support to clang for whatever you need
> in order to make it possible.  You mention performance, are you certain
> that clang's parser would be unacceptably slow?
>
> +cfe-dev as they may have some more input on what it would take to extend
> clang to make this possible.
>
> On Wed, Mar 15, 2017 at 4:48 PM Eugene Zemtsov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi, Everyone.
>
> Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
> cover full extent of possible function declarations,
> or even declarations returned by abi::__cxa_demangle.
>
> Consider this code:
> --
>
> #include 
> #include 
> #include 
>
> void func() {
>   printf("func() was called\n");
> }
>
> struct Class
> {
>   Class() {
> printf("ctor was called\n");
>   }
>
>   Class(const Class& c) {
> printf("copy ctor was called\n");
>   }
>
>   ~Class() {
> printf("dtor was called\n");
>   }
> };
>
>
> int main() {
>   std::function f = func;
>   f();
>
>   Class c;
>   std::vector v;
>   v.push_back(c);
>
>   return 0;
> }
>
> --
>
> When compiled It has at least two symbols that currently cannot be
> correctly parsed by MethodName::Parse() .
>
> void std::vector::_M_emplace_back_aux const&>(Class const&)
> void (* const::_Any_data::_M_access() const)() - a template 
> function that returns a reference to a function pointer.
>
> It causes incorrect behavior in avoid-stepping and sometimes messes
> printing of thread backtrace.
>
> I would like to solve this issue, but current implementation of method
> name parsing doesn't seem sustainable.
> Clever substrings and regexs are fine for trivial cases, but they become a
> nightmare once we consider more complex cases.
> That's why I'd like to have code that follows some kind of grammar
> describing function declarations.
>
> As I see it, choices for new implementation of MethodName::Parse() are
> 1. Reuse clang parsing code.
> 2. Parser generated by bison.
> 3. Handwritten recursive descent parser.
>
> I looked at the option #1, at it appears to be impossible to reuse clang
> parser for this kind of zero-context parsing.
> Especially given that we care about performance of this code. Clang C++
> lexer on the other hand can be reused.
>
> Option #2. Using bison is tempting, but it would require introduction of
> new compile time dependency.
> That might be especially inconvenient on Windows.
>
> That's why I think option #3 is the way to go. Recursive descent parser
> that reuses a C++ lexer from clang.
>
> LLDB doesn't need to parse everything (e.g. we don't care about details
> of function arguments), but it needs to be able to handle tricky return
> types and base names.
> Eventually new implementation should be able to parse signature of every
> method generated by STL.
>
> Before starting implementation, I'd love to get some feedback. It might be
> that my overlooking something important.
>
> --
> Thanks,
> Eugene Zemtsov.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
> --
> Thanks,
> Eugene Zemtsov.
> ___
> 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

Re: [lldb-dev] DWARF v5 unit headers

[Tamas Berghammer via lldb-dev]

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
have to teach LLDB to handle dwarf v5).

For the future changes, when you start to emit the new dwarf v5 tag and
form values instead of the current GNU extension tag and form values for
split dwarf and for the related new data form-s we will have to teach LLDB
to understand them (currently we expect only the GNU versions) so a heads
up for that change would be appreciated. Other then this I expect no issue
regarding the addition of dwarf v5 support for LLDB.

Tamas

On Tue, Feb 28, 2017 at 5:25 AM Robinson, Paul via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I'm planning to commit a patch (http://reviews.llvm.org/D30206) which will
> cause Clang/LLVM to emit correct unit headers if you ask for version 5.
> I've run the lldb tests and I *think* I pointed to my modified Clang
> correctly (cmake with -DLLDB_TEST_COMPILER=/my/clang) and AFAICT it does
> not introduce new problems.
> I saw 3 Failure and 12 Error with or without the patch.
> (One Expected Failure seems to have become an Unexpected Success. Haven't
> tried to decipher logs to figure out which one yet.)
>
> If anybody can predict a problem with my patch, please let me know by
> noon Pacific time (2000 GMT) tomorrow (28th).
>
> We're going to be doing more work implementing various bits of DWARF v5
> in the coming months.  If anybody thinks they can predict that there are
> particular bits that would be especially problematic for LLDB, it would
> be useful to know up front which bits those are.
>
> Thanks
> --paulr
>
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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
name is just the name of the file without any path? If the problem is what
I am guessing then you should see an output like this (note the relative
path).
(lldb) target modules dump line-table s.cpp
Line table for ./foo/s.cpp in `a.out
0x00400a0d: ./foo/s.cpp:3
0x00400a1a: ./foo/s.cpp:4
0x00400a58: ./foo/s.cpp:4
0x00400a64: ./foo/s.cpp:5
0x00400a93: ./foo/s.cpp:6
0x00400a9e: ./foo/s.cpp:6
...

The above problem can be worked around either by running LLDB with a
current working directory where the file path displayed by "target modules
dump line-table" is relative to or setting up a directory remapping for
that path using "settings set target.source-map ./ ".

Tamas

On Mon, Jan 9, 2017 at 11:55 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> In ELF files if there is a section named “.gnu_debuglink” it will contain
> a path to the external debug file. Dump this section and see what it
> contains. This section contains a null terminated C string as the path
> followed by a 4 byte aligned 32 bit integer which is a file CRC. Check to
> see the path is relative.
>
> I am guessing this is your problem.
>
> Greg
>
>
> On Jan 9, 2017, at 3:42 PM, Jeffrey Tan  wrote:
>
> Hey Greg, I just confirmed this with our build team. I seem to have
> misunderstood the location of debug symbol. It is actually not inside each
> individual object file but:
> The debug info in dev mode sits in the .debug_* sections of the shared
> libraries (we don't use debug fission).
> One potential complicating factor is that we relativize the 
> DW_AT_comp_dirattributes
> in the DWARF info, so that it's almost always just a long reference to the
> current working directory (e.g. .///).
>
> I do not know why this(symbol in shared library) would cause the bug
> though.
>
> Jeffrey
>
> On Mon, Jan 9, 2017 at 1:57 PM, Greg Clayton  wrote:
>
> Comments below.
>
> On Jan 9, 2017, at 1:10 PM, Jeffrey Tan via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> O ur company is using Buck(https://buckbuild.com/) to build internal
> service. Recently the build team made a change in buck to not merge dwarf
> symbols from each object file into final binary so debugger needs to read
> source/symbol table from compilation unit itself.
>
>
> How are debug symbols expected to be found? Is fission being used where
> the DWARF for each compile unit is in .dwo files and the main executable
> has skeleton DWARF? I will skip all other questions until we know more
> about how and where the DWARF is.
>
> Greg Clayton
>
>
>
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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
branch (as we know that the only way that block can be reached is through a
dynamic branch). If there is exactly 1 dynamic branch in the code then this
should gave us the "perfect" result while if we have multiple dynamic
branches then we will pick one "randomly" but for compiler generated code I
think it will be good enough. The only tricky case is if we fail to detect
the dynamic branch but that should be easy to fix as we already track every
branch on ARM (for single stepping) and doing it on AArch64 should be easy
as well.

On Tue, Nov 8, 2016 at 11:10 PM Jason Molenda  wrote:

> Yeah I was thinking that maybe if we spot an epilogue instruction (ret, b
> ), and the next instruction doesn't have a reinstated
> register context, we could backtrack to the initial register context of
> this block of instructions (and if it's not the beginning of the function),
> re-instate that register context for the next instruction.
>
> It doesn't help if we have a dynamic dispatch after the initial part of
> the function.  For that, we'd need to do something like your suggestion of
> finding the biggest collection of register saves.
>
> e.g. if I rearrange/modify my example function a little to make it more
> interesting (I didn't fix up the +offsets)
>
> prologue:
> > 0x17df0 <+0>:   stpx22, x21, [sp, #-0x30]!
> > 0x17df4 <+4>:   stpx20, x19, [sp, #0x10]
> > 0x17df8 <+8>:   stpx29, x30, [sp, #0x20]
> > 0x17dfc <+12>:  addx29, sp, #0x20; =0x20
>
> direct branch:
> > 0x17e1c <+44>:  cmpw20, #0x1d; =0x1d
> > 0x17e20 <+48>:  b.hi   0x17e4c   ; <+92>  {
> block #3 }
>
> dynamic dispatch:
> > 0x17e24 <+52>:  adrx9, #0x90 ; switcher + 196
> > 0x17e28 <+56>:  nop
> > 0x17e2c <+60>:  ldrsw  x8, [x9, x8, lsl #2]
> > 0x17e30 <+64>:  addx8, x8, x9
> > 0x17e34 <+68>:  br x8
>
> block #1
> > 0x17e9c <+172>: sxtw   x8, w19
> > 0x17ea0 <+176>: strx8, [sp]
> > 0x17ea4 <+180>: adrx0, #0x10f; "%c\n"
> > 0x17ea8 <+184>: nop
> > 0x17eac <+188>: bl 0x17f64   ; symbol stub
> for: printf
> > 0x17e70 <+128>: subsp, x29, #0x20; =0x20
> > 0x17e74 <+132>: ldpx29, x30, [sp, #0x20]
> > 0x17e78 <+136>: ldpx20, x19, [sp, #0x10]
> > 0x17e7c <+140>: ldpx22, x21, [sp], #0x30
> > 0x17eb0 <+192>: b 0x17f4c   ; symbol stub
> for: abort
>
> block #2
> > 0x17e38 <+72>:  subsp, x29, #0x20; =0x20
> > 0x17e3c <+76>:  ldpx29, x30, [sp, #0x20]
> > 0x17e40 <+80>:  ldpx20, x19, [sp, #0x10]
> > 0x17e44 <+84>:  ldpx22, x21, [sp], #0x30
> > 0x17e48 <+88>:  ret
>
>
> block #3
> > 0x17e4c <+92>:  addw0, w0, #0x1  ; =0x1
> > 0x17e50 <+96>:  b  0x17e38   ; <+72> at
> a.c:115
> > 0x17e54 <+100>: orrw8, wzr, #0x7
> > 0x17e58 <+104>: strx8, [sp, #0x8]
> > 0x17e5c <+108>: sxtw   x8, w19
> > 0x17e60 <+112>: strx8, [sp]
> > 0x17e64 <+116>: adrx0, #0x148; "%c %d\n"
> > 0x17e68 <+120>: nop
> > 0x17e6c <+124>: bl 0x17f64   ; symbol stub
> for: printf
> > 0x17e70 <+128>: subsp, x29, #0x20; =0x20
> > 0x17e74 <+132>: ldpx29, x30, [sp, #0x20]
> > 0x17e78 <+136>: ldpx20, x19, [sp, #0x10]
> > 0x17e7c <+140>: ldpx22, x21, [sp], #0x30
> > 0x17e80 <+144>: b  0x17f38   ; f3 at b.c:4
>
> block #4
> > 0x17e38 <+72>:  subsp, x29, #0x20; =0x20
> > 0x17e3c <+76>:  ldpx29, x30, [sp, #0x20]
> > 0x17e40 <+80>:  ldpx20, x19, [sp, #0x10]
> > 0x17e44 <+84>:  ldpx22, x21, [sp], #0x30
> > 0x17e48 <+88>:  ret
>
> First, an easy one:  When we get to the first instruction of 'block #4',
> we've seen a complete epilogue ending in 'B other-function' and the first
> instruction of block #4 is not branched to.  If we find the previous direct
> branch target -- to the first instruction of 'block #3' was conditionally
> branched to, we reuse that register context for block #4.  This could
> easily go wrong for hand-written assembly where you might undo the stack
> state part-way and then branch to another part of the function.  But I
> doubt compiler generated code is ever going to do that.
>
> Second, a trickier one: When we get to the first instruction of 'block
> #2', we have 

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

[Tamas Berghammer via lldb-dev]

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 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 understand it, there are a few ways to go about building lldb using
> the ToT (or at least, last green) compiler. This approach will be of
> limited use until building lldb with cmake is supported, however. I'm
> following up on this timeline.
>
> -Tim
>
>
> On Thu, Oct 20, 2016 at 11:50 AM, Ted Woodward <
> ted.woodw...@codeaurora.org> wrote:
>
> 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 packetize instructions, so 1 instruction is
> run at a time. At 01 it will, but it doesn’t do many other optimizations.
> We should still have 1 line per packet. O2 and O3 can move instructions
> around, so will have up to 4 source lines in 1 packet. I think we’ll need
> to experiment internally with what that means for the debugger, once we get
> this change.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Eric Christopher [mailto:echri...@gmail.com]
> *Sent:* Wednesday, October 19, 2016 6:09 PM
> *To:* Tim Hammerquist 
> *Cc:* Greg Clayton ; Ted Woodward <
> ted.woodw...@codeaurora.org>; LLDB 
> *Subject:* Re: [lldb-dev] llvm changing line table info from DWARF 2 to
> DWARF 4
>
>
>
>
>
> On Wed, Oct 19, 2016 at 3:34 PM Tim Hammerquist  wrote:
>
> I was mistaken.
>
>
>
> The system toolchain builds stage1 llvm, clang & co.
>
> The system toolchain builds lldb containing the llvm/clang/etc bits.
>
> The system toolchain builds gtest test programs.
>
> The stage1 compiler builds the python test inferiors.
>
>
>
>
>
> OK, then it sounds like at least some of the test programs are built with
> the new compiler? IIRC the python test inferiors here are the programs that
> are the meat of the testsuite for lldb yes?
>
>
>
> If so, then on check-in we should possibly see some difference on some bot
> if they all use the same general configuration.  I don't have a current
> checkout so I don't know if the default -g is used or if it's set to a
> different dwarf level. Currently it looks like clang will use dwarf4 by
> default with -g:
>
>
>
> echristo@dzur ~/tmp> ~/builds/build-llvm/bin/clang -c foo.c -o - -target
> x86_64-apple-macosx10.11 -g | llvm-dwarfdump - | grep version | grep -v
> clang
>
> 0x: Compile Unit: length = 0x0037 version = 0x0004 abbr_offset
> = 0x addr_size = 0x08 (next unit at 0x003b)
>
>  version: 2
>
>
>
> where the first line is the debug_info header and the second is the
> version in the line table.
>
>
>
> Ted/Greg: Relatedly, what brought this up was the vliw aspect with 
> maximum_operations_per_instruction
> - it's being hard coded to 1 here and I'm not sure how we want to deal with
> that on hexagon? Currently it'll be hard set to 1 so line stepping will
> work as I imagine it currently does. That said, if we wanted to take
> advantage of it then that's different. Primarily I wasn't sure if Ted and
> folk had a debugger that did take advantage of it if it was there.
>
>
>
> Thanks!
>
>
>
> -eric
>
>
>
>
>
> On Wed, Oct 19, 2016 at 3:28 PM, Eric Christopher 
> wrote:
>
>
>
> On Wed, Oct 19, 2016 at 3:26 PM Tim Hammerquist  wrote:
>
> The LLDB job in llvm.org will build a stage1 RA with
> llvm+clang+libcxx+compiler-rt using the system compiler, and use the new
> compiler to build lldb.
>
>
>
> By default, this is kicked off automatically when a clang stage1 RA is
> successful, but can be manually triggered to build HEAD, or any revision
> desired.
>
>
>
> The python test suite (invoked with the xcodebuild target
> lldb-python-test-suite) uses the newly built compiler to build its test
> programs.
>
>
>
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/21202/consoleFull#console-section-4
>
>
>
> However, the gtest suite (target lldb-gtest) uses the system (Xcode
> toolchain) compiler to build test programs.
>
>
>
>
> http://lab.llvm.org:8080/green/job/lldb_build_test/21202/artifact/lldb/test_output.zip
>
>
>
>
>
> This seems like something that should be fixed :)
>
>
>
> -eric
>
>
>
>
>
> -Tim
>
>
>
> On Wed, Oct 19, 2016 at 2:36 PM, Eric 

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

[Tamas Berghammer via lldb-dev]

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 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 API reference documentation available at
http://lldb.llvm.org/python_reference/
<http://lldb.llvm.org/python_reference/index.html> 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 "ninja lldb-cpp-doc
lldb-python-doc" (from a Linux machine using epydoc 3.0.1 and doxygen
1.8.6) to get them up to date. Is there any objection against it?

Additionally, in the future it would be great if we can keep the generated
doc more up to date after additions to the SB API so users of LLDB can rely
it.


There is a bot continuously updating http://llvm.org/docs/ ; ideally we
should be able to hook the other LLVM sub-projects there.

—
Mehdi
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Regenerating public API reference documentation

[Tamas Berghammer via lldb-dev]

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 "ninja lldb-cpp-doc
lldb-python-doc" (from a Linux machine using epydoc 3.0.1 and doxygen
1.8.6) to get them up to date. Is there any objection against it?

Additionally, in the future it would be great if we can keep the generated
doc more up to date after additions to the SB API so users of LLDB can rely
it.

Tamas
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Evolution

[Tamas Berghammer via lldb-dev]

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);sub(" *$","");printf("%s%d\n",
> $0, t-length($0));}' | sort -t: -n -k 3 -r | awk 'BEGIN { FS = ":" } ; { if
> ($3 >= 50) print $0 }'
> On Sun, Aug 28, 2016 at 9:54 AM Zachary Turner  wrote:
>
>> I tried that, but most of the results (and there are a ton to wade
>> through) are function parameters that wrapped and align with the opening
>> paren on the next line.
>>
>> Earlier in the thread (i think it was this thread anyway) i posted a bash
>> incantation that will grep the source tree and return all lines with >= N
>> leading spaces sorted descending by number of leading spaces. The highest
>> was about 160 :)
>>
>> If you search lldb-dev for awk or sed you'll probably find it
>> On Sun, Aug 28, 2016 at 9:10 AM Chris Lattner  wrote:
>>
>>> Can you just grep for “^“ or something?
>>> That seems like a straight-forward way to find lines that have a ton of
>>> leading indentation.
>>>
>>> -Chris
>>>
>>> On Aug 27, 2016, at 9:28 AM, Zachary Turner  wrote:
>>>
>>> It will probably be hard to find all the cases.  Unfortunately
>>> clang-tidy doesn't have a "detect deep indentation" check, but that would
>>> be pretty useful, so maybe I'll try to add that at some point (although I
>>> doubt I can get to it before the big reformat).
>>>
>>> Finding all of the egregious cases before the big reformat will present
>>> a challenge, so I'm not sure if it's better to spend effort trying, or just
>>> deal with it as we spot code that looks bad because of indentation level.
>>>
>>> On Sat, Aug 27, 2016 at 9:24 AM Chris Lattner 
>>> wrote:
>>>
 On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

 Back to the formatting issue, there's a lot of code that's going to
 look bad after the reformat, because we have some DEEPLY indented code.
 LLVM has adopted the early return model for this reason.  A huge amount of
 our deeply nested code could be solved by using early returns.


 FWIW, early returns are part of the LLVM Coding standard:

 http://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code

 So it makes sense for LLDB to adopt this approach at some point.

 I don’t have an opinion about whether it happens before or after the
 "big reformat", but I guess I agree with your point that doing it would be
 good to do it for the most egregious cases before the reformat.

 -Chris

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

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

[Tamas Berghammer via lldb-dev]

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 feature hit OCaml packages.
>
> Anyway, here are the patches. I would be fine with just the code review if
> the absence of tests is a bother.
> I ran check-lldb before and after applying the patches, and AFAIK I didn't
> introduce any regressions.
>
> Elias
>
> --
> From: tbergham...@google.com
> Date: Thu, 7 Jul 2016 13:23:41 +
>
> Subject: Re: [lldb-dev] Add support for OCaml native debugging
> To: e.bouta...@hotmail.fr; lldb-dev@lists.llvm.org
>
>
> 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.
>
> Tamas
>
> On Wed, Jul 6, 2016 at 3:26 PM E BOUTALEB via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I would like to submit two patches for code review.
> They introduce concrete support for OCaml native debugging, granted that
> you have access to the native compiler with DWARF emission support (see
> https://github.com/ocaml/ocaml/pull/574)
>
> This adds about 2000 lines of code.
> The type system isn't particularly complex here, every value is considered
> as an unsigned integer, and interpretation of the value is left to an
> external debugging layer made in OCaml.
> The language plugin handles function name demangling for breakpoints too.
>
> No tests for now. Is it fine to commit binaries with the patchs?
>
> Elias Boutaleb
> ___
> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 <
lldb-dev@lists.llvm.org> wrote:

> It would be nice to get a patch that gets rid of the Mutex.h/Mutex.cpp and
> switches over to using C++11 std::mutex/std::recursive_mutex and get rid of
> Condition.h/Condition.cpp for std::condition_variable. Then we can be more
> consistent. We need to make sure the C++ standard libraries are ready on
> all platforms first though.
>
> Greg
>
> > On May 11, 2016, at 3:01 PM, Zachary Turner  wrote:
> >
> > I mean std::recursive_mutex is recursive
> >
> > On Wed, May 11, 2016 at 3:01 PM Zachary Turner 
> wrote:
> > Yes, eventually we should move to std::mutex and
> std::condition_variable, in which case it behaves as expected (std::mutex
> is non recursive, std::mutex is recursive).
> >
> >
> >
> > On Wed, May 11, 2016 at 2:20 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > From lldb/source/Host/windows/Mutex.cpp:
> >
> >
> > Mutex::Mutex () :
> > m_mutex()
> > {
> > m_mutex =
> static_cast(malloc(sizeof(CRITICAL_SECTION)));
> > InitializeCriticalSection(static_cast(m_mutex));
> > }
> >
> > //--
> > // Default constructor.
> > //
> > // Creates a pthread mutex with "type" as the mutex type.
> > //--
> > Mutex::Mutex (Mutex::Type type) :
> > m_mutex()
> > {
> > m_mutex =
> static_cast(malloc(sizeof(CRITICAL_SECTION)));
> > InitializeCriticalSection(static_cast(m_mutex));
> > }
> >
> >
> > It also means that Condition.cpp doesn't act like its unix counterpart
> as the pthread_contition_t requires that wait be called with a non
> recursive mutex. Not sure what or if any issues are resulting from this,
> but I just thought everyone should be aware.
> >
> > Greg Clayton
> >
> > ___
> > 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

+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 7:04 PM Jeffrey Pautler via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi all. First post…new to the mailing list.
>
>
>
> I was looking for the lldb/branches/google/stable/ branch on a git mirror,
> but was unable to find it. I was specifically looking at
> http://llvm.org/git/lldb.git, but didn’t see it anywhere else either
> (github, etc).
>
>
>
> Is it only available from the svn repo?
>
>
>
> Would it be useful for anyone else for that branch to be mirrored to the
> git repo as well?
>
>
>
> Thanks,
>
> Jeff
>
>
>
>
>
>
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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
how you can add a new one here: http://lldb.llvm.org/varformats.html

Enrico: Is there any reason you suggested the data formatters written
inside LLDB over the python based ones?

On Thu, Apr 7, 2016 at 3:31 AM Jeffrey Tan via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Thanks Enrico. This is very detailed! I will take a look.
> Btw: originally, I was hoping that data formatter can be added without
> changing the source code. Like giving a xml/json format file telling lldb
> the memory layout/structure of the data structure, lldb can parse the
> xml/json and deduce the formatting. This is approach used by data
> visualizer in VS debugger:
> https://msdn.microsoft.com/en-us/library/jj620914.aspx
> This will make adding data formatter more extensible/flexible. Any reason
> we did not take this approach?
>
> Jeffrey
>
> On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata 
> wrote:
>
>>
>> On Apr 5, 2016, at 2:42 PM, Jeffrey Tan  wrote:
>>
>> Hi Enrico,
>>
>> Any suggestion/example how to add a data formatter for our own STL
>> string? From the output below I can see we are using our own "
>> *fbstring_core*" which I assume I need to write a type summary for this
>> type:
>>
>> frame variable corpus -T
>> (const string ) corpus = error: summary string parsing error: {
>>   (std::*fbstring_core*) store_ = {
>> (std::*fbstring_core*::(anonymous union))  = {
>>   (char [24]) small_ = "www"
>>   (std::fbstring_core::MediumLarge) ml_ = {
>> (char *) data_ = 0x0077
>> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H\x89��_U��D\x88e�H\x8bE\xa0H\x89��]U��H\x89�H\x8dE�H\x89�H\x89���
>> ��L\x8dm�H\x8bE\x98H\x89��IU��\x88]�L\x8be\xb0L\x89��
>> (std::size_t) size_ = 0
>> (std::size_t) capacity_ = 1441151880758558720
>>   }
>> }
>>   }
>> }
>>
>>
>> Admittedly, this is going to be a little vague since I haven’t really
>> seen your code and I am only working off of one sample
>>
>> There’s going to be two parts to getting this to work:
>>
>> *Part 1 - Formatting fbstring_core*
>>
>> At a glance, an fbstring_core can be backed by two representations.
>> A “small” representation (a char array), and a “medium/large"
>> representation (a char* + a size)
>> I assume that the way you tell one from the other is
>>
>> if (size == 0) small
>> else medium-large
>>
>> If my assumption is not correct, you’ll need to discover what the correct
>> discriminator logic is - the class has to know, and so do you :-)
>>
>> Armed with that knowledge, look in lldb
>> source/Plugins/Language/CPlusPlus/Formatters/LibCxx.cpp
>> There’s a bunch of code that deals with formatting llvm’s libc++
>> std::string - which follows a very similar logic to your class
>>
>> ExtractLibcxxStringInfo() is the function that handles discovering which
>> layout the string uses - where the data lives - and how much data there is
>>
>> Once you have told yourself how much data there is (the size) and where
>> it lives (array or pointer), LibcxxStringSummaryProvider() has the easy
>> task - it sets up a StringPrinter, tells it how much data to print, where
>> to get it from, and then delegates the StringPrinter to do the grunt work
>> StringPrinter is a nifty little tool - it can handle generating summaries
>> for different kinds of strings (UTF8? UTF16? we got it - is a \0 a
>> terminator? what quote character would you like? …) - you point it at some
>> data, set up a few options, and it will generate a printable representation
>> for you - if your string type is doing anything out of the ordinary, let’s
>> talk - I am definitely open to extending StringPrinter to handle even more
>> magic
>>
>> *Part 2 - Teaching std::string that it can be backed by an fbstring_core*
>>
>> At the end of part 1, you’ll probably end up with a
>> FBStringCoreSummaryProvider() - now you need to teach LLDB about it
>> The obvious thing you could do would be to go in CPlusPlusLanguage
>> ::GetFormatters() add a LoadFBStringFormatter(g_category) to it - and
>> then imitate - say - LoadLibCxxFormatters()
>>
>> AddCXXSummary(cpp_category_sp, lldb_private::formatters::
>> FBStringCoreSummaryProvider, “fbstringcore summary provider", ConstString
>> (“std::fbstring_core<.+>"), stl_summary_flags, true);
>>
>> That will work - but what you would see is:
>>
>> (const string ) corpus = error: summary string parsing error: {
>>   (std::*fbstring_core*) store_ = “www"
>>
>>
>> You wanna do
>>
>> (lldb) log enable lldb formatters
>> (lldb) frame variable -T corpus
>>
>> It will list one or more typenames - the most specific one is the one you
>> like (e.g. for libc++ we get std::__1::string - this is how we 

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

[Tamas Berghammer via lldb-dev]

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
state.

On Mon, Apr 4, 2016 at 10:53 PM Todd Fiala  wrote:

> One more update:
>
> The Green Dragon OS X LLDB builder now actually runs the gtests instead of
> just building them.
>
> The gtests run as a phase right before the Python test suite.  A non-zero
> value returning from the gtests will cause the OS X LLDB build to fail.
> Right now, tracking down the cause of the failure will require looking at
> the console log for the build and test job.  I'm excited to see our gtest
> test count has gone from roughly 17  to over 100 now!
>
> Pavel or Tamas, are we running the gtests on the Linux buildbots?
>
> -Todd
>
> On Mon, Apr 4, 2016 at 10:49 AM, Todd Fiala  wrote:
>
>> Hi all,
>>
>> I've made a minor change to the Green Dragon LLDB OS X Xcode build
>> located here:
>> http://lab.llvm.org:8080/green/job/LLDB/
>>
>> 1. Previously, the python test run used the default C/C++ compiler to
>> build test inferiors.  Now it uses the just-built clang/clang++ to build
>> test inferiors.  At some point in the future, we will change this to a
>> matrix of important clang/clang++ versions (e.g. some number of official
>> Xcode-released clangs).  For now, however, we'll continue to build with
>> just one, and that one will be the one in the clang build tree.
>>
>> 2. The Xcode llvm/clang build step now includes compiler-rt and libcxx.
>> This, together with the change above, will allow the newer LLDB TSAN tests
>> to run.
>>
>> If you're ever curious how the Xcode build is run, it uses the build.py
>> script in the zorg repo (http://llvm.org/svn/llvm-project/zorg/trunk)
>> under zorg/jenkins/build.py.  The build constructs the build tree with a
>> "derive-lldb" command, and does the Xcode build with the "lldb" command.
>>
>> Please let me know if you have any questions.
>>
>> I'll address any hiccups that may show up ASAP.
>>
>> Thanks!
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 arm we compile to thumb2 instruction set what is in average ~30%
smaller then the arm (and aarch64) instruction set. Before this change the
size of lldb-server on arm was ~14MB
* We have Safe ICF (identical code folding) enabled for arm what reduces
the binary size by 5-10%. It is not enabled for aarch64 because last time I
checked there was still some issue in ld.gold when using ICF on aarch64. It
should be already fixed upstream but haven't reached the NDK yet.
* The aarch64 lldb-server capable of debugging both arm and aarch64
applications so it contains a bit more code because of this (e.g. 2
spearate register context)

Optimizing the size of both binary is possible (and we want to do it sooner
or later) but because of the reasons I listed the arm one will stay much
smaller then the aarch64 one.

Tamas

On Tue, Mar 1, 2016 at 9:18 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> so the problem here is that we are currently relying on the linker to
> remove code that we don't need, and it can't always do a good job in
> figuring out which code is not used due to complex dependencies. So,
> innocent-looking changes in the code can pull in lots of transitive
> dependencies, even though they are not used. I suspect something like
> that is going on here, although we should keep in mind that arm64 code
> is less dense naturally. Any help on this front will be welcome,
> although it probably won't be trivial, as we have probably picked off
> the low-hanging fruit already.
>
> That said, you may want to try adding LLVM_TARGETS_TO_BUILD=Aarch64 to
> your cmake line. We use that, although I can't say how much it affects
> the size of the resulting binary.
>
> help that helps,
> pl
>
> On 29 February 2016 at 20:15, Mikhail Filimonov via lldb-dev
>  wrote:
> > Hello, fellow developers and congratulations with long awaited 3.8
> Release.
> >
> > I wonder why AArch64 stripped binary of lldb-server built from [3.8
> Release] RC3 source is so much bigger than its ARM counterpart.
> > See the numbers:
> > 16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64
> >  9570916 Feb 29 22:23 lldb-server-3.8.0-arm
> > lldb-server-3.8.0-aarch64: ELF 64-bit LSB  executable, ARM aarch64,
> version 1 (SYSV), statically linked, stripped
> > lldb-server-3.8.0-arm: ELF 32-bit LSB  executable, ARM, EABI5
> version 1 (SYSV), statically linked, stripped
> >
> > My build configuration is MinSizeRel in both cases:
> > cmake -GNinja
> > -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> > -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> > -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/aarch64-21-android
> > -DANDROID_ABI=aarch64
> > -DCMAKE_CXX_COMPILER_VERSION=4.9
> > -DLLVM_TARGET_ARCH=aarch64
> > -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android
> > -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> > -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
> >
> > cmake -GNinja
> > -DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
> > -DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
> > -DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/arm-21-android-toolchain
> > -DANDROID_ABI=armeabi
> > -DCMAKE_CXX_COMPILER_VERSION=4.9
> > -DLLVM_TARGET_ARCH=arm
> > -DLLVM_HOST_TRIPLE=arm-unknown-linux-android
> > -DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
> > -DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
> >
> > Maybe I need some additional settings to be set for AArch64 case?
> >
> > Regards,
> > Mikhail
> >
> > -Original Message-
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> Hans Wennborg via lldb-dev
> > Sent: Wednesday, February 24, 2016 12:51 AM
> > To: release-test...@lists.llvm.org
> > Cc: llvm-dev ; cfe-dev ;
> openmp-dev (openmp-...@lists.llvm.org) ; LLDB
> Dev 
> > Subject: [lldb-dev] [3.8 Release] RC3 has been tagged
> >
> > Dear testers,
> >
> > Release Candidate 3 has just been tagged [1]. Please build, test, and
> upload to the sftp.
> >
> > If there are no regressions from previous release candidates, this will
> be the last release candidate before the final release.
> >
> > Release notes can still go into the branch.
> >
> > Thanks again for all your work!
> > Hans
> >
> >  [1]
> http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> ---
> > This email message is for the 

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

[Tamas Berghammer via lldb-dev]

I completely agree with you that we shouldn't change LLDB too much just to
speed up the startup time at the first use.

For android we already have a host side disk cache in place similar to what
you described for iOS and we already using ADB (an android specific
interface) to download the 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 <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, Tamas Berghammer via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > 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 think you won't have to download them the next time when you try to
> use a different device. In case of Android we have to download the symbols
> from each device you are using and at that point 30s might be an issue (I
> still don't think it is).
> >
> > With my app developer hat on, if some program makes me wait 30s for
> something then I won't like that program.
>
> I agree, but if the first time you hook your phone up Android Studio pops
> up a dialog box saying "This is the first time you have connected this
> device, hold on while I cache the shared libraries for this device..." then
> it wouldn't be too bad. It is primarily the fact that the 30 seconds is
> happening without feedback during first launch or attach. Also, you can
> probably use something faster than the lldb-platform to download all of the
> files. In Xcode, we download all symbols into the users home directory in a
> known location:
>
> ~/Library/Developer/Xcode/iOS DeviceSupport
>
> This folder contains the exact OS version and a build number:
>
> (lldb) platform select remote-ios
>   Platform: remote-ios
>  Connected: no
>  SDK Roots: [ 0] "~/Library/Developer/Xcode/iOS DeviceSupport/9.0 (W)"
>  SDK Roots: [ 1] "~/Library/Developer/Xcode/iOS DeviceSupport/9.1 (X)"
>  SDK Roots: [ 2] "~/Library/Developer/Xcode/iOS DeviceSupport/9.2 (Y)"
>
> Where W, X, Y are build numbers. We know we can look in these
> folders for any files that are from the device. They get populated and
> these SDK directories get searched by LLDB's PlatformRemoteiOS so they get
> found (we don't use the file cache that the PlatformAndroid currently uses).
>
> So with a little work, I would add some functionality to your Android
> Studio, have something that knows how to copy files from device as quickly
> as possible (using lldb-platform is slwww and that is the way it is
> currently done I believe) into some such directory, all while showing a
> progress dialog to the user on first device connect, and then debugging
> will always be quick. And you can probably make it quicker than 30 seconds.
>
> Greg Clayton
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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
think you won't have to download them the next time when you try to use a
different device. In case of Android we have to download the symbols from
each device you are using and at that point 30s might be an issue (I still
don't think it is).

On Tue, Feb 23, 2016 at 6:00 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I believe this is already done.
>
> I am guessing the main issue is this happens on the first time you debug
> to a device you and up with a 30 second delay with no feedback as to what
> is going on. So you say "launch" and then 35 seconds later you hit your
> breakpoint at main. In Xcode we solve this by downloading all of the files
> when we attach to a device for the first time and we show progress as we
> download all shared libraries. Sounds like it would be good for Android
> Studio to do the same thing?
>
> Greg
> > On Feb 22, 2016, at 5:27 PM, Zachary Turner  wrote:
> >
> > Can't you just cache the modules locally on the disk, so that you only
> take that 26 second hit the first time you try to download that module, and
> then it indexes it by some sort of hash.  Then instead of just downloading
> it, you check the local cache first and only download if it's not there.
> >
> > If you already do all this, then disregard.
> >
> > On Mon, Feb 22, 2016 at 4:39 PM Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > > On Jan 28, 2016, at 4:21 AM, Pavel Labath  wrote:
> > >
> > > Hello all,
> > >
> > > we are running into limitations of the current module download/caching
> > > system. A simple android application can link to about 46 megabytes
> > > worth of modules, and downloading that with our current transfer rates
> > > takes about 25 seconds. Much of the data we download this way is never
> > > actually accessed, and yet we download everything immediately upon
> > > starting the debug session, which makes the first session extremely
> > > laggy.
> > >
> > > We could speed up a lot by only downloading the portions of the module
> > > that we really need (in my case this turns out to be about 8
> > > megabytes). Also, further speedups could be made by increasing the
> > > throughput of the gdb-remote protocol used for downloading these files
> > > by using pipelining.
> > >
> > > I made a proof-of-concept hack  of these things, put it into lldb and
> > > I was able to get the time for the startup-attach-detach-exit cycle
> > > down to 5.4 seconds (for comparison, the current time for the cycle is
> > > about 3.6 seconds with a hot module cache, and 28(!) seconds with an
> > > empty cache).
> > >
> > > Now, I would like to properly implement these things in lldb properly,
> > > so this is a request for comments on my plan. What I would like to do
> > > is:
> > > - Replace ModuleCache with a SectionCache (actually, more like a cache
> > > of arbitrary file chunks). When a the cache gets a request for a file
> > > and the file is not in the cache already, it returns a special kind of
> > > a Module, whose fragments will be downloaded as we are trying to
> > > access them. These fragments will be cached on disk, so that
> > > subsequent requests for the file do not need to re-download them. We
> > > can also have the option to short-circuit this logic and download the
> > > whole file immediately (e.g., when the file is small, or we have a
> > > super-fast way of obtaining the whole file via rsync, etc...)
> > > - Add pipelining support to GDBRemoteCommunicationClient for
> > > communicating with the platform. This actually does not require any
> > > changes to the wire protocol. The only change is in adding the ability
> > > to send an additional request to the server while waiting for the
> > > response to the previous one. Since the protocol is request-response
> > > based and we are communication over a reliable transport stream, each
> > > response can be correctly matched to a request even though we have
> > > multiple packets in flight. Any packets which need to maintain more
> > > complex state (like downloading a single entity using continuation
> > > packets) can still lock the stream to get exclusive access, but I am
> > > not sure if we actually even have any such packets in the platform
> > > flavour of the protocol.
> > > - Paralelize downloading of multiple files in parallel, utilizing
> > > request pipelining. Currently we get the biggest delay when first
> > > attaching to a process (we download file headers and some basic
> > > informative sections) and when we try to set the first symbol-level
> > > breakpoint (we download symbol tables and string sections). Both of
> > > these actions operate on all 

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

[Tamas Berghammer via lldb-dev]

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 of the owner/maintainer. The main reason I think
it this way because a change like this will increase the number of build
failures what will give more work to the buildbot maintainer primarily
because most buildbot don't send out failure messages (flakiness) and I am
not convinced that the community will fix some warning based on a report
from a build bot.

As a partial maintainer of 5 different buildbots I don't want to enable
-Werror on any them as I think it will be too much additional maintenance
work compared to the benefit unless we enforce -Werror on local builds as
well (e.g. use -Werror if compiling with clang on an x86_64 platform).

On Wed, Feb 17, 2016 at 3:19 AM Saleem Abdulrasool 
wrote:

> On Tue, Feb 16, 2016 at 12:38 PM, Kamil Rytarowski  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> NetBSD builds with GCC 4.8.2 and it emits few warnings for LLDB.
>>
>> Before enabling -Werror please first iterate over build logs and help
>> to squash them. For example it detects undefined behavior IIRC for a
>> Darwin code part.
>
>
> Interesting.  On Linux, lldb had many warnings, and over time, I've
> managed to get mots of them cleaned up.  Right now, there are a couple of
> -Wtype-limits warnings and one -Wformat warning.  Is there a build bot that
> can be used to monitor what those warnings are?  If there aren't any
> buildbots, then this would be of no consequence since we wouldn't turn it
> on for user builds.
>
> I wish I had caught what I wrote versus what I was thinking before hitting
> send :-(.
>
>
>>
>> On 16.02.2016 20:01, Zachary Turner via lldb-dev wrote:
>> > You're talking about doing it on a per-bot basis and not a global
>> > policy, but just throwing in that on the MSVC side at least, we're
>> > not warning free right now and it's not trivial tog et warning free
>> > without disabling some warnings (which I don't want to do either)
>> >
>> > On Tue, Feb 16, 2016 at 10:31 AM Saleem Abdulrasool via lldb-dev
>> > > wrote:
>> >
>> > On Tuesday, February 16, 2016, Tamas Berghammer
>> > > wrote:
>> >
>> > 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)?
>> >
>> >
>> > I think that the same policy as LLVM/clang should apply here.  The
>> > person making the change would be responsible for ensuring that
>> > nothing breaks as a result of their change.  The same situation
>> > exists when working on interfaces that effect clang: a fix for a
>> > warning introduced by a change in LLVM may be non-trivial in
>> > clang.
>> >
>> > Just to be clear, I'm merely suggesting this as an option.  If it
>> > is deemed too burdensome by most of the common committers, we state
>> > so and not do this.
>> >
>> >
>> >
>> > On Tue, Feb 16, 2016 at 4:31 PM Saleem Abdulrasool
>> >  wrote:
>> >
>> > On Tuesday, February 16, 2016, Tamas Berghammer
>> >  wrote:
>> >
>> > 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 nor clang have -Werror enabled so if
>> > we enable it then a clang/llvm change can break our build with a
>> > warning when it is hard to justify a revert and a fix might not be
>> > trivial.
>> >
>> >
>> > Err, sorry.  I meant by default on the build bots (IIRC, some
>> > (many?) of the build bots do build with -Werror for LLVM and
>> > clang).  Yes, a new warning in clang could cause issues in LLDB,
>> > though the same thing exists for the LLVM/clang dependency.  Since
>> > this would be on the build bots, it should get resolved rather
>> > quickly.
>> >
>> > In short term I would prefer to just create a policy saying
>> > everybody should write warning free code for lldb (I think it
>> > already kind of exists) and we as a community try to ensure it
>> > during code review and with fixing the possible things what slip
>> > through. In the longer term I would be happy to see -Werror turned
>> > on for llvm and clang first and then we can follow up with lldb but
>> > making this change will require a lot of discussion and might get
>> > some push back.
>> >
>> > 

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

[Tamas Berghammer via lldb-dev]

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 Tue, Feb 16, 2016 at 4:31 PM Saleem Abdulrasool 
wrote:

> On Tuesday, February 16, 2016, Tamas Berghammer 
> wrote:
>
>> 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 nor clang have -Werror enabled so if we enable it then a
>> clang/llvm change can break our build with a warning when it is hard to
>> justify a revert and a fix might not be trivial.
>>
>
> Err, sorry.  I meant by default on the build bots (IIRC, some (many?) of
> the build bots do build with -Werror for LLVM and clang).  Yes, a new
> warning in clang could cause issues in LLDB, though the same thing exists
> for the LLVM/clang dependency.  Since this would be on the build bots, it
> should get resolved rather quickly.
>
> In short term I would prefer to just create a policy saying everybody
>> should write warning free code for lldb (I think it already kind of exists)
>> and we as a community try to ensure it during code review and with fixing
>> the possible things what slip through. In the longer term I would be happy
>> to see -Werror turned on for llvm and clang first and then we can follow up
>> with lldb but making this change will require a lot of discussion and might
>> get some push back.
>>
>> On Tue, Feb 16, 2016 at 6:02 AM Saleem Abdulrasool via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> It seems that enabling -Werror by default is within reach for lldb now.
>>> There currently are three warnings that remain with gcc 5.1 on Linux, and
>>> the build is clean of warnings with clang.
>>>
>>> There are two instances of type range limitations on comparisons in
>>> asserts, and one instance of string formatting which has a GNU
>>> incompatibility.
>>>
>>> Is there any interest in enabling -Werror by default to help keep the
>>> build clean going forward?
>>>
>>> --
>>> Saleem Abdulrasool
>>> compnerd (at) compnerd (dot) org
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 nor clang have -Werror enabled so if we enable it then a
clang/llvm change can break our build with a warning when it is hard to
justify a revert and a fix might not be trivial.

In short term I would prefer to just create a policy saying everybody
should write warning free code for lldb (I think it already kind of exists)
and we as a community try to ensure it during code review and with fixing
the possible things what slip through. In the longer term I would be happy
to see -Werror turned on for llvm and clang first and then we can follow up
with lldb but making this change will require a lot of discussion and might
get some push back.

On Tue, Feb 16, 2016 at 6:02 AM Saleem Abdulrasool via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> It seems that enabling -Werror by default is within reach for lldb now.
> There currently are three warnings that remain with gcc 5.1 on Linux, and
> the build is clean of warnings with clang.
>
> There are two instances of type range limitations on comparisons in
> asserts, and one instance of string formatting which has a GNU
> incompatibility.
>
> Is there any interest in enabling -Werror by default to help keep the
> build clean going forward?
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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:

> I’ve been investing the “po performance bug” ( po
> when debugging Xcode is extremely slow) in recent Xcode, and I discovered
> this problem.
>
> We are looking at pch files that are generated on Xcode’s behalf and it
> looks like we’re recursing through their dependencies when we don’t find
> something, but we’re probably not searching efficiently because this is
> super slow.
>
> This would be an Everest regression.
>
> I’m going to keep working on the original Radar because I haven’t gotten
> Brent’s backtrace yet; that said, this one is going to affect users’
> perception of expression parser performance as well so I’ve filed it
> separately.
>
> Sean
> ___
> 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

Re: [lldb-dev] Running a single test

[Tamas Berghammer via lldb-dev]

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 via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Try passing the directory to start in as the last argument.  Also make
> sure you include .py on the filename when using -p (I don't actually know
> if this is required but I do it).
>
> % python dotest.py
> --executable /tank/emaste/src/llvm/build-nodebug/bin/lldb -C /usr/bin/clang
> -v -t -p TestCppIncompleteTypes.py
> ~/src/llvm/tools/lldb/packages/Python/lldbsuite/test
>
> I don't know off the top of my head why that last argument is required,
> and I agree it's counterintuitive and probably doesn't *need* to be that
> way for technical reasons.
>
> LMK if this works
>
> On Tue, Feb 9, 2016 at 2:01 PM Ed Maste via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I've been away from LLDB development for a little while but am
>> starting to work on it again.
>>
>> I used to run a few tests using dotest.py's -f or -p flags, but they
>> don't seem to be working now.
>>
>>   -f filterspec Specify a filter, which consists of the test class
>> name, a dot, followed by the test method, to only
>> admit such test into the test suite
>>   -p patternSpecify a regexp filename pattern for inclusion
>> in the
>> test suite
>>
>> For example, I'd expect this command:
>>
>> % python dotest.py --executable
>> /tank/emaste/src/llvm/build-nodebug/bin/lldb -C /usr/bin/clang -v -t
>> -p TestCppIncompleteTypes
>>
>> to run just the TestCppIncompleteTypes.py test(s), but instead it
>> looks like it runs the full suite.
>>
>> I'd also expect
>>
>> % python dotest.py --executable
>> /tank/emaste/src/llvm/build-nodebug/bin/lldb -C /usr/bin/clang -v -t
>> -f TestCppIncompleteTypes.test_limit_debug_info
>>
>> to run a single test from the same suite, but it runs no tests
>> ("Collected 0 tests").
>>
>> I'm sure these options used to work, although this could be an issue
>> that affects only FreeBSD. Do they work on Linux/OS X?
>> ___
>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 decide what is our plan for going forward both
in terms of Visual Studio version and Python version and I expect that we
will make a decision this week. Until then please don't remove any hack we
have in the code because of MSVC 2013 (e.g. alias template workarounds) and
if adding new code then please try not to break MSVC 2013. I will send out
an update about our decision hopefully at the end of this week.

You mentioned that LLVM plan to bump the minimum version of MSVC to 2015.
Do you have any link to the place where they discussed it or do you know
anything about the schedule?

Thanks,
Tamas

On Tue, Feb 2, 2016 at 7:16 PM Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> As of this week, we have the test suite running clean under MSVC 2015
> using Python 3.5.  I'm sure new things will pop up, but I'm considering the
> transition "done" as of now.
>
> What this means for MSVC 2013 is that we dont' want to support it anymore.
>
> Reasons:
> * C++ language support is poor
> * Compiling your own version of Python is difficult and a high barrier to
> entry for people wanting to build LLDB on Windows
> * LLVM will eventually bump its minimum MSVC version to 2015 as well.
>
> To this end, I have already changed the MSVC buildbot [
> http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc2015] to compile
> using 2015.  The old 2013 buildbot no longer exists.
>
> This week I plan to update the build instructions on lldb.org to reflect
> the simpler more streamlined instructions for 2015 and remove the
> instructions for 2015.
>
> I know some people are still using 2013.  I don't plan to break anything
> or explicitly remove support from CMake or anywhere else for 2013.  I'm
> only saying that unless someone else steps up to keep this configuration
> working, it may break at any time, there won't be a buildbot testing it,
> and I can't guarantee anything about it continuing to work.
>
> Note that when LLVM bumps its minimum required version to MSVC 2015
> (expected this year), it will be **very hard for anyone to continue using
> Python 2 on Windows at tip of trunk**.  The only real workaround for this
> is going to be forking Python (on your own end) and making whatever changes
> are necessary to Python to keep it compiling, as they will not accept the
> patches upstream.
>
> Happy to answer any questions about this.
> ___
> 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

Re: [lldb-dev] Inquiry for performance monitors

[Tamas Berghammer via lldb-dev]

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 the functionality
into an IDE (they just have to link to your shared library)
* You can generate a Python API if you need one with SWIG the same way we
do it for the SB API
* You don't have to worry about making the code both Python 2.7 and Python
3.5 compatible

You can see a very simple example for implementing an out of tree C++
plugin in /examples/plugins/commands

On Mon, Feb 1, 2016 at 10:53 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Speaking for Android Studio, I think that we *could* use a
> python-based implementation (hard to say exactly without knowing the
> details of the implementation), but I believe a different
> implementation could be *easier* to integrate. Plus, if the solution
> integrates more closely with lldb, we could surface some of the data
> in the command-line client as well.
>
> pl
>
> On 1 February 2016 at 10:30, Ravitheja Addepally
>  wrote:
> > And what about the ease of integration into a an IDE, I don't really
> know if
> > the python based approach would be usable or not in this context ?
> >
> > On Mon, Feb 1, 2016 at 11:17 AM, Pavel Labath  wrote:
> >>
> >> It feels to me that the python based approach could run into a dead
> >> end fairly quickly: a) you can only access the data when the target is
> >> stopped; b) the self-tracing means that the evaluation of these
> >> expressions would introduce noise in the data; c) overhead of all the
> >> extra packets(?).
> >>
> >> So, I would be in favor of a lldb-server based approach. I'm not
> >> telling you that you shouldn't do that, but I don't think that's an
> >> approach I would take...
> >>
> >> pl
> >>
> >>
> >> On 1 February 2016 at 08:58, Ravitheja Addepally
> >>  wrote:
> >> > Ok, that is one option, but one of the aim for this activity is to
> make
> >> > the
> >> > data available for use by the IDE's like Android Studio or XCode or
> any
> >> > other that may want to display this information in its environment so
> >> > keeping that in consideration would the complete python based approach
> >> > be
> >> > useful ? or would providing LLDB api's to extract raw perf data from
> the
> >> > target be useful ?
> >> >
> >> > On Thu, Jan 21, 2016 at 10:00 PM, Greg Clayton 
> >> > wrote:
> >> >>
> >> >> One thing to think about is you can actually just run an expression
> in
> >> >> the
> >> >> program that is being debugged without needing to change anything in
> >> >> the GDB
> >> >> remote server. So this can all be done via python commands and would
> >> >> require
> >> >> no changes to anything. So you can run an expression to enable the
> >> >> buffer.
> >> >> Since LLDB supports multiple line expression that can define their
> own
> >> >> local
> >> >> variables and local types. So the expression could be something like:
> >> >>
> >> >> int perf_fd = (int)perf_event_open(...);
> >> >> struct PerfData
> >> >> {
> >> >> void *data;
> >> >> size_t size;
> >> >> };
> >> >> PerfData result = read_perf_data(perf_fd);
> >> >> result
> >> >>
> >> >>
> >> >> The result is then a structure that you can access from your python
> >> >> command (it will be a SBValue) and then you can read memory in order
> to
> >> >> get
> >> >> the perf data.
> >> >>
> >> >> You can also split things up into multiple calls where you can run
> >> >> perf_event_open() on its own and return the file descriptor:
> >> >>
> >> >> (int)perf_event_open(...)
> >> >>
> >> >> This expression will return the file descriptor
> >> >>
> >> >> Then you could allocate memory via the SBProcess:
> >> >>
> >> >> (void *)malloc(1024);
> >> >>
> >> >> The result of this expression will be the buffer that you use...
> >> >>
> >> >> Then you can read 1024 bytes at a time into this newly created
> buffer.
> >> >>
> >> >> So a solution that is completely done in python would be very
> >> >> attractive.
> >> >>
> >> >> Greg
> >> >>
> >> >>
> >> >> > On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally
> >> >> >  wrote:
> >> >> >
> >> >> > Hello,
> >> >> >   Regarding the questions in this thread please find the
> answers
> >> >> > ->
> >> >> >
> >> >> > How are you going to present this information to the user? (I know
> >> >> > debugserver can report some performance data... Have you looked
> into
> >> >> > how that works? Do you plan to reuse some parts of that
> >> >> > infrastructure?) and How will you get the information from the
> server
> >> >> > to
> >> >> > the client?
> >> >> >
> >> >> >  Currently I plan to show a list of instructions that have been
> >> >> > executed
> >> >> > so far, I saw the
> >> >> > implementation 

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

[Tamas Berghammer via lldb-dev]

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 specify a function what have to evaluate to true for the decorator to
be considered (and it is evaluated only after all other condition of
@expectedFailureAll). Then we can create a free function called
getLinuxDistribution what will return the distribution id and then as a
final step we can specify a lambda to expetedFailureAll through its new
argument what calls getLinuxDistribution and compares it with the right
value. I know it is a lot of hoops to jump over to get a distribution
specific decorator but I think this approach can handle arbitrarily complex
skip/xfail conditions what will help us in the future.

What do you think?

Thanks,
Tamas


On Fri, Jan 22, 2016 at 6:31 PM Todd Fiala  wrote:

> Hey all,
>
> What do you think about having some kind of way of marking the (in this
> case, specifically) Ubuntu distribution for fail/skip test decorators?
> I've had a few cases where I've needed to mark tests failing on for Ubuntu
> where it really was only a particular release of an Ubuntu distribution,
> and wasn't specifically the compiler.  (i.e. it was a constellation of more
> moving parts that clearly occur on a particular release of an Ubuntu
> distribution but not on others, and certainly not generically across all
> Linux distributions).
>
> I'd love to have a way to skip and xfail a test for a specific Ubuntu
> distribution release.  I guess it could be done uber-genrically, but with
> Linux distributions this can get complicated due to the os/distribution
> axes.  So I'd be happy to start off with just having them at a distribution
> basis:
>
> @skipIfUbuntu(version_check_list)  # version_check_list contains one or
> more version checks that, if passing, trigger the skip
>
> @expectedFailureUbuntu(version_check_list)  # similar to above
>
> Or possibly more usefully,
>
> @skipIfLinuxDistribution(version_check_list)  # version_check_list
> contains one or more version checks that, if passing, trigger the skip,
> includes the distribution
>
> @expectedFailureLinuxDistribution(version_check_list)  # similar to above
>
>
> It's not clear to me how to work in the os=linux, distribution=Ubuntu into
> the more generic checks like and get distribution-level version checking
> working right otherwise, but I'm open to suggestions.
>
> The workaround for the short term is to just use blanket-linux @skipIf and
> @expectedFailure style calls.
>
> Thoughts?
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 16, 2015, at 6:06 AM, Dean De Leo via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > assume we wish to use the expression evaluator to invoke a function from
> lldb, setting the result into an array passed as parameter, e.g:
> >
> > void test1(uint32_t* d) {
> >for(int i = 0; i < 6; i++){
> >d[i] = 42 + i;
> >}
> > }
> >
> > where the expected output should be d = {42,43,44,45,46,47}. However
> performing the following expression having as target android/mips32 returns:
> >
> > (lldb) expr -- uint32_t data[6] = {}; test1(data);  data
> > (uint32_t [6]) $4 = ([0] = 0, [1] = 2003456944, [2] = 44, [3] = 45, [4]
> = 2004491136, [5] = 47)
> >
> > Is this an expected behaviour or a bug?
>
> Definitely a bug in LLDB somewhere, or possibly in the memory allocation
> on the MIPS host that is done via lldb-server. Are you using lldb-server
> here? It has an allocate memory packet.
>
> > I suspect the evaluator allocates the memory for data and releases once
> the expression has been executed?
>
> We allocate memory for the resulting data that continues to exist in your
> process so the memory shouldn't be released.
>
> > If so, can you please advise what's the proper way to achieve the same
> functionality?
>
> This should work so it will be a matter of tracking down what is actually
> failing. If you can run to where you want to run your expression and then
> before you run your expression do:
>
> (lldb) log enable -f /tmp/log.txt gdb-remote packets
> (lldb) log enable -f /tmp/log.txt lldb expr
>
> Then run your expression and then do:
>
> (lldb) log disable gdb-remote packets
> (lldb) log disable lldb expr
>
> Then send the file, we might be able to see what is going on. The GDB
> remote packets will allow us to see the memory that is allocated, and the
> "lldb expr" will allow us to see all of the gory details as to where it is
> trying to use "d".
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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 specific test we have to specify the "-f" option to
dotest.py and it takes the fully qualified function name as an argument.
Before your change it was displayed in the test output (in a bit
uncomfortable way) but after your change we have to open the test file and
copy the class name from there to run only a single test suit.
* With the new output format the output of the buildbot only displays the
list of the failing test function names what isn't too specific in a lot of
case (e.g. we have several test method called test_dwarf). This point is
less important as the file name can be added to the output from the
buildbot perspective.

Thanks,
Tamas

On Wed, Dec 9, 2015 at 7:57 PM Ying Chen  wrote:

> I submitted this patch to include "ERROR" lines in buildbot step results.
> http://reviews.llvm.org/rL255145
>
> Error results will be displayed in step result like this after the patch,
> "ERROR: 9 (SIGKILL) test_buildbot_catches_exceptional_exit_dwarf"
>
> Thanks,
> Ying
>
> On Wed, Dec 9, 2015 at 10:45 AM, Todd Fiala  wrote:
>
>> Great, thanks Tamas!
>>
>> I left the default turned on, and just essentially removed the issues by
>> parking them as .py.parked files.  That way we can flip them on in the
>> future if we want to verify a testbot's detection of these.
>>
>> I will be going back to the xUnit Results formatter and making sure it
>> maps timeouts and exceptional errors to the xUnit error type with details.
>>
>> On Wed, Dec 9, 2015 at 10:30 AM, Tamas Berghammer > > wrote:
>>
>>> 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
>>>
>>> On Wed, Dec 9, 2015 at 6:26 PM Todd Fiala  wrote:
>>>
 The reports look good at the test level:


 http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/9294

 I'd say the buildbot reflection script missed the ERROR, so that is
 something maybe Ying can look at (the summary line in the build run), but
 that is unrelated AFAICT.

 I'm going to move aside the failures.

 On Wed, Dec 9, 2015 at 10:13 AM, Todd Fiala 
 wrote:

> I am going to stop the current build on that builder.  There was one
> change in it, and it will be another 20 minutes before it completes.  I
> don't want the repo in a known broken state that long.
>
> On Wed, Dec 9, 2015 at 10:07 AM, Todd Fiala 
> wrote:
>
>> I forced a build on the ubuntu 14.04 cmake builder.  The build
>> _after_ 9292 will contain the two changes (and we will expect failures on
>> it).
>>
>> On Wed, Dec 9, 2015 at 10:05 AM, Todd Fiala 
>> wrote:
>>
>>> These went in as:
>>>
>>> r255130 - turn it on by default
>>> r255131 - create known issues.  This one is to be reverted if all 3
>>> types show up properly.
>>>
>>> On Wed, Dec 9, 2015 at 9:41 AM, Todd Fiala 
>>> wrote:
>>>
 It is a small change.

 I almost have all the trial tests ready, so I'll just commit both
 changes at the same time (the flip on, and the trial balloon issues).

 If all goes well and the three types of issue show up, then the
 last of the two will get reverted (the one with the failures).

 If none (or only some) of the issues show up, they'll both get
 reverted.

 -Todd

 On Wed, Dec 9, 2015 at 9:39 AM, Pavel Labath 
 wrote:

> If it's not too much work, I think the extra bit of noise will not
> be
> a problem. But I don't think it is really necessary either.
>
> I assume the actual flip will be a small change that we can back
> out
> easily if we notice troubles... After a sufficient grace period we
> can
> remove the old formatter altogether and hopefully simplify the code
> somewhat.
>
> pl
>
> On 9 December 2015 at 17:08, Todd Fiala 
> wrote:
> > Here's what I can do.
> >
> > Put in the change (setting the default to use the new format).
> >
> > Separately, put in a trial balloon commit with one failing test,
> one
> > 

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

[Tamas Berghammer via lldb-dev]

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

On Wed, Dec 9, 2015 at 6:26 PM Todd Fiala  wrote:

> The reports look good at the test level:
>
>
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/9294
>
> I'd say the buildbot reflection script missed the ERROR, so that is
> something maybe Ying can look at (the summary line in the build run), but
> that is unrelated AFAICT.
>
> I'm going to move aside the failures.
>
> On Wed, Dec 9, 2015 at 10:13 AM, Todd Fiala  wrote:
>
>> I am going to stop the current build on that builder.  There was one
>> change in it, and it will be another 20 minutes before it completes.  I
>> don't want the repo in a known broken state that long.
>>
>> On Wed, Dec 9, 2015 at 10:07 AM, Todd Fiala  wrote:
>>
>>> I forced a build on the ubuntu 14.04 cmake builder.  The build _after_
>>> 9292 will contain the two changes (and we will expect failures on it).
>>>
>>> On Wed, Dec 9, 2015 at 10:05 AM, Todd Fiala 
>>> wrote:
>>>
 These went in as:

 r255130 - turn it on by default
 r255131 - create known issues.  This one is to be reverted if all 3
 types show up properly.

 On Wed, Dec 9, 2015 at 9:41 AM, Todd Fiala 
 wrote:

> It is a small change.
>
> I almost have all the trial tests ready, so I'll just commit both
> changes at the same time (the flip on, and the trial balloon issues).
>
> If all goes well and the three types of issue show up, then the last
> of the two will get reverted (the one with the failures).
>
> If none (or only some) of the issues show up, they'll both get
> reverted.
>
> -Todd
>
> On Wed, Dec 9, 2015 at 9:39 AM, Pavel Labath 
> wrote:
>
>> If it's not too much work, I think the extra bit of noise will not be
>> a problem. But I don't think it is really necessary either.
>>
>> I assume the actual flip will be a small change that we can back out
>> easily if we notice troubles... After a sufficient grace period we can
>> remove the old formatter altogether and hopefully simplify the code
>> somewhat.
>>
>> pl
>>
>> On 9 December 2015 at 17:08, Todd Fiala  wrote:
>> > Here's what I can do.
>> >
>> > Put in the change (setting the default to use the new format).
>> >
>> > Separately, put in a trial balloon commit with one failing test, one
>> > exceptional exit test, and one timeout test, and watch the ubuntu
>> 14.04
>> > buildbot catch it and fail.  Then reverse this out.  That should
>> show beyond
>> > a reasonable doubt whether the buildbot catches new failures and
>> errors.  (I
>> > think this is a noisy way to accomplish this, but it certainly would
>> > validate if its working).
>> >
>> > -Todd
>> >
>> > On Wed, Dec 9, 2015 at 8:06 AM, Todd Fiala 
>> wrote:
>> >>
>> >> Specifically, the markers for issue details are:
>> >>
>> >> FAIL
>> >> ERROR
>> >> UNEXPECTED SUCCESS
>> >> TIMEOUT
>> >>
>> >> (These are the fourth field in the array entries (lines 275 - 290)
>> of
>> >> packages/Python/lldbsuite/test/basic_results_formatter.py).
>> >>
>> >> -Todd
>> >>
>> >> On Wed, Dec 9, 2015 at 8:04 AM, Todd Fiala 
>> wrote:
>> >>>
>> >>> That's a good point, Tamas.
>> >>>
>> >>> I use (so I claim) the same all upper-case markers for the test
>> result
>> >>> details.  Including, not using XPASS but rather UNEXPECTED
>> SUCCESS for
>> >>> unexpected successes.  (The former would trigger the lit script
>> IIRC to
>> >>> parse that as a failing-style result).
>> >>>
>> >>> The intent is this is a no-op on the test runner.
>> >>>
>> >>> On Wed, Dec 9, 2015 at 8:02 AM, Tamas Berghammer <
>> tbergham...@google.com>
>> >>> wrote:
>> 
>>  +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
>>   wrote:
>> >
>> > Hi all,
>> >
>> > Per a previous thread on this, I've made all the changes I
>> intended to
>> > make last night to get the intended replacement of test run
>> results meet or
>> > exceed current requirements.
>> >
>> > I'd like to switch over to that by 

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

[Tamas Berghammer via lldb-dev]

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 "libb.so" and when we debug again, we don't need to reload the debug
>> info for "libb.so" if it hasn't changed, we just reload "liba.so" and its
>> debug info. When we rerun a target (run a.out again), we don't need to
>> spend any time reloading any shared libraries that haven't changed since
>> they are still in our global shared library cache. So to keep this global
>> library cache clean, we don't allow types from another shared library
>> (libb.so) to be loaded into another (liba.so), otherwise we wouldn't be
>> able to reap the benefits of our shared library cache as we would always
>> need to reload debug info every time we run.
>>
>> Tangential: gdb starts up significantly faster than lldb. I wonder
>> what lldb is doing wrong.
>>
>> Oh, this is if I use the lldb that Apple supplied. If I compile my own
>> lldb with llvm-release, clang-release, and lldb-release, it takes like
>> 20x the time to start up: why is this? And if I use llvm-debug,
>> clang-debug, lldb-debug, the time it takes is completely unreasonable.
>>
>
> If you built your own you probably built a +Asserts build which slows
> things down a lot. You'll want to make sure you're building Release-Asserts
> (Release "minus" Asserts) builds if you want them to be usable.
>

What do you mean under startup speed and how do you measure it? I use
Release+Assert build of ToT LLDB on Linux and it takes significantly less
time for it to start up when debugging a large application (I usually test
with debug clang) then what you mentioned.

For me just to start up LLDB is almost instantaneous (~100ms) as it don't
parse any symbol or debug information at that time. If I trigger some debug
info parsing/indexing (with setting a breakpoint) then the startup time
will be around 3-5 seconds (40 core + ssd machine) what include an indexing
of all DIEs (it should be faster on darwin as the index is already in the
executable). On the other hand doing the same with gdb takes ~30 seconds
(independently if I set a breakpoint or not) because gdb parses all symbol
info at startup.

I would like to understand why are you seeing so slow startup time as I
worked on optimizing symbol parsing quite a bit in the last few month. Can
you send me some information about how you measure the startup time (lldb
commands, some info about the inferior) and can you do a quick profiling to
see where the time is spent?


>
>>
>> > LLDB currently recreates types in a clang::ASTContext and this imposes
>> much stricter rules on how we represent types which is one of the
>> weaknesses of the LLDB approach to type representation as the clang
>> codebase often asserts when it is not happy with how things are
>> represented. This does payoff IMHO in the complex expressions we can
>> evaluate where we can use flow control, define and use C++ lambdas, and
>> write more than one statement when writing expressions. But it is
>> definitely a tradeoff. GDB has its own custom type representation which can
>> be better for dealing with the different kinds and completeness of debug
>> info, but I am comfortable with our approach.
>>
>> Yeah, about that. I question the utility of evaluating crazy
>> expressions in lldb: I've not felt the need to do that even once, and
>> I suspect a large userbase is with me on this. What's important is
>> that lldb should _never_ fail to inspect a variable: isn't this the #1
>> job of the debugger?
>>
>
> Depends on the language - languages with more syntactic sugar basically
> need crazy expression evaluation to function very well in a debugger for
> the average user. (evaluating operator overloads in C++ expressions, just
> being able to execute non-trivial pretty-printers for interesting types
> (std::vector being a simple example, or a small-string optimized
> std::string, etc - let alone examples in ObjC or even Swift))
>

If you just want to inspect the content of a variable then I suggest to use
the "frame variable" command as it require significantly less context then
evaluating an expression. Unfortunately it can still fail in some cases
with the same lookup failure you see but it happens in significantly less
cases.


> - Dave
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

On Mon, Nov 30, 2015 at 10:18 AM haifeng_q <haifen...@foxmail.com> wrote:

> Question 1:
> On the windows, I use the code implements a function (see
> debug_target.cpp) of JIT (see debug_target_process.cpp), but when
> generating debug information, no production .symtab section for information
> that leads LLDB get JIT debugging information .symtab failure , and then
> set a breakpoint to fail.
>  LLDB command: lldb_result.txt
>  JIT compilation results: debug_target.ll
>
>  Question 2:
>  How JIT debugging supported on Linux?
>

I theory when a new function is JIT-ed then __jit_debug_register_code
function is called where LLDB have a breakpoint set. When that breakpoint
is hit then LLDB reads the JIT-ed elf file based on the information in
__it_debug_descriptor
and processes all debug info in it.

In practice when I last tried JIT debugging with lldb and lli (few weeks
ago) it get the notification for the new JIT-ed elf file but it processed
only the eh_frame from it even though symtab and full debug info was also
provided. Most likely there is some issue around the JIT breakpoint
handling or around the elf file parsing code in LLDB what needs
some investigation.

>
> thanks!
>
> -- The original message --
> *From:* "Zachary Turner";<ztur...@google.com>;
> *Data:* 2015年11月21日 AM 0:10
> *Receive:* "Tamas Berghammer"<tbergham...@google.com>; " "<
> 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 Berghammer via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> 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 will work or not.
>>
>> On Fri, Nov 20, 2015 at 8:56 AM haifeng_q <haifen...@foxmail.com> wrote:
>>
>>> My analysis of the code, the reasons are:
>>>
>>> Since the debugging process is MSVC compiler, there is no DWARF debugging
>>> information. So lldb get __jit_debug_register_code and
>>> __it_debug_descriptor symbol debugging process fails, and
>>> __jit_debug_register_code not support MSVC.
>>> I do not know whether correct?
>>>
>>> -- original message--
>>> *From:*"Tamas Berghammer";tbergham...@google.com;
>>> Date*:*2015年11月19日 PM 8:37
>>> *receive:* " "<haifen...@foxmail.com>; "lldb-dev"<
>>> lldb-dev@lists.llvm.org>;
>>> *Subject:* 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 understanding the eh_frame for the JIT-ed code but didn't found
>>> the debug info for unknown reason. We should investigate it and try to fix
>>> it sometime. We (lldb for android developers) plan to do it sometime but if
>>> you are interested in it then please feel free to take a look and let us
>>> know if you have any question.
>>>
>>> Tamas
>>>
>>> On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>>> hi,
>>>> process A generate function Func1 code with llvm jit compiler, and calls
>>>> Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug
>>>> information. how to use LLDB to attach process A to debug this function
>>>> , add a breakpoint in the function?
>>>>
>>>> thanks!
>>>> ___
>>>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 will work or not.

On Fri, Nov 20, 2015 at 8:56 AM haifeng_q  wrote:

> My analysis of the code, the reasons are:
>
> Since the debugging process is MSVC compiler, there is no DWARF debugging
> information. So lldb get __jit_debug_register_code and
> __it_debug_descriptor symbol debugging process fails, and
> __jit_debug_register_code not support MSVC.
> I do not know whether correct?
>
> -- original message--
> *From:*"Tamas Berghammer";tbergham...@google.com;
> Date*:*2015年11月19日 PM 8:37
> *receive:* " "; "lldb-dev";
>
> *Subject:* 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 understanding the eh_frame for the JIT-ed code but didn't found
> the debug info for unknown reason. We should investigate it and try to fix
> it sometime. We (lldb for android developers) plan to do it sometime but if
> you are interested in it then please feel free to take a look and let us
> know if you have any question.
>
> Tamas
>
> On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> hi,
>> process A generate function Func1 code with llvm jit compiler, and calls
>> Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug
>> information. how to use LLDB to attach process A to debug this function, add
>> a breakpoint in the function?
>>
>> thanks!
>> ___
>> 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

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

[Tamas Berghammer via lldb-dev]

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.llvm.org> wrote:

> Hi all,
>
> I've made a few changes to the Apple OS X buildbot today.  These are
> mostly minor, but the key is to make sure we all know when it's broken.
>
> First off, it now builds the lldb-tool scheme using the Debug
> configuration.  (Previously it was building a BuildAndIntegration
> configuration, which nobody outside Apple is ever going to be able to build
> right).
>
> Second, it no longer tries to build a signed debugserver and instead uses
> the system debugserver.
>
> At this point, if you get an email on a broken build, please make sure to
> do the typical courteous thing and (1) fix it if you know how, (2) reach
> out and ask us if we know how if it is a platform-specific issue, or (3)
> revert until we figure out a way to get it working for everyone.
>
> You can get to the builder here:
> http://lab.llvm.org:8080/green/job/LLDB/
>
> It's part of the newer Jenkins-style builders that llvm.org has been
> trying out.
>
> It is configured to send emails on a transition from green to red.
>
> Here's the current green build:
> http://lab.llvm.org:8080/green/job/LLDB/13827/
>
> Thanks!
> --
> -Todd
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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 check if the same is happening in your case as it might help finding
out the root cause.

In my case the issue is that we somehow end up with 2 FilldDecl object for
a given field inside one of the CXXRecordDecl object and then when we are
doing a pointer based lookup we will go wrong. I haven't figured out why it
is happening and haven't manage to reproduce it reliably either, but plan
to look into it in the near future if nobody beats me.

Tamas

On Wed, Oct 21, 2015 at 4:46 PM Ramkumar Ramachandra via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> So first, an addendum: I found a way to make the project build without
> using a symlink, and use a direct reference instead. The problem still
> persists. It may be that symlink is one of the problems, but it is
> certainly not the only problem.
>
> On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton  wrote:
> > int
> > Declaration::Compare(const Declaration& a, const Declaration& b)
> > {
> > int result = FileSpec::Compare(a.m_file, b.m_file, true);
> > if (result)
>
> Wait, won't FileSpec::Compare be true iff a.m_file is the same as
> b.m_file (excluding symlink resolution)? If so, why are we putting the
> symlink-checking logic in the true branch of the original
> FileSpec::Compare? Aren't we expanding the scope of what we match,
> instead of narrowing it?
>
> > {
> > int symlink_result = result;
> > if (a.m_file.GetFilename() == b.m_file.GetFilename())
> > {
> > // Check if the directories in a and b are symlinks to each
> other
> > FileSpec resolved_a;
> > FileSpec resolved_b;
> > if (FileSystem::ResolveSymbolicLink(a.m_file,
> resolved_a).Success() &&
> > FileSystem::ResolveSymbolicLink(b.m_file,
> resolved_b).Success())
> > {
> > symlink_result = FileSpec::Compare(resolved_a,
> resolved_b, true);
>
> I'm confused. Shouldn't the logic be "check literal equality; if true,
> return immediately; if not, check equality with symlink resolution"?
>
> > }
> > }
> > if (symlink_result != 0)
> > return symlink_result;
> > }
> > if (a.m_line < b.m_line)
> > return -1;
> > else if (a.m_line > b.m_line)
> > return 1;
> > #ifdef LLDB_ENABLE_DECLARATION_COLUMNS
> > if (a.m_column < b.m_column)
> > return -1;
> > else if (a.m_column > b.m_column)
> > return 1;
> > #endif
> > return 0;
> > }
>
> Here's my version of the patch, although I'm not sure when the code
> will be reached.
>
> int
> Declaration::Compare(const Declaration& a, const Declaration& b)
> {
> int result = FileSpec::Compare(a.m_file, b.m_file, true);
> if (result)
> return result;
> if (a.m_file.GetFilename() == b.m_file.GetFilename()) {
> // Check if one of the directories is a symlink to the other
> int symlink_result = result;
> FileSpec resolved_a;
> FileSpec resolved_b;
> if (FileSystem::ResolveSymbolicLink(a.m_file,
> resolved_a).Success() &&
> FileSystem::ResolveSymbolicLink(b.m_file,
> resolved_b).Success())
> {
> symlink_result = FileSpec::Compare(resolved_a, resolved_b,
> true);
> if (symlink_result)
> return symlink_result;
> }
> }
> if (a.m_line < b.m_line)
> return -1;
> else if (a.m_line > b.m_line)
> return 1;
> #ifdef LLDB_ENABLE_DECLARATION_COLUMNS
> if (a.m_column < b.m_column)
> return -1;
> else if (a.m_column > b.m_column)
> return 1;
> #endif
> return 0;
> }
>
> If you're confident that this solves a problem, I can send it as a
> code review or something (and set up git-svn, sigh).
> ___
> 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

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

[Tamas Berghammer via lldb-dev]

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 that category)
* If it fails 2 times in a row then record it as a failure because a flakey
test should pass at least once in every 2 run (it means we need ~95%
success rate to keep the build bot green in most of the time). If it isn't
passing often enough for that then it should be marked as expected failure.
This is done this way to detect the case when a flakey test get broken
completely by a new change.

I checked some states for TestRaise on the build bot and in the current
definition of expected flakey we shouldn't mark it as flakey because it
will often fail 2 times in a row (it passing rate is ~50%) what will be
reported as a failure making the build bot red.

I will send you the full stats from the lass 100 build in a separate off
list mail as it is a too big for the mailing list. If somebody else is
interested in it then let me know.

Tamas

On Sun, Oct 18, 2015 at 2:18 AM Todd Fiala  wrote:

> Nope, no good either when I limit the flakey to DWO.
>
> So perhaps I don't understand how the flakey marking works.  I thought it
> meant:
> * run the test.
> * If it passes, it goes as a successful test.  Then we're done.
> * run the test again.
> * If it passes, then we're done and mark it a successful test.  If it
> fails, then mark it an expected failure.
>
> But that's definitely not the behavior I'm seeing, as a flakey marking in
> the above scheme should never produce a failing test.
>
> I'll have to revisit the flakey test marking to see what it's really doing
> since my understanding is clearly flawed!
>
> On Sat, Oct 17, 2015 at 5:57 PM, Todd Fiala  wrote:
>
>> Hmm, the flakey behavior may be specific to dwo.  Testing it locally as
>> unconditionally flaky on Linux is failing on dwarf.  All the ones I see
>> succeed are dwo.  I wouldn't expect a diff there but that seems to be the
>> case.
>>
>> So, the request still stands but I won't be surprised if we find that dwo
>> sometimes passes while dwarf doesn't (or at least not enough to get through
>> the flakey setting).
>>
>> On Sat, Oct 17, 2015 at 4:57 PM, Todd Fiala  wrote:
>>
>>> Hi Tamas,
>>>
>>> I think you grabbed me stats on failing tests in the past.  Can you dig
>>> up the failure rate for TestRaise.py's test_restart_bug() variants on
>>> Ubuntu 14.04 x86_64?  I'd like to mark it as flaky on Linux, since it is
>>> passing most of the time over here.  But I want to see if that's valid
>>> across all Ubuntu 14.04 x86_64.  (If it is passing some of the time, I'd
>>> prefer marking it flakey so that we don't see unexpected successes).
>>>
>>> Thanks!
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> After our last discussion, I thought about it some more and there are at
> least some problems with this.  The biggest problem is that with only a
> single process, you are doing all tests from effectively a single instance
> of LLDB.  There's a TestMultipleDebuggers.py for example, and whether or
> not that test passes is equivalent to whether or not the test suite can
> even work without dying horribly.  In other words, you are inherently
> relying on multiple debuggers working to even run the test suite.
>
> I don't know if that's a problem, but at the very least, it's kind of
> unfortunate.  And of course the problem grows to other areas.  What other
> things fail horribly when a single instance of LLDB is debugging 100
> processes at the same time?
>
> It's worth adding this as an alternate run mode, but I don't think we
> should make it default until it's more battle-tested.
>
> On Mon, Sep 21, 2015 at 12:49 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I'm considering changing the default lldb test runner from
>> multiprocessing-based to threading-based.  Long ago I switched it from
>> threading to multiprocessing.  The only reason I did this was because OS X
>> was failing to allow more than one exec at a time in the worker threads -
>> way down in the Python Global Interpreter Lock (GIL).  And, at the time, I
>> didn't have the time to break out the test runner strategies.
>>
>> We have verified the threading-based issue is no longer manifesting on OS
>> X 10.10 and 10.11 beta.  That being the case, I'd like to convert us back
>> to being threading-based by default.  Specifically, this will have the same
>> effect as doing the following:
>> (non-Windows): --test-runner-name threading
>> (Windows): --test-runner-name threading-pool
>>
>> There are a couple benefits here:
>> 1. We'll remove a fork for creating the worker queues.  Each of those are
>> just threads when using threading, rather than being forked processes.
>> Depending on the underlying OS, a thread is typically cheaper.  Also, some
>> of the inter-worker communication now becomes cheap intra-process
>> communication instead of heavier multiprocessing constructs.
>> 2. Debugging is a bit easier.  The worker queues make a lot of noise in
>> 'ps aux'-style greps, and are a pain to debug relatively speaking vs. the
>> threaded version.
>>
>> I'm not yet looking to remove the multiprocessing support.  It is likely
>> I'll check the OS X version and default to the multiprocessing test runner
>> if it wasn't explicitly specified and the OS X version is < 10.10 as I'm
>> pretty sure I hit the issue on 10.9's python.
>>
>> Thoughts?
>> --
>> -Todd
>> ___
>> 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 mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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 a
general idea about what is happening.

I will try to create a statistic where the results are displayed separately
for each compiler and architecture to get a bit more detailed view, but it
will take some time. If you want I can include the list of build numbers
for all outcome, but it will be a very log list (currently only included
for Timeout and Failure)

Tamas

On Mon, Sep 14, 2015 at 11:24 PM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On an Ubuntu 14.04 x86_64 system, I'm seeing the following results:
>
> *cmake/ninja/clang-3.6:*
>
> Testing: 395 test suites, 24 threads
> 395 out of 395 test suites processed - TestGdbRemoteKill.py
> Ran 395 test suites (0 failed) (0.00%)
> Ran 478 test cases (0 failed) (0.00%)
>
> Unexpected Successes (6)
> UNEXPECTED SUCCESS: LLDB (suite) :: TestConstVariables.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestEvents.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestMiBreak.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestMiGdbSetShow.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestMiInterpreterExec.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestMiSyntax.py
>
>
> *cmake/ninja/gcc-4.9.2:*
>
> 395 out of 395 test suites processed - TestMultithreaded.py
> Ran 395 test suites (1 failed) (0.253165%)
> Ran 457 test cases (1 failed) (0.218818%)
> Failing Tests (1)
> FAIL: LLDB (suite) :: TestRegisterVariables.py
>
> Unexpected Successes (6)
> UNEXPECTED SUCCESS: LLDB (suite) :: TestDataFormatterSynth.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestMiBreak.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestMiGdbSetShow.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestMiInterpreterExec.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestMiSyntax.py
> UNEXPECTED SUCCESS: LLDB (suite) :: TestRaise.py
>
>
> I will look into those.  I suspect some of them are compiler-version
> specific, much like some of the OS X ones I dug into earlier.
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>


test-statistics
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Tamas Berghammer via lldb-dev]

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
list the failures displayed on the Web UI what don't contain full test
names and don't contain info about the UnexpectedSuccess-es. If you want to
download it from the web interface then I am pretty sure we have to parse
in the stdout of the test runner and change dotest in a way that it
displays more information about the outcome of the different tests.

On Tue, Sep 15, 2015 at 5:52 PM Todd Fiala  wrote:

> Yep looks like there's a decent interface to it.  Thanks, Siva!
>
> I see there's some docs here too:
> http://docs.buildbot.net/current/index.html
>
> On Tue, Sep 15, 2015 at 9:42 AM, Siva Chandra 
> wrote:
>
>> On Tue, Sep 15, 2015 at 9:25 AM, Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> > 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 data and to parse the test
>>> output from the test traces.
>>>
>>> Are the GCE logs public?  If not, do you know if our buildbot protocol
>>> supports polling this info via another method straight from the build bot?
>>>
>>
>> You are probably looking for this: http://lab.llvm.org:8011/json/help
>>
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev