Re: [lldb-dev] LLVM at FOSDEM 2016 - Call for papers and participation

[Renato Golin via lldb-dev]

Good news, folks!

Following FOSDEM's own delay on their schedule, we'll extend the
deadline until next Friday, 11th December.

cheers,
--renato


On 2 November 2015 at 13:32, Renato Golin  wrote:
> CALL FOR PAPERS / PARTICIPATION
>
> At FOSDEM 2016, LLVM will for the first time participate with a
> dedicated devroom. Complementing the upcoming Euro LLVM 2015, the
> devroom at FOSDEM provides a great opportunity for core LLVM developers
> and the wider open source community to get together, connect and discuss.
>
> As possibly the largest European Open Source Conference, FOSDEM takes
> place in Brussels and attracts with more than 400 lectures every year
> over 5000 hackers - many core contributors of the worlds leading open
> source projects.
>
>
> = Call for Speakers, Posters, Demos =
>
> We invite academic, industrial and hobbyist speakers to present their
> work on developing or using LLVM, Clang, LLDB, Polly, Compiler-RT, etc.
>
> We are looking for:
>
>   1. Keynote speakers.
>   2. Technical presentations (30 minutes plus questions and discussion)
>  related to development of LLVM, Clang etc.
>   3. Presentations about the use of LLVM, Clang in commercial or
>  academic projects as well as in the open source world.
>   4. Tutorials
>   5. Lightning talks (5 minutes)
>
> The deadline for receiving submissions is December 1st, 2015.  Speakers
> will be notified of acceptance or rejection by the 15th of December.
> Proposals that are not sufficiently detailed (talks lacking a
> comprehensive abstract for example) are likely to be rejected.
>
> Please create an account on the FOSDEM interface (
> https://penta.fosdem.org/user/new_account ) and submit your proposal
> ( https://penta.fosdem.org/submission/FOSDEM16/event/new ).
> Please make sure you select "LLVM devroom" as the "Track".
>
>
> = Registration =
>
> FOSDEM does not require any registration and is free of charge. However,
> just like last year, an important crowd must be expected.
>
>
> = Organization =
>
> The mailing list llvm-devr...@lists.fosdem.org can be used to discuss
> issues of general interest related to the conference organization.
>
>
> = Financial Support =
>
> There may be a possibility of limited funding to help students or
> contributors who could not otherwise attend the conference. This will
> depend on overall sponsorship and companies' interest in supporting the
> event.
>
> If you need funding to attend the meeting, or can help sponsor, please
> tell us on llvm-devr...@lists.fosdem.org.
>
>
> = About LLVM =
>
> LLVM is a collection of libraries and tools that make it easy to build
> compilers, optimizers, Just-In-Time code generators, and many other
> compiler-related programs.  LLVM uses a single, language-independent
> virtual instruction set both as an offline code representation (to
> communicate code between compiler phases and to run-time systems) and as
> the compiler internal  representation (to analyse and transform
> programs). This persistent code representation allows a common set of
> sophisticated compiler techniques to be applied at compile-time,
> link-time, install-time, run-time, or "idle-time" (between program runs).
>
> The strengths of the LLVM infrastructure are its extremely simple design
> (which makes it easy to understand and use), source-language
> independence, powerful mid-level optimizer, automated compiler debugging
> support, extensibility, and its stability and reliability. LLVM is
> currently being used to host a wide variety of academic research
> projects and commercial projects.
>
> Besides LLVM, several projects have been developed on top of it like
> Clang, LLDB, LLD or Polly.
>
> For more information, please visit http://llvm.org/ or the conference
> webpage at http://llvm.org/devmtg/2016-01/
>
>
> Tobias Grosser, Sylvestre Ledru & Renato Golin
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Greg Clayton via lldb-dev]

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

LLDB loads all shared libraries that it can when it first launches and GDB 
doesn't. In GDB you pay for this when you run your program. So if you want to 
compare things, do something like:

- get the current time as time1
- set an executable file in GDB and LLDB
- set a breakpoint
- run and hit the breakpoint
- get the current time as time2 and subtract from time1 and note time 
measurement.

Load GDB and LLDB up with a nice fat clang with debug info and the time to run 
to a breakpoint as a nice example. 

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

Not sure one this. 

Are you saying you build on MacOSX using the Xcode project and build the 
"Release" build configuration and it runs slower than the LLDB that is shipped 
by Apple? This shouldn't happen. One reason that this might be the case is the 
binaries you build are not stripped and have a TON of C++ names that are not 
exported through the LLDB.framework, but are in the symbol table. You can run 
"strip -Sx" on your LLDB.framework and it should remove these extra symbols.


> And if I use llvm-debug,
> clang-debug, lldb-debug, the time it takes is completely unreasonable.

Simple: optimized code is much faster

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

I agree with you on this. "frame variable" should never fail you as it doesn't 
use the expression parser. "frame variable" and its rock solid functionality is 
what IDEs use to display variables in variable views. So use "frame variable" 
and all will be good.

The expression parser is more complex and requires some special handling due to 
how we represent the ASTs as a single AST for all compile units within a module 
(executable/shared library). We use clang as the expression parser and this 
won't change so even if we tried to limit the expression parser to only do what 
the GDB expression parser does it won't help. So we need to tame the beast and 
we need to track down why things are not evaluating correctly when they do go 
wrong.

So please help us to track any issues down that we are having as one bug fix 
can often lead to fixing a whole variety of different issues.

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

[lldb-dev] [Bug 25703] New: test runner does not feed timeouts through the test event system

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25703

Bug ID: 25703
   Summary: test runner does not feed timeouts through the test
event system
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

The parallel test runner detects timeouts at the level of running the inferior
dotest.py process and having that take too long to finish.

The code in the parallel test runner that knows about the timeout doesn't have
a connection to the test event system.  It is the dotest inferior (the thing
that timed out and was killed because of it) that had the connection (via
socket) to report test events to the event collector.

When a timeout occurs, a test event should be generated and sent to the event
collector.  This likely will involve making a socket and connecting to the
event collector.

Once this is complete, a basic ResultsFormatter-based test results summary
generation should be able to entirely replace the legacy parallel test summary
output.  (Right now I can replace all of it but the timeout handling).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 25703] test runner does not feed timeouts through the test event system

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25703

Todd Fiala  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Greg Clayton via lldb-dev]

So one other issue with removing debug info from the current binary for base 
classes that are virtual: if the definition for the base class changes in 
libb.so, but liba.so was linked against an older version of class B from 
libb.so, like for example:

class A : public B
{
int m_a;
};

If A was linked against a B that looked like this:

class B
{
virtual ~B();
int m_b;
};

Then libb.so was rebuilt and B now looks like:

class B
{
virtual ~B();
virtual int foo();
int m_b;
int m_bb;
};

Then we when displaying an instance of "A" using in liba.so that was linked 
against the first version of B, we would actually show you the new version of 
"B" and everything would look like it was using the new definition for B, but 
liba.so is actually linked against the old instance and the code in class A 
would probably crash at some point due to the compilation mismatch, but the 
user would never really see actually what the original program was linked 
against and possibly be able to see the issue and realize they need to 
recompile liba.so against libb.so. If full debug info is emitted we would be 
able to show the original structure for B. Not an issue that people are always 
going to run into, but it is a reason that I like to have all the info complete 
in the current binary.

Greg

> On Nov 30, 2015, at 3:32 PM, David Blaikie  wrote:
> 
> 
> 
> On Mon, Nov 30, 2015 at 3:29 PM, Greg Clayton  wrote:
> 
> > On Nov 30, 2015, at 2:54 PM, David Blaikie  wrote:
> >
> >
> >
> > On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton  wrote:
> > >
> > > This will print out the complete class definition that we have for 
> > > "CG::Node" including ivars and methods. You should be able to see the 
> > > inheritance structure and you might need to also dump the type info for 
> > > each inherited class.
> > >
> > > Compilers have been trying to not output a bunch of debug info and in the 
> > > process they started to omit class info for base classes. So if you have:
> > >
> > > class A : public B
> > > {
> > > };
> > >
> > > where class "B" has all sorts of interesting methods, the debug info will 
> > > often look like:
> > >
> > > class B; // Forward declaration for class B
> > >
> > > class A : public B
> > > {
> > > };
> > >
> > > When this happens, we must make class A in a clang::ASTContext in 
> > > DWARFASTParserClang and if "B" is a forward declaration, we can't leave 
> > > it as a forward declaration or clang will assert and kill the debugger, 
> > > so currently we just say "oh well, the compiler gave us lame debug info, 
> > > and clang will crash if we don't fix this, so I am going to pretend we 
> > > have a definition for class B and it contains nothing".
> > >
> > > Why not lookup the definition of B in the debug info at this point rather 
> > > than making a stub/empty definition? (& if there is none, then, yes, I 
> > > suppose an empty definition of B is as good as anything, maybe - it's 
> > > going to produce some weird results, maybe)
> >
> > LLDB creates types using only the debug info from the currently shared 
> > library and we don't take a copy of a type from another shared library when 
> > creating the types for a given shared library. Why? LLDB has a global 
> > repository of modules (the class that represents an executable or shared 
> > library in LLDB). If Xcode, or any other IDE that can debug more that one 
> > thing at a time has two targets: "a.out" and "b.out", they share all of the 
> > shared library modules so that if debug info has already been parsed in the 
> > target for "a.out" for the shared library "liba.so" (or any other shared 
> > library), then the "b.out" target has the debug info already loaded for 
> > "liba.so" because "a.out" already loaded that module (LLDB runs in the same 
> > address space as our IDE). This means that all debug info in LLDB currently 
> > creates types using only the info in the current shared library. 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.
> >
> > Ah, right - I do remember you describing this to me before. Sorry I forgot.
> >
> > Wouldn't it be sufficient to just copy the definition when needed? If the 
> > type changes in an incompatible way in a 

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

[David Blaikie via lldb-dev]

On Tue, Dec 1, 2015 at 11:29 AM, Greg Clayton  wrote:

> So one other issue with removing debug info from the current binary for
> base classes that are virtual: if the definition for the base class changes
> in libb.so, but liba.so was linked against an older version of class B from
> libb.so, like for example:
>
> class A : public B
> {
> int m_a;
> };
>
> If A was linked against a B that looked like this:
>
> class B
> {
> virtual ~B();
> int m_b;
> };
>
> Then libb.so was rebuilt and B now looks like:
>
> class B
> {
> virtual ~B();
> virtual int foo();
> int m_b;
> int m_bb;
> };
>
> Then we when displaying an instance of "A" using in liba.so that was
> linked against the first version of B, we would actually show you the new
> version of "B" and everything would look like it was using the new
> definition for B, but liba.so is actually linked against the old instance
> and the code in class A would probably crash at some point due to the
> compilation mismatch, but the user would never really see actually what the
> original program was linked against and possibly be able to see the issue
> and realize they need to recompile liba.so against libb.so. If full debug
> info is emitted we would be able to show the original structure for B. Not
> an issue that people are always going to run into, but it is a reason that
> I like to have all the info complete in the current binary.
>

Sure - pretty substantial cost to pay (disk usage, link time, etc) & more
targeted features might be able to diagnose this more directly (& actually
diagnose it, rather than leaving it to the user to happen to look at the
debug info in a very specific way).

A DWARF linter (possibly built into a debugger) could catch /some/ cases of
the mismatch even with the minimal debug info (eg: if the offset of the
derived class's members don't make sense for the base class (if they
overlap with the base class's members because the base class got bigger, or
left a big gap because the base class got smaller, for example) it could
produce a warning)

A more tailored tool might just produce a table of type hashes of some kind.

- Dave


>
> Greg
>
> > On Nov 30, 2015, at 3:32 PM, David Blaikie  wrote:
> >
> >
> >
> > On Mon, Nov 30, 2015 at 3:29 PM, Greg Clayton 
> wrote:
> >
> > > On Nov 30, 2015, at 2:54 PM, David Blaikie  wrote:
> > >
> > >
> > >
> > > On Mon, Nov 30, 2015 at 2:42 PM, Greg Clayton 
> wrote:
> > > >
> > > > This will print out the complete class definition that we have for
> "CG::Node" including ivars and methods. You should be able to see the
> inheritance structure and you might need to also dump the type info for
> each inherited class.
> > > >
> > > > Compilers have been trying to not output a bunch of debug info and
> in the process they started to omit class info for base classes. So if you
> have:
> > > >
> > > > class A : public B
> > > > {
> > > > };
> > > >
> > > > where class "B" has all sorts of interesting methods, the debug info
> will often look like:
> > > >
> > > > class B; // Forward declaration for class B
> > > >
> > > > class A : public B
> > > > {
> > > > };
> > > >
> > > > When this happens, we must make class A in a clang::ASTContext in
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it
> as a forward declaration or clang will assert and kill the debugger, so
> currently we just say "oh well, the compiler gave us lame debug info, and
> clang will crash if we don't fix this, so I am going to pretend we have a
> definition for class B and it contains nothing".
> > > >
> > > > Why not lookup the definition of B in the debug info at this point
> rather than making a stub/empty definition? (& if there is none, then, yes,
> I suppose an empty definition of B is as good as anything, maybe - it's
> going to produce some weird results, maybe)
> > >
> > > LLDB creates types using only the debug info from the currently shared
> library and we don't take a copy of a type from another shared library when
> creating the types for a given shared library. Why? LLDB has a global
> repository of modules (the class that represents an executable or shared
> library in LLDB). If Xcode, or any other IDE that can debug more that one
> thing at a time has two targets: "a.out" and "b.out", they share all of the
> shared library modules so that if debug info has already been parsed in the
> target for "a.out" for the shared library "liba.so" (or any other shared
> library), then the "b.out" target has the debug info already loaded for
> "liba.so" because "a.out" already loaded that module (LLDB runs in the same
> address space as our IDE). This means that all debug info in LLDB currently
> creates types using only the info in the current shared library. When we
> debug "a.out" again, we might have recompiled "liba.so", but not "libb.so"
> and when we debug again, we don't 

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