Re: [lldb-dev] LLDB windows build and /bigobj

2016-02-09 Thread Reid Kleckner via lldb-dev 
Which object file has crossed the limit? When this has happened before,
this has usually highlighted over use of templates, which is worth fixing
because it speeds up builds on other platforms as well. If MSVC 2015
instead just happens to generate say one extra section per function, then
we should probably use bigobj.

On Tue, Feb 9, 2016 at 3:55 AM, Aidan Dodds via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi all,
>
> I pulled in recent changes to upstream llvm, clang and lldb and it seems
> to have tipped my windows build over the edge, and its complaining that
> my object files have exceeded the section limit.
> This error is raised while building the clang libraries.  Has anyone
> else seen this problem while doing an x64 build with with Visual Studio
> 2015?
>
> This problem can be fixed however by specifying /bigobj as a compiler
> flag.  The problem is however that this needs to be given to clang,
> which in turn inherits most of its cmake from llvm.
>
> I have attached my prospective patch for this issue, but wanted to check
> in with the lldb folk first to see if anyone has hit this issue, and if
> they would have any feedback before I submit it to llvm.
>
> Thanks,
> Aidan
>
> --
> Aidan Dodds
> staff software engineer, Debuggers
> Codeplay Software Ltd
> Level C, Argyle House, 3 Lady Lawson St.
> Edinbrgh, EH3 9DR
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
>
> This email and any attachments may contain confidential and /or privileged
> information and is for use by the addressee only. If you are not the
> intended recipient, please notify Codeplay Software Ltd immediately and
> delete the message from your computer. You may not copy or forward it,or
> use or disclose its contents to any other person. Any views or other
> information in this message which do not relate to our business are not
> authorized by Codeplay software Ltd, nor does this message form part of any
> contract unless so stated.
> As internet communications are capable of data corruption Codeplay
> Software Ltd does not accept any responsibility for any changes made to
> this message after it was sent. Please note that Codeplay Software Ltd does
> not accept any liability or responsibility for viruses and it is your
> responsibility to scan any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: 81 Linkfield Street, Redhill RH1 6BY
>
>
>
>
>
>
>
>
> ___
> 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] Clang macro debug info

2016-02-09 Thread Ewan Crawford via lldb-dev 

Hiya everyone,

I was wondering if anyone knows about the status of inspecting macros 
for objects compiled with clang.
Using either the DWARF 5 .debug_macro section or DWARF 4 .debug_macinfo 
section.


We can debug macros from gcc with -g3, but I can't seem to get clang to 
emit anything lldb can use.
Neither -gdwarf-4 or -gdwarf-5 look like they emit the necessary debug 
info.


Am I just compiling incorrectly or is clang(or lldb) missing some 
functionality?


Cheers,
 Ewan

--
Ewan Crawford
Software Engineer
Codeplay Software Ltd
Level C, Argyle House
3 Lady Lawson Street, Edinburgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged 
information and is for use by the addressee only. If you are not the intended 
recipient, please notify Codeplay Software Ltd immediately and delete the 
message from your computer. You may not copy or forward it,or use or disclose 
its contents to any other person. Any views or other information in this 
message which do not relate to our business are not authorized by Codeplay 
software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd 
does not accept any responsibility for any changes made to this message after 
it was sent. Please note that Codeplay Software Ltd does not accept any 
liability or responsibility for viruses and it is your responsibility to scan 
any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY

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

[lldb-dev] Running a single test

2016-02-09 Thread Ed Maste via lldb-dev 
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

Re: [lldb-dev] Running a single test

2016-02-09 Thread Zachary Turner via lldb-dev 
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

Re: [lldb-dev] LLDB windows build and /bigobj

2016-02-09 Thread Reid Kleckner via lldb-dev 
OK, we've had to change that several times now. At this point I think we
should just enable bigobj on that specific file. I'll try to prepare a
patch.

On Tue, Feb 9, 2016 at 9:52 AM, Aidan Dodds  wrote:

> Hi Reid,
> Thanks for taking a look at this.
> Here was the full error:
>
> llvm\tools\clang\lib\ASTMatchers\Dynamic\Registry.cpp : fatal error C1128: 
> number of sections exceeded object file format limit: compile with /bigobj
>
> That file seems to have quite a bit of macro magic going on, so I'll try
> to dig deeper into this when I'm back in the office tomorrow.
>
>
> On 09/02/2016 17:11, Reid Kleckner wrote:
>
> Which object file has crossed the limit? When this has happened before,
> this has usually highlighted over use of templates, which is worth fixing
> because it speeds up builds on other platforms as well. If MSVC 2015
> instead just happens to generate say one extra section per function, then
> we should probably use bigobj.
>
> On Tue, Feb 9, 2016 at 3:55 AM, Aidan Dodds via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I pulled in recent changes to upstream llvm, clang and lldb and it seems
>> to have tipped my windows build over the edge, and its complaining that
>> my object files have exceeded the section limit.
>> This error is raised while building the clang libraries.  Has anyone
>> else seen this problem while doing an x64 build with with Visual Studio
>> 2015?
>>
>> This problem can be fixed however by specifying /bigobj as a compiler
>> flag.  The problem is however that this needs to be given to clang,
>> which in turn inherits most of its cmake from llvm.
>>
>> I have attached my prospective patch for this issue, but wanted to check
>> in with the lldb folk first to see if anyone has hit this issue, and if
>> they would have any feedback before I submit it to llvm.
>>
>> Thanks,
>> Aidan
>>
>> --
>> Aidan Dodds
>> staff software engineer, Debuggers
>> Codeplay Software Ltd
>> Level C, Argyle House, 3 Lady Lawson St.
>> Edinbrgh, EH3 9DR
>> Tel: 0131 466 0503
>> Fax: 0131 557 6600
>> Website: http://www.codeplay.com
>> Twitter: https://twitter.com/codeplaysoft
>>
>> This email and any attachments may contain confidential and /or
>> privileged information and is for use by the addressee only. If you are not
>> the intended recipient, please notify Codeplay Software Ltd immediately and
>> delete the message from your computer. You may not copy or forward it,or
>> use or disclose its contents to any other person. Any views or other
>> information in this message which do not relate to our business are not
>> authorized by Codeplay software Ltd, nor does this message form part of any
>> contract unless so stated.
>> As internet communications are capable of data corruption Codeplay
>> Software Ltd does not accept any responsibility for any changes made to
>> this message after it was sent. Please note that Codeplay Software Ltd does
>> not accept any liability or responsibility for viruses and it is your
>> responsibility to scan any attachments.
>> Company registered in England and Wales, number: 04567874
>> Registered office: 81 Linkfield Street, Redhill RH1 6BY
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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] Clang macro debug info

2016-02-09 Thread Jim Ingham via lldb-dev 
You should ask on a clang list for a 100% correct answer, but I am pretty sure 
clang does not support macro information.  You can get somewhat the same result 
by building clang modules and importing them into lldb.  But you can't build 
modules for C++ yet, so you can only do this for C & ObjC programs.

Jim


> On Feb 9, 2016, at 9:08 AM, Ewan Crawford via lldb-dev 
>  wrote:
> 
> Hiya everyone,
> 
> I was wondering if anyone knows about the status of inspecting macros for 
> objects compiled with clang.
> Using either the DWARF 5 .debug_macro section or DWARF 4 .debug_macinfo 
> section.
> 
> We can debug macros from gcc with -g3, but I can't seem to get clang to emit 
> anything lldb can use.
> Neither -gdwarf-4 or -gdwarf-5 look like they emit the necessary debug info.
> 
> Am I just compiling incorrectly or is clang(or lldb) missing some 
> functionality?
> 
> Cheers,
> Ewan
> 
> -- 
> Ewan Crawford
> Software Engineer
> Codeplay Software Ltd
> Level C, Argyle House
> 3 Lady Lawson Street, Edinburgh, EH3 9DR
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
> 
> This email and any attachments may contain confidential and /or privileged 
> information and is for use by the addressee only. If you are not the intended 
> recipient, please notify Codeplay Software Ltd immediately and delete the 
> message from your computer. You may not copy or forward it,or use or disclose 
> its contents to any other person. Any views or other information in this 
> message which do not relate to our business are not authorized by Codeplay 
> software Ltd, nor does this message form part of any contract unless so 
> stated.
> As internet communications are capable of data corruption Codeplay Software 
> Ltd does not accept any responsibility for any changes made to this message 
> after it was sent. Please note that Codeplay Software Ltd does not accept any 
> liability or responsibility for viruses and it is your responsibility to scan 
> any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: 81 Linkfield Street, Redhill RH1 6BY
> 
> ___
> 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

2016-02-09 Thread Ed Maste via lldb-dev 
On 9 February 2016 at 17:19, Zachary Turner  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.

Ah yes, that works for -p, and explains why it worked for me before:
the tests themselves used to be in lldb/tests/... (that is,
subdirectories of dotest.py's location), so they were found without
specifying an explicit path. Thanks.
___
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

2016-02-09 Thread 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

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

2016-02-09 Thread Sean Callanan via lldb-dev 
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

Re: [lldb-dev] LLDB windows build and /bigobj

2016-02-09 Thread Aidan Dodds via lldb-dev 

Hi Reid,
Thanks for taking a look at this.
Here was the full error:

llvm\tools\clang\lib\ASTMatchers\Dynamic\Registry.cpp : fatal error C1128: 
number of sections exceeded object file format limit: compile with /bigobj

That file seems to have quite a bit of macro magic going on, so I'll try 
to dig deeper into this when I'm back in the office tomorrow.


On 09/02/2016 17:11, Reid Kleckner wrote:
Which object file has crossed the limit? When this has happened 
before, this has usually highlighted over use of templates, which is 
worth fixing because it speeds up builds on other platforms as well. 
If MSVC 2015 instead just happens to generate say one extra section 
per function, then we should probably use bigobj.


On Tue, Feb 9, 2016 at 3:55 AM, Aidan Dodds via lldb-dev 
> wrote:


Hi all,

I pulled in recent changes to upstream llvm, clang and lldb and it
seems
to have tipped my windows build over the edge, and its complaining
that
my object files have exceeded the section limit.
This error is raised while building the clang libraries. Has anyone
else seen this problem while doing an x64 build with with Visual
Studio
2015?

This problem can be fixed however by specifying /bigobj as a compiler
flag.  The problem is however that this needs to be given to clang,
which in turn inherits most of its cmake from llvm.

I have attached my prospective patch for this issue, but wanted to
check
in with the lldb folk first to see if anyone has hit this issue,
and if
they would have any feedback before I submit it to llvm.

Thanks,
Aidan

-- 
Aidan Dodds

staff software engineer, Debuggers
Codeplay Software Ltd
Level C, Argyle House, 3 Lady Lawson St.
Edinbrgh, EH3 9DR
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or
privileged information and is for use by the addressee only. If
you are not the intended recipient, please notify Codeplay
Software Ltd immediately and delete the message from your
computer. You may not copy or forward it,or use or disclose its
contents to any other person. Any views or other information in
this message which do not relate to our business are not
authorized by Codeplay software Ltd, nor does this message form
part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay
Software Ltd does not accept any responsibility for any changes
made to this message after it was sent. Please note that Codeplay
Software Ltd does not accept any liability or responsibility for
viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY








___
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