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

[haifeng_q via lldb-dev]

Problem solved. JIT debugging can be performed On the windows.
  
 thank you very much!
  
  
  --  The original message --
  From: "Oleksiy Vyalov";;
 Data: 2015??12??3??AM 10:16
 Receive: " "; 
 Cc: "Zachary Turner"; "lldb-dev"; 
"Tamas Berghammer"; 
 Title: Re: [lldb-dev] reply: reply?? lldb debug jit-compiled code with llvm on 
windows

 

 Could you re-build lldb with http://reviews.llvm.org/D15172 and try to hit a 
breakpoint in jit code?  

 I'm using following setup to compile and run JIT code:
 ./build_release/bin/clang -c -O0 -g -emit-llvm ./jit_test.cpp  
./build_release/bin/lli -debugger-tune=lldb -jit-kind=mcjit 
~/projects/lldb/test/jit_test.bc


 
 On Mon, Nov 30, 2015 at 3:47 AM, Tamas Berghammer via lldb-dev 
 wrote:
  

  On Mon, Nov 30, 2015 at 10:18 AM haifeng_q  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";;
 Data: 2015??11??21?? AM 0:10
 Receive: "Tamas Berghammer"; " 
"; "lldb-dev"; 
 
 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 
 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  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 
 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




 

-- 
  Oleksiy Vyalov | Software Engineer | ovya...@google.com___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Pavel Labath via lldb-dev]

There is already code that enforces unique names (see dotest.py:1255).
I added this a while back because we were getting test flakyness
because of that. I don't remember the exact reason but I think it had
something to do with the log file names clashes, as all logs are
placed in the same folder.

I agree that it is possible to have multiple test files with the same
name, and still have the names meaningful, but then we need to make
sure that the it actually works reliably.


As for the results formatter, I like the new output a lot. For me, the
inability to recognize crashes is a blocker for using it, but once
that works, I would definitely be in favor of making the default.


I would welcome shortening of the test names, but that is of secondary
significance for me.

great job,
pl


On 3 December 2015 at 06:20, Todd Fiala via lldb-dev
 wrote:
>
>
> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner  wrote:
>>
>>
>>
>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
>>>
>>>

 and the classname could be dropped (there's only one class per file
 anyway, so the classname is just wasted space)
>>>
>>>
>>> Part of the reason I included that is I've hit several times where copy
>>> and paste errors lead to the same class name, method name or even file name
>>> being used for a test.  I think, though, that most of those are addressed by
>>> having the path (relative is fine) to the python test file.  I think we can
>>> probably get by with classname.methodname (relative test path).  (From your
>>> other email, I think you nuke the classname and keep the module name, but
>>> I'd probably do the reverse, keeping the class name and getting rid of the
>>> module name since it can be derived from the filename).
>>
>> I don't think the filename can be the same anymore, as things will break
>> if two filenames are the same.
>
>
> Maybe, but that wasn't my experience as of fairly recently.  When tracking
> failures sometime within the last month, I tracked something down in a
> downstream branch with two same-named files that (with the legacy output)
> made it hard to track down what was actually failing given the limited info
> of the legacy test summary output.  Maybe that has changed since then, but
> I'm not aware of anything that would have prohibited that.
>
>>
>>   We could go one step further and enforce this in the part where it scans
>> for all the tests.
>
>
> I think I can come up with a valid counterargument to doing that.  I could
> imagine some python .py files being organized hierarchically, where some of
> the context of what is being tested clearly comes from the directory
> structure.
>
> Something like (I'm making this up):
>
> lang/c/const/TestConst.py
> lang/c++/const/TestConst.py
>
> where it seems totally reasonable to me to have things testing const support
> (in this example) but being very different things for C and C++, being
> totally uniqued by path rather than the .py file.  I'd prefer not to require
> something like this to say:
> lang/c/const/TestConstC.py
> lang/c++/const/TestConstC++.py
>
> as it is redundant (at least via the path hierarchy).
>
> The other reason I could see avoiding that
> unique-test-basenames-across-test-suite restriction is that it can become
> somewhat of an unnecessary burden on downstream branches.  Imagine somebody
> has a branch and has a test that happens to be running fine, then somebody
> in llvm.org lldb adds a test with the same name.  Downstream breaks.  We
> could choose to not care about that, but given that a lot of our tests will
> revolve around language features accessed/provided by the debugger, and a
> number of language features pull out of a limited set of feature names (e.g.
> const above), I could see us sometimes hitting this.
>
> Just one take on it.  I'm not particularly wedded to it (I probably would
> avoid the confusion by doing something exactly like what I said above with
> regards to tacking on the language to the test name), but I have hit this in
> similar form across different language tests.
>
>>
>>   If it finds two test files with the same name we could just generate an
>> error.  I think that's a good idea anyway, because if two test files have
>> the same name, then the tests inside must be similar enough to warrant
>> merging them into the same file.
>
>
> Maybe, but not in the real cases I saw across different languages.  I think
> for other areas of the debugger, this isn't an issue.  So maybe language
> feature tests just have to know to append their language (whether it be C,
> C++, ObjC, etc.)
>
>>
>>
>> If no two filenames are the same, and if there's only 1 class per file,
>> then filename + method name should uniquely identify a single test, and so
>> you could omit the class name and show a relative path to the filename.
>
>
> I think we currently have some tests that have multiple test classes in the
> test file.  We could certainly verify that in TOT, and we could certainly
> undo that which seems reaso

Re: [lldb-dev] New test summary results formatter

[Todd Fiala via lldb-dev]

On Thu, Dec 3, 2015 at 1:41 AM, Pavel Labath  wrote:

> There is already code that enforces unique names (see dotest.py:1255).
>

How long ago was that added?  I literally hit this within the last 6-8
weeks on something internal.


> I added this a while back because we were getting test flakyness
> because of that. I don't remember the exact reason but I think it had
> something to do with the log file names clashes, as all logs are
> placed in the same folder.
>
> I agree that it is possible to have multiple test files with the same
> name, and still have the names meaningful, but then we need to make
> sure that the it actually works reliably.
>
>
I really have no problem with this being forced.  With regards to other
repos, this is no different than using a shared library where a base class
may (in the future) add a method name that perturbs a downstream user
(subclass).  Removal of confusion trumps inconvenience in this case.  I'm
sold.


>
> As for the results formatter, I like the new output a lot.


Glad to hear that.  I'm looking forward to making it better.


> For me, the
> inability to recognize crashes is a blocker for using it, but once
> that works, I would definitely be in favor of making the default.
>
>
Yep, that and timeouts.  For us, we catch both on Jenkins and the Xunit
formatter only because the Xunit results gatherer also checks the output,
where the legacy summary support displays this information.  (I have the
new summary output wiring in the timeout data, but not the exceptional exit
(i.e. signal-based exit)) bits.

I'll be addressing both of those in the extremely near future.

I'll be depending on the test event infrastructure's ability to handle
re-runs to do the low-load, single-worker test pass, so I'm working on this
test summary bit first.  (And it's nice to have!).


>
> I would welcome shortening of the test names, but that is of secondary
> significance for me.
>
>
Ultimately I think it's fair to say "hey just put one test case class in a
file", and with a "test file base names must be unique" policy, I think we
can even get away with "test_method_name (relative filename)" to identify
the test method.  That should be even shorter than what Zachary and I were
discussing last night.


> great job,
> pl
>
>
Thanks for the feedback!

Hopefully this serves you as well, Dawn?


>
> On 3 December 2015 at 06:20, Todd Fiala via lldb-dev
>  wrote:
> >
> >
> > On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner 
> wrote:
> >>
> >>
> >>
> >> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
> >>>
> >>>
> 
>  and the classname could be dropped (there's only one class per file
>  anyway, so the classname is just wasted space)
> >>>
> >>>
> >>> Part of the reason I included that is I've hit several times where copy
> >>> and paste errors lead to the same class name, method name or even file
> name
> >>> being used for a test.  I think, though, that most of those are
> addressed by
> >>> having the path (relative is fine) to the python test file.  I think
> we can
> >>> probably get by with classname.methodname (relative test path).  (From
> your
> >>> other email, I think you nuke the classname and keep the module name,
> but
> >>> I'd probably do the reverse, keeping the class name and getting rid of
> the
> >>> module name since it can be derived from the filename).
> >>
> >> I don't think the filename can be the same anymore, as things will break
> >> if two filenames are the same.
> >
> >
> > Maybe, but that wasn't my experience as of fairly recently.  When
> tracking
> > failures sometime within the last month, I tracked something down in a
> > downstream branch with two same-named files that (with the legacy output)
> > made it hard to track down what was actually failing given the limited
> info
> > of the legacy test summary output.  Maybe that has changed since then,
> but
> > I'm not aware of anything that would have prohibited that.
> >
> >>
> >>   We could go one step further and enforce this in the part where it
> scans
> >> for all the tests.
> >
> >
> > I think I can come up with a valid counterargument to doing that.  I
> could
> > imagine some python .py files being organized hierarchically, where some
> of
> > the context of what is being tested clearly comes from the directory
> > structure.
> >
> > Something like (I'm making this up):
> >
> > lang/c/const/TestConst.py
> > lang/c++/const/TestConst.py
> >
> > where it seems totally reasonable to me to have things testing const
> support
> > (in this example) but being very different things for C and C++, being
> > totally uniqued by path rather than the .py file.  I'd prefer not to
> require
> > something like this to say:
> > lang/c/const/TestConstC.py
> > lang/c++/const/TestConstC++.py
> >
> > as it is redundant (at least via the path hierarchy).
> >
> > The other reason I could see avoiding that
> > unique-test-basenames-across-test-suite restriction is that it can become
> > somewhat of an unnecessary burd

[lldb-dev] Custom expression evaluation target options

[Luke Drummond via lldb-dev]

Hello all

I've recently tracked down a problem in the expression evaluation engine 
for lldb, and I'm hoping for some historical context, and possibly some 
direction on the most appropriate fix.


## Problem

I'd like to be able to set some target options for the JIT when calling 
`expr myRenderscriptFunction(some_arg)`, so that the JIT compiler 
generates calling code that matches a given calling convention.


Expression evaluation on x86 targets for our RenderScript 
LanguageRuntime requires the JIT to call a RenderScript function with a 
slightly different ABI than the default detected ABI for the module, 
(vectors are required to be passed in SSE registers) and there doesn't 
appear to be a way to configure the `Clang::Compiler` object used in 
`lldb_private::ClangExpressionParser` to use non-default code-generation 
options.


Unfortunately, for now there's no way to get the target options we need 
in `lldb_private::ClangExpressionParser`. It seems that the constructor 
for the ClangExpressionParser class hard-codes the target options based 
on some possibly broken assumptions on the target hardware and ABI 
available:



http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp?view=markup#l178

This has been marked a `TODO` in the source, so I've been working on the 
assumption that there is no currently implemented way to do this, and 
have been trying to work out the best way to approach this.


However, as any new implementation may involve touching codepaths I'm 
not particularly familiar with - or that other people are actively 
working on - I'd appreciate if anyone on list can suggest whether:


   1. There's a better way to do what I need (I hope this is the case).
   2. If not (1) whether the TODOs/FIXMEs in the current 
ClangExpressionParser implementation are being worked on already.


I notice that some of the folks at Imagination gave a similar problem 
statement on this list, back in April, and it was suggested they encode 
the processor specific features in the ELF header `e_flags` word (header 
offset 0x24).


http://lists.llvm.org/pipermail/lldb-dev/2015-April/007295.html

 I have checked the LLVM source tree, and it seems that there are no 
i386 specific flags specified at the present time, so this path doesn't 
solve the issue either.


http://llvm.org/docs/doxygen/html/Support_2ELF_8h_source.html

These flags seem to be little-used, and a quick search of my current 
Linux system's lib32 shared objects directory turned up only four files 
with non-zero e_flags in their header. I've not been able to track down 
what they mean (grepping GNU binutils was fruitless).


Any suggestions are welcome.

All the Best

Luke

--
Codeplay Software Ltd.
Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
https://www.codeplay.com
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Custom expression evaluation target options

[Greg Clayton via lldb-dev]

Each expression has a language so we should be able to get the Language* for 
renderscript:


lldb_private::Language* language = lldb_private::Language::FindPlugin 
(m_expr.GetLanguage());

Then you can add a new virtual class on lldb_private::Language that can get any 
additional compiler flags needed for expressions and just make it work? The 
renderscript language would set the appropriate ABI flags needed?

Greg


> On Dec 3, 2015, at 8:44 AM, Luke Drummond via lldb-dev 
>  wrote:
> 
> Hello all
> 
> I've recently tracked down a problem in the expression evaluation engine for 
> lldb, and I'm hoping for some historical context, and possibly some direction 
> on the most appropriate fix.
> 
> ## Problem
> 
> I'd like to be able to set some target options for the JIT when calling `expr 
> myRenderscriptFunction(some_arg)`, so that the JIT compiler generates calling 
> code that matches a given calling convention.
> 
> Expression evaluation on x86 targets for our RenderScript LanguageRuntime 
> requires the JIT to call a RenderScript function with a slightly different 
> ABI than the default detected ABI for the module, (vectors are required to be 
> passed in SSE registers) and there doesn't appear to be a way to configure 
> the `Clang::Compiler` object used in `lldb_private::ClangExpressionParser` to 
> use non-default code-generation options.
> 
> Unfortunately, for now there's no way to get the target options we need in 
> `lldb_private::ClangExpressionParser`. It seems that the constructor for the 
> ClangExpressionParser class hard-codes the target options based on some 
> possibly broken assumptions on the target hardware and ABI available:
> 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp?view=markup#l178
> 
> This has been marked a `TODO` in the source, so I've been working on the 
> assumption that there is no currently implemented way to do this, and have 
> been trying to work out the best way to approach this.
> 
> However, as any new implementation may involve touching codepaths I'm not 
> particularly familiar with - or that other people are actively working on - 
> I'd appreciate if anyone on list can suggest whether:
> 
>   1. There's a better way to do what I need (I hope this is the case).
>   2. If not (1) whether the TODOs/FIXMEs in the current ClangExpressionParser 
> implementation are being worked on already.
> 
> I notice that some of the folks at Imagination gave a similar problem 
> statement on this list, back in April, and it was suggested they encode the 
> processor specific features in the ELF header `e_flags` word (header offset 
> 0x24).
> 
>http://lists.llvm.org/pipermail/lldb-dev/2015-April/007295.html
> 
> I have checked the LLVM source tree, and it seems that there are no i386 
> specific flags specified at the present time, so this path doesn't solve the 
> issue either.
> 
>http://llvm.org/docs/doxygen/html/Support_2ELF_8h_source.html
> 
> These flags seem to be little-used, and a quick search of my current Linux 
> system's lib32 shared objects directory turned up only four files with 
> non-zero e_flags in their header. I've not been able to track down what they 
> mean (grepping GNU binutils was fruitless).
> 
> Any suggestions are welcome.
> 
> All the Best
> 
> Luke
> 
> -- 
> Codeplay Software Ltd.
> Level C, Argyle House, 3 Lady Lawson St, Edinburgh, EH3 9DR
> https://www.codeplay.com
> ___
> 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] New test summary results formatter

[Zachary Turner via lldb-dev]

On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:

> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner  wrote:
>
>>
>>
>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
>>
>>>
>>>
 and the classname could be dropped (there's only one class per file
 anyway, so the classname is just wasted space)

>>>
>>> Part of the reason I included that is I've hit several times where copy
>>> and paste errors lead to the same class name, method name or even file name
>>> being used for a test.  I think, though, that most of those are addressed
>>> by having the path (relative is fine) to the python test file.  I think we
>>> can probably get by with classname.methodname (relative test path).  (From
>>> your other email, I think you nuke the classname and keep the module name,
>>> but I'd probably do the reverse, keeping the class name and getting rid of
>>> the module name since it can be derived from the filename).
>>>
>> I don't think the filename can be the same anymore, as things will break
>> if two filenames are the same.
>>
>
> Maybe, but that wasn't my experience as of fairly recently.  When tracking
> failures sometime within the last month, I tracked something down in a
> downstream branch with two same-named files that (with the legacy output)
> made it hard to track down what was actually failing given the limited info
> of the legacy test summary output.  Maybe that has changed since then, but
> I'm not aware of anything that would have prohibited that.
>
Well I only said "things" will break, not everything will break.  Most
likely you just didn't notice the problem or it didn't present itself in
your scenario.  There are definitely bugs surrounding multiple files with
the same name, because of some places where we use a dictionary keyed on
filename.


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

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

Ahh I read further and see this was already mentioned by Pavel.

On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner  wrote:

> On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:
>
>> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner 
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
>>>


> and the classname could be dropped (there's only one class per file
> anyway, so the classname is just wasted space)
>

 Part of the reason I included that is I've hit several times where copy
 and paste errors lead to the same class name, method name or even file name
 being used for a test.  I think, though, that most of those are addressed
 by having the path (relative is fine) to the python test file.  I think we
 can probably get by with classname.methodname (relative test path).  (From
 your other email, I think you nuke the classname and keep the module name,
 but I'd probably do the reverse, keeping the class name and getting rid of
 the module name since it can be derived from the filename).

>>> I don't think the filename can be the same anymore, as things will break
>>> if two filenames are the same.
>>>
>>
>> Maybe, but that wasn't my experience as of fairly recently.  When
>> tracking failures sometime within the last month, I tracked something down
>> in a downstream branch with two same-named files that (with the legacy
>> output) made it hard to track down what was actually failing given the
>> limited info of the legacy test summary output.  Maybe that has changed
>> since then, but I'm not aware of anything that would have prohibited that.
>>
> Well I only said "things" will break, not everything will break.  Most
> likely you just didn't notice the problem or it didn't present itself in
> your scenario.  There are definitely bugs surrounding multiple files with
> the same name, because of some places where we use a dictionary keyed on
> filename.
>
>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB and Swift

[Todd Fiala via lldb-dev]

Hi all,

Earlier today, you may have heard that Swift went open source over at
swift.org.  I just wanted to take a moment to mention the Swift debugger
and REPL and how they relate to LLDB.

Swift’s Debugger and REPL are built on LLDB’s source-level plug-in
architecture.  As such, the Swift Debugger repository at
github.com/apple/swift-lldb naturally contains the LLDB source from llvm.org’s
LLDB repository, plus additions for Swift language support. We merge
regularly and make every attempt to minimize our differences with llvm.org’s
LLDB.  For more information on how we’re handling this, have a look at
swift.org/contributing/#llvm-and-swift.

As we’ve worked hard to make it straightforward to develop additive-only
language support in LLDB, the Swift support can readily be found by finding
the new files in the swift-lldb repository vs. those found at
llvm.org/svn/llvm-project/lldb/trunk.  For the rest of the LLDB files in
common, we do still have a small number of diffs in
github.com/apple/swift-lldb vs. llvm.org TOT.  We will work through
upstreaming these quickly.  I’ll touch on some of those differences briefly
here:

* Several minor places where full language abstraction hasn’t yet occurred,
where we’re explicitly checking for Swift-related details.  Abstracting out
those remaining places and providing the hooks in llvm.org LLDB will
benefit all languages.

* Printed-form version string handling.  The ‘lldb -v’ and ‘(lldb) version’
commands create a different version string in both Xcode and cmake-based
Swift LLDB.  We will work to incorporate this into llvm.org LLDB once the
language/component version support info is properly abstracted out.

* Test infrastructure.  There are a few places where Swift language support
(e.g. swift compiler flags, runtime support directories, etc.) are added in
order to enable building Swift-based test inferiors.  We may be able to
rearrange things to make those language-specific additions more readily
pluggable in the core LLDB test runner.

We look forward to upstreaming the differences in common files in the
coming days and weeks.

Please feel free to contact me if you have any questions.

Thanks!

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

[lldb-dev] LLDB using Valgrind's embedded gdbserver

[Daniel Trebbien via lldb-dev]

Hello,

I am working on enhancing Valgrind's embedded gdbserver to allow LLDB to
use it (https://bugs.kde.org/show_bug.cgi?id=356174 ).  After adding
support for 'qC' packets to the embedded gdbserver, LLDB is able to
continue the halted program running under Valgrind; however, a short moment
later LLDB crashes.

I am using OS X 10.11.1 (15B42) and lldb-340.4.110.1.

The location of the segmentation fault is
ABISysV_x86_64::GetArgumentValues(lldb_private::Thread&,
lldb_private::ValueList&) const + 147:

[  0] 0x00010432d7ad
LLDB`ABISysV_x86_64::GetArgumentValues(lldb_private::Thread&,
lldb_private::ValueList&) const + 147 at ABISysV_x86_64.cpp:485:32
   481  addr_t current_stack_argument = sp + 8; // jump over
return address
   482  
   483  uint32_t argument_register_ids[6];
   484  
-> 485  argument_register_ids[0] = reg_ctx->GetRegisterInfo
(eRegisterKindGeneric,
LLDB_REGNUM_GENERIC_ARG1)->kinds[eRegisterKindLLDB];


Someone at Apple Developer Relations (ADR) informed me that unlike
gdb, lldb does not have an initial target definition set, and relies
on the gdbserver to tell it which registers the gdbserver supports.
This can be done either by responding to 'qRegisterInfo XX' packets or
to 'qXfer:features:read:target.xml'.


ADR also informed me about the
plugin.process.gdb-remote.target-definition-file LLDB setting and the
example target definitions at
http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/

I can confirm that using either x86_64_linux_target_definition.py or
x86_64_target_definition.py fixes the segfault issue.


Valgrind's gdbserver does not support qRegisterInfo, but it does
support qXfer:features:read:target.xml.


Enabling LLDB's gdb-remote logging, I am seeing that the Valgrind
embedded gdbserver is sending:


target.xml:

```








  i386:x86-64
  
  
  


```


64bit-core.xml:

```






  

















  

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  

  
  
  
  
  
  
  
  


```


(64bit-sse.xml and 64bit-avx.xml omitted.)


Can anyone see why this XML target definition would be causing the crash?


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

Re: [lldb-dev] Exclusively build and install LLDB?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02.12.2015 19:36, Jim Ingham wrote:
> Todd is right, at runtime lldb does need to find some of the clang
> include files in order to build modules for its own purposes.  On
> an OS X install, these headers are put in:
> 
> LLDB.framework/Resources/Clang
> 
> and are:
> 
>> ls
> ./avx512vlbwintrin.h  lzcntintrin.h   
> stdatomic.h ../
> avx512vlintrin.h  mm3dnow.h   stdbool.h Intrin.h  
> avxintrin.h
> mm_malloc.h   stddef.h __stddef_max_align_t.h bmi2intrin.h
> mmintrin.hstdint.h __wmmintrin_aes.h  bmiintrin.h
> module.modulemap  stdnoreturn.h __wmmintrin_pclmul.h  cpuid.h
> nmmintrin.h   tbmintrin.h adxintrin.h emmintrin.h 
> pmmintrin.h
> tgmath.h altivec.hf16cintrin.hpopcntintrin.h  
> tmmintrin.h 
> ammintrin.h   float.h prfchwintrin.h  
> unwind.h arm_acle.h
> fma4intrin.h  rdseedintrin.h  vadefs.h arm_neon.h 
> fmaintrin.h
> rtmintrin.h   varargs.h avx2intrin.h  ia32intrin.h
> shaintrin.h
> wmmintrin.h avx512bwintrin.h  immintrin.h smmintrin.h 
> x86intrin.h 
> avx512erintrin.h  iso646.hstdalign.h  
> xmmintrin.h avx512fintrin.h
> limits.h  stdarg.hxopintrin.h
> 
> Other than that, lldb shouldn't need to install any other clang
> bits for its own purposes - and on OS X at least lldb only installs
> itself and not any of the clang binaries, so in practice this can
> be made to work.
> 
> Also, building lldb requires a lot of clang/llvm headers that I
> don't think get installed in the normal course of things.  So I'm
> not sure how easy it is going to be to build lldb against an
> installed llvm/clang.  I couldn't tell for sure whether this was
> another of your goals, but it may take a fair bit of monkeying
> around if you want to do things this way.
> 

It seems that the only library / header out of public includes is for
handling raw (in C) Regular Expressions. I have a work-in-progress
code switching to public llvm::Regex instead. Other then that, there
are minor changes in CMake.

I'm ignoring autoconf framework since it's marked to be abandoned.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWYN2hAAoJEEuzCOmwLnZsavoP/3sE59LBLSozwu5T9XOPh1oG
NpvpVFLvuyRgfb0JBEDQM/J13zbTTGSDl3A3IemvRA4Cvgeal34qKL4bsLSih3RF
fZ3699NAbmyFk92ePMIaLWFwmoiaBhboYHTR3sxiuhk0SHmPuK/PVuzD0xzPm4AC
AyqqdztkjTFZs5TyAg8vRJTlqY+VtPy4gcbG2DL0zECo1QRmsc+sFGkqmueYj7tc
5qgG7fcfswQ+gx5WFX652aksaep7ZsLpdgw3s9pFSdmAAu6PRo2CCXIYhllIHSPR
gdscSbI53LoNF5Z9ZWgDaYhEKkNKDlx9ib/zolUvNJfXuhm1yko2uPsis6XkVvBB
jsUbQ7VFLU+GYuHr6ys5qhHHEfTkAIhn9TZbhymJTt54eRPRONRmfaA6/PcZ3W+J
R/uJTNE9PvX9Hjhj2tV+59lSmrdlpmS6/9Akbv4lo3qkh2r4lJYVETpwlZv/IhJO
IHUcgdjVmFlmBC8p4nZhXxYLZiVjFT4sJr9JB/XZFkJWUajJNslIXr8hmhrzYnC1
ze71CXV4Z/q27KX3UeFmCcdudiviBA9IjzPhODknLVC60T+dIxI5C1yy1lfVnSx0
/FPurG255Eqg2sE2+DHUxIIJMfx2M8w4DrMCQAZEzO/hW+Ey05LH2fI43pcsduxF
SnkgZawyGkbQvn0NPI2M
=5u5p
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Exclusively build and install LLDB?

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Compatibility with wide range of LLVM or Clang releases is out of scope.

On 02.12.2015 17:38, Todd Fiala wrote:
> Yes, that concept came out in the thread.  I just wanted to make
> sure there wasn't also a desire to park on a version of llvm/clang,
> and if so, that the path there is not pleasant and definitely not
> intended to be supported on top of tree svn/trunk.
> 
> Thanks for clarifying!
> 
> -Todd
> 
> On Wed, Dec 2, 2015 at 8:34 AM, Pavel Labath  > wrote:
> 
> On 2 December 2015 at 16:19, Todd Fiala  > wrote:
>> Sorry for being late the the party here.
>> 
>> Sean Callanan and some of the other members can comment more on
>> this, but LLDB's expression parser for C/C++ is going to need
>> access to the clang include headers, so somehow lldb has to be
>> able to find them.  Out of tree llvm/clang usage is certainly
>> possible as others have pointed out.  Using that as the one way
>> it is done, though, is likely to lead to pain.  Parts of lldb's
>> source will adjust as needed when the API surface area of LLVM
>> or clang changes.  It may not be happening quite as frequently as
>> it had say 2 or 3 years ago, but it definitely happens.  So my
>> expectation would be that if you decouple lldb from llvm/clang
>> (i.e. let them drift), sooner or later you will get bitten by
>> that.  Particularly when things like clang modules and whatnot
>> come along and actually require different logic on the lldb side 
>> to deal with content generated on the clang/llvm side.  Once
>> expression evaluation is potentially compromised (due to the
>> drift), I suspect the lldb experience will degrade
>> significantly.
> 
> I think you have misunderstood our intentions here.
> 
> Kamil, correct me if I am wrong, but I don't think we are talking 
> about building lldb against a different version of clang. What we
> want is just to be able to build and link lldb against an
> already-built clang (of the same version). This is quite useful
> when you (as a distribution maintainer) want to provide prebuilt
> packages. So, for example you can have a "clang" and an "lldb"
> package. Users wishing to install clang, just get the first one,
> while someone installing lldb will get the correct clang package
> pulled automatically. I believe the easiest way to build these
> packages is to use the standalone mode of lldb (which already
> exists, and some people use that).
> 
> hope that makes sense, pl
> 
> 
> 
> 
> -- -Todd

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWYN6jAAoJEEuzCOmwLnZsdnsQAK7bn22uT/O61/QDF9oEYRlR
pzZtSkmGQZQuizw+TVUGgApk/KmwZ8BFsXUhguDzuDx8AR4qblYR+VwHSsQCaZwe
OIoZFTOOsmw5fBsbcYmtjlGsWOFQBWXOpMwXIZ5eQyQU8Q1rW2ssmniyfO7SkIE8
agcfzShyhzkFsQ9SLlHkZbNP+CALBVCOGWH4PnvdSkruIHKxmoOycgNvsG1HXsOV
jtgsx7S4EK1WEjPg3yzIiTgpYJVS2q3C2tLXmuYIg0TsNCwtoutSgodx6AV6Z31X
RbuDU8Gr4HqGZZa8LydRmoj2FRrkaMYEO2b8L9caQDRDCyn0TVEb6m5GSzut9EjP
+BKqeiNLaNVHIXjabsRf7a7tWpVSF0RH2vtyJOlXX1fisca4gWgpzLHY0u6IB37K
LnA4H1j/+f4ffOc1UpjFZs9Y6aTKLwAZaieZQXz8cRMueTpFBegla2osvY/Stg2f
OZnhzeUGcPVN2aERtR+HHxqWAZKHPHIPeTQTZ9vAEGF/KpedVrMEjgICCbisnLgQ
VNnm68m1aD8+30DNI70629JdmyjLGr5khzBmPipNqqZk8TB9Wn5HExTcSQod3fBP
+NHsaeucVcR0ZXL7vXM88yN28PRyHTGnVItAkSunsVCHwJ4WKtUyCHouSR2SMD2W
g0MvEbC3BKaPKRYB3WgB
=PHHJ
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

It would also be nice if the summary statistics were printed after the list
of failing / errored tests.  The reason is that it involves a fixed number
of lines to print the table, but the list of failures and errors is a
variable number of lines which could potentially be very long and push the
statistics off the screen.

On Thu, Dec 3, 2015 at 10:08 AM Zachary Turner  wrote:

> Ahh I read further and see this was already mentioned by Pavel.
>
> On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner  wrote:
>
>> On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:
>>
>>> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner 
>>> wrote:
>>>


 On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:

>
>
>> and the classname could be dropped (there's only one class per file
>> anyway, so the classname is just wasted space)
>>
>
> Part of the reason I included that is I've hit several times where
> copy and paste errors lead to the same class name, method name or even 
> file
> name being used for a test.  I think, though, that most of those are
> addressed by having the path (relative is fine) to the python test file.  
> I
> think we can probably get by with classname.methodname (relative test
> path).  (From your other email, I think you nuke the classname and keep 
> the
> module name, but I'd probably do the reverse, keeping the class name and
> getting rid of the module name since it can be derived from the filename).
>
 I don't think the filename can be the same anymore, as things will
 break if two filenames are the same.

>>>
>>> Maybe, but that wasn't my experience as of fairly recently.  When
>>> tracking failures sometime within the last month, I tracked something down
>>> in a downstream branch with two same-named files that (with the legacy
>>> output) made it hard to track down what was actually failing given the
>>> limited info of the legacy test summary output.  Maybe that has changed
>>> since then, but I'm not aware of anything that would have prohibited that.
>>>
>> Well I only said "things" will break, not everything will break.  Most
>> likely you just didn't notice the problem or it didn't present itself in
>> your scenario.  There are definitely bugs surrounding multiple files with
>> the same name, because of some places where we use a dictionary keyed on
>> filename.
>>
>>
>>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB and Swift

[Kamil Rytarowski via lldb-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Very nice. Congrats on your release!

On 04.12.2015 00:03, Todd Fiala via lldb-dev wrote:
> Hi all,
> 
> Earlier today, you may have heard that Swift went open source over 
> at swift.org .  I just wanted to take a moment
> to mention the Swift debugger and REPL and how they relate to
> LLDB.
> 
> Swift’s Debugger and REPL are built on LLDB’s source-level plug-in 
> architecture.  As such, the Swift Debugger repository at
> github.com/apple/swift-lldb 
> naturally contains the LLDB source from llvm.org
> ’s LLDB repository, plus additions for Swift
> language support. We merge regularly and make every attempt to 
> minimize our differences with llvm.org ’s LLDB.
> For more information on how we’re handling this, have a look at
> swift.org/contributing/#llvm-and-swift 
> .
> 
> As we’ve worked hard to make it straightforward to develop
> additive-only language support in LLDB, the Swift support can
> readily be found by finding the new files in the swift-lldb
> repository vs. those found at llvm.org/svn/llvm-project/lldb/trunk 
> .  For the rest of
> the LLDB files in common, we do still have a small number of diffs 
> in github.com/apple/swift-lldb 
> vs. llvm.org  TOT.  We will work through
> upstreaming these quickly.  I’ll touch on some of those differences
> briefly here:
> 
> * Several minor places where full language abstraction hasn’t yet 
> occurred, where we’re explicitly checking for Swift-related
> details. Abstracting out those remaining places and providing the
> hooks in llvm.org  LLDB will benefit all
> languages.
> 
> * Printed-form version string handling.  The ‘lldb -v’ and ‘(lldb) 
> version’ commands create a different version string in both Xcode
> and cmake-based Swift LLDB.  We will work to incorporate this into
> llvm.org  LLDB once the language/component
> version support info is properly abstracted out.
> 
> * Test infrastructure.  There are a few places where Swift
> language support (e.g. swift compiler flags, runtime support
> directories, etc.) are added in order to enable building
> Swift-based test inferiors.  We may be able to rearrange things to
> make those language-specific additions more readily pluggable in
> the core LLDB test runner.
> 
> We look forward to upstreaming the differences in common files in
> the coming days and weeks.
> 
> Please feel free to contact me if you have any questions.
> 
> Thanks!
> 
> -Todd
> 
> 
> ___ lldb-dev mailing
> list lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWYOYqAAoJEEuzCOmwLnZsyVMP/0pC9Vahn0ErYFeBQoaXA3Qx
FFr7dAIMAyC+tH0Rb2virNLsrozgNXAnV06vfS2fdt1nB2sVwFDeZvtscjRCY0BC
w8v5N0joKb0Ao2RJcazCLJYOEihTc9thsBSQFDzQ3UIMJ5f5FIhykcSDecIh3OTQ
Hb2FGzTsFbdRLQvu6XwagaxT0n5PL3IG7BIRVLgQl988ICJvGNFDub7/7Ylee52b
oLtkxRhMMn9n2UXGPahQ6WozKfjc/l5s6isAp3bdkH4GEyTIv+D7/CKUmvLyZxaP
L75JS0g/bb++uMY+2naKzCrTYm7Se2hopIvbvgf7vkTIrLBUZt8JtJ7qkKkiwTL3
iW4oOiXUTz0pFQ6g2vdCGBM1263iPxS816JxLtW+aB4Gj/qhuzoTTseb7+KvFCVs
5PG87p7L6pm5TKswX+Cf6Di0O5fqyUFwk06hB9wuck6iCbT5dl4Zkty0OKsh/mnb
RSztbQn9BpCbMDiZe2wv5y8H8kaMvaNvnODqNdK6C94M4km6AD7YNx0WFMPkPrL5
IfLzGZau89ejrmJIU9SKW7HJRn+luIxjr2sa3BVGV+cZP4wUm9Z+d91Q6DPXwKv0
MBdb7ISPGqW13yYHYJ9dK/pKFjHiMFMjIzBsMvItqvN3Xy3GmHDIm80G6jzu7Wj0
VipucL5yeiHkTIJNccs8
=qRiS
-END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB and Swift

[Todd Fiala via lldb-dev]

Thanks, Kamil!

-Todd

> On Dec 3, 2015, at 5:02 PM, Kamil Rytarowski  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Very nice. Congrats on your release!
> 
>> On 04.12.2015 00:03, Todd Fiala via lldb-dev wrote:
>> Hi all,
>> 
>> Earlier today, you may have heard that Swift went open source over 
>> at swift.org .  I just wanted to take a moment
>> to mention the Swift debugger and REPL and how they relate to
>> LLDB.
>> 
>> Swift’s Debugger and REPL are built on LLDB’s source-level plug-in 
>> architecture.  As such, the Swift Debugger repository at
>> github.com/apple/swift-lldb 
>> naturally contains the LLDB source from llvm.org
>> ’s LLDB repository, plus additions for Swift
>> language support. We merge regularly and make every attempt to 
>> minimize our differences with llvm.org ’s LLDB.
>> For more information on how we’re handling this, have a look at
>> swift.org/contributing/#llvm-and-swift 
>> .
>> 
>> As we’ve worked hard to make it straightforward to develop
>> additive-only language support in LLDB, the Swift support can
>> readily be found by finding the new files in the swift-lldb
>> repository vs. those found at llvm.org/svn/llvm-project/lldb/trunk 
>> .  For the rest of
>> the LLDB files in common, we do still have a small number of diffs 
>> in github.com/apple/swift-lldb 
>> vs. llvm.org  TOT.  We will work through
>> upstreaming these quickly.  I’ll touch on some of those differences
>> briefly here:
>> 
>> * Several minor places where full language abstraction hasn’t yet 
>> occurred, where we’re explicitly checking for Swift-related
>> details. Abstracting out those remaining places and providing the
>> hooks in llvm.org  LLDB will benefit all
>> languages.
>> 
>> * Printed-form version string handling.  The ‘lldb -v’ and ‘(lldb) 
>> version’ commands create a different version string in both Xcode
>> and cmake-based Swift LLDB.  We will work to incorporate this into
>> llvm.org  LLDB once the language/component
>> version support info is properly abstracted out.
>> 
>> * Test infrastructure.  There are a few places where Swift
>> language support (e.g. swift compiler flags, runtime support
>> directories, etc.) are added in order to enable building
>> Swift-based test inferiors.  We may be able to rearrange things to
>> make those language-specific additions more readily pluggable in
>> the core LLDB test runner.
>> 
>> We look forward to upstreaming the differences in common files in
>> the coming days and weeks.
>> 
>> Please feel free to contact me if you have any questions.
>> 
>> Thanks!
>> 
>> -Todd
>> 
>> 
>> ___ lldb-dev mailing
>> list lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJWYOYqAAoJEEuzCOmwLnZsyVMP/0pC9Vahn0ErYFeBQoaXA3Qx
> FFr7dAIMAyC+tH0Rb2virNLsrozgNXAnV06vfS2fdt1nB2sVwFDeZvtscjRCY0BC
> w8v5N0joKb0Ao2RJcazCLJYOEihTc9thsBSQFDzQ3UIMJ5f5FIhykcSDecIh3OTQ
> Hb2FGzTsFbdRLQvu6XwagaxT0n5PL3IG7BIRVLgQl988ICJvGNFDub7/7Ylee52b
> oLtkxRhMMn9n2UXGPahQ6WozKfjc/l5s6isAp3bdkH4GEyTIv+D7/CKUmvLyZxaP
> L75JS0g/bb++uMY+2naKzCrTYm7Se2hopIvbvgf7vkTIrLBUZt8JtJ7qkKkiwTL3
> iW4oOiXUTz0pFQ6g2vdCGBM1263iPxS816JxLtW+aB4Gj/qhuzoTTseb7+KvFCVs
> 5PG87p7L6pm5TKswX+Cf6Di0O5fqyUFwk06hB9wuck6iCbT5dl4Zkty0OKsh/mnb
> RSztbQn9BpCbMDiZe2wv5y8H8kaMvaNvnODqNdK6C94M4km6AD7YNx0WFMPkPrL5
> IfLzGZau89ejrmJIU9SKW7HJRn+luIxjr2sa3BVGV+cZP4wUm9Z+d91Q6DPXwKv0
> MBdb7ISPGqW13yYHYJ9dK/pKFjHiMFMjIzBsMvItqvN3Xy3GmHDIm80G6jzu7Wj0
> VipucL5yeiHkTIJNccs8
> =qRiS
> -END PGP SIGNATURE-
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Todd Fiala via lldb-dev]

That seems reasonable. I'll work that in.

-Todd

> On Dec 3, 2015, at 4:55 PM, Zachary Turner  wrote:
> 
> It would also be nice if the summary statistics were printed after the list 
> of failing / errored tests.  The reason is that it involves a fixed number of 
> lines to print the table, but the list of failures and errors is a variable 
> number of lines which could potentially be very long and push the statistics 
> off the screen.
> 
>> On Thu, Dec 3, 2015 at 10:08 AM Zachary Turner  wrote:
>> Ahh I read further and see this was already mentioned by Pavel.
>> 
>>> On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner  wrote:
 On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:
> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner  wrote:
> 
> 
>> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala  wrote:
>>  
>>> and the classname could be dropped (there's only one class per file 
>>> anyway, so the classname is just wasted space)
>> 
>> Part of the reason I included that is I've hit several times where copy 
>> and paste errors lead to the same class name, method name or even file 
>> name being used for a test.  I think, though, that most of those are 
>> addressed by having the path (relative is fine) to the python test file. 
>>  I think we can probably get by with classname.methodname (relative test 
>> path).  (From your other email, I think you nuke the classname and keep 
>> the module name, but I'd probably do the reverse, keeping the class name 
>> and getting rid of the module name since it can be derived from the 
>> filename).
> 
> I don't think the filename can be the same anymore, as things will break 
> if two filenames are the same.
 
 Maybe, but that wasn't my experience as of fairly recently.  When tracking 
 failures sometime within the last month, I tracked something down in a 
 downstream branch with two same-named files that (with the legacy output) 
 made it hard to track down what was actually failing given the limited 
 info of the legacy test summary output.  Maybe that has changed since 
 then, but I'm not aware of anything that would have prohibited that.
>>> 
>>> Well I only said "things" will break, not everything will break.  Most 
>>> likely you just didn't notice the problem or it didn't present itself in 
>>> your scenario.  There are definitely bugs surrounding multiple files with 
>>> the same name, because of some places where we use a dictionary keyed on 
>>> filename.
>>>  
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev