Re: [lldb-dev] something just toasted the test suite on OS X

2016-01-26 Thread Zachary Turner via lldb-dev 
No worries, worst case scenario a sledgehammer solution is to change all
the places where we write to the session file to convert to unicode first
(which would be a trivial conversion, since everything is going to be
ascii, which is already valid utf 8).

The reason a problem arose at all is because TestCxxWcharT.py tried to
write actual unicode characters to the session file.  I don't think there's
any way to prevent that because the characters could appear in a backtrace,
in a variable name, or in a test that is specifically testing unicode.  So
we can't just have the one place that needs to write unicode encode it as
bytes because there's no one place.

I'll sleep on it and try to see if there's a better solution.  Maybe we can
just make a function called write_session_file() that takes either a string
or a unicode, converts it to a unicode if it's not already one, and then
writes.

On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala  wrote:

> Okay we're back to green here:
> http://lab.llvm.org:8080/green/job/lldb_build_test/16173/
>
> Thanks, Enrico!
>
> Zachary, I may let this rest until the morning.  If you want to try
> something else, shoot me a patch and I'll gladly try it.
>
> -Todd
>
> On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala  wrote:
>
>> It's in item 3 from Effective Python, by Brett Slatkin, which goes over
>> having methods that always go to unicode or to byte streams taking either
>> unicode or byte style strings, for both Python 2 and Python 3.  Essentially
>> you figure out what you want it to be in, and you write a couple helper
>> routes to go in either the "to unicode" or the "to bytes" direction.  It
>> basically looks at the type of the string/bytes you give it, and makes sure
>> it becomes what you need.  It's going to assume an encoding like utf-8.
>>
>> On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
>> wrote:
>>
>>> I'm also not sure why Linux isn't failing.  Looking at the documentation
>>> for io.write object, i see this:
>>>
>>> write(*s*)
>>> 
>>>
>>> Write the unicode
>>>  string *s* to
>>> the stream and return the number of characters written.
>>> So clearly it does have to be a unicode object, and saying
>>> print(self.getvalue(), file=self.session) is clearly NOT printing a unicode
>>> string to the file.
>>>
>>> What's the pattern you're referring to?  You can't convert a string to a
>>> unicode without specifying an encoding, and it seems annoying to have to do
>>> that on every single call to print.
>>>
>>> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner 
>>> wrote:
>>>
 sorry, yea I stuck around for a while after that patch waiting for
 emails, but nothing came through.  Please revert in the meantime, I'll work
 on a fix tomorrow.

 On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> I think I see what happened w/r/t why no emails when out when the
> build went heavy red.  (Well they went out internally, but not
> externally).  When I made the change on Friday to improve the workflow for
> the Green Dragon OS X builder and test output, I switched email over to 
> the
> builder step, which doesn't know anything about who made which changes.  
> So
> it didn't know who to put on the blame list for the broken build.  Drats,
> I'll have to figure that out.
>
> I'd really prefer to have all those stages happening in one build step
> to keep it clear what's going on.
>
> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
> wrote:
>
>> Well our whole test suite just stopped running, so yes.
>>
>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>> wrote:
>>
>>>
>>> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Not sure exactly what it is, but all the tests are failing due to
>>> some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to 
>>> guess.
>>>
>>>
>>> Author: zturner
>>> Date: Mon Jan 25 18:59:42 2016
>>> New Revision: 258759
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
>>> Log:
>>> Write the session log file in UTF-8.
>>>
>>> Previously we were writing in the default encoding, which depends
>>> on the operating system and is not guaranteed to be unicode aware.
>>> On Python 3, this would lead to a situation where writing unicode
>>> text to the log file generates an exception.  The fix here is to
>>> write session logs using the proper encoding, which incidentally
>>> fixes another test, so xfail is removed from that.
>>>
>>> sounds like a likely culprit from what you’re saying
>>>
>>> I am not going to be able to look at details on that, but here's a
>>> link to the log on the OS X builder:
>>>
>>>
>

Re: [lldb-dev] Bad state of release 3.7.1?

2016-01-26 Thread Pavel Labath via lldb-dev 
Hello Jeffrey,

we did test 3.7 before letting it out, bug this bug was fixed only
after the release date, so the fix is not present in 3.7. I think you
have a couple of options now:
- backport the patch to 3.7: should be pretty easy and I expect it to
"just work"
- llvm 3.7 + lldb 3.8: this won't work out of the box as llvm
interfaces have changed. I don't think it would be too hard to make it
work, but you would be in totally unsupported waters there..
- switch to lldb 3.8: probably the easiest solution. Note that you can
still use llvm 3.7 in other parts of your toolchain, if you need it.
The only requirement is that you build lldb with the matching version
of llvm.

regards,
pl




On 26 January 2016 at 01:36, David Jones via lldb-dev
 wrote:
> r246756 has a fix, if you are comfortable applying it. It's a large patch.
> In theory it should back-port but I have not tried it.
>
> The API gap from 3.7.1 to 3.8 is quite minimal, so you should be able to get
> your applications running with 3.8 rather easily if they are running on
> 3.7.1 already.
>
>
> On Mon, Jan 25, 2016 at 7:40 PM, Jeffrey Tan 
> wrote:
>>
>> Btw: is there a fix that we can cherry pick? Or is it safe for us to build
>> lldb 3.8rc1 with llvm3.7.1?
>>
>> On Mon, Jan 25, 2016 at 4:34 PM, Jeffrey Tan 
>> wrote:
>>>
>>> Thanks David.
>>> I am new to lldb group but it's kind of surprise to me that the lldb on
>>> the official release page(http://llvm.org/releases/download.html#3.7.1) can
>>> have such big problems(can't attach/launch). Don't we fully test lldb before
>>> we post on the official website?
>>>
>>>
>>>
>>> On Mon, Jan 25, 2016 at 4:12 PM, David Jones 
>>> wrote:

 This is a known problem with 3.7.1.

 It should be fixed for 3.8. You should be able to try out 3.8rc1 right
 now.



 On Mon, Jan 25, 2016 at 5:37 PM, Jeffrey Tan via lldb-dev
  wrote:
>
> Hi,
>
> My colleague downloaded and built 3.7.1 version of lldb on Linux. When
> we used it to attach to a normal process(like sleep), it just hangs 
> forever:
>
> bin/lldb -n sleep
> (lldb) process attach --name "sleep"
>
> And my private built 3.8.0 version works fine.
>
> Just to confirm, is 3.7.1 a bad version? Is there any known issue about
> it?
>
> Thanks
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>

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

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

2016-01-26 Thread Pavel Labath via lldb-dev 
+ Omair

I don't really understand arm (sub)-architectures or REPL. The patch
seems mostly harmless, but it also feels like a hack to me. A couple
of questions:
- why does this only pose a problem for REPL?
- If I understand correctly, the problem is that someone is looking at
the architecture string contained in the Triple, and not finding what
it expects. Is that so? Could you point me to (some of) the places
that do that.

Omair, any thoughts on this?

cheers,
pl


On 25 January 2016 at 18:55, Hans Wennborg  wrote:
> This patch looks reasonable to me, but I don't know enough about LLDB
> to actually review it.
>
> +Renato or Pavel maybe?
>
> On Thu, Jan 14, 2016 at 11:32 AM, William Dillon via lldb-dev
>  wrote:
>> Hi again, everyone
>>
>> I’d like to ping on this patch now that the 3.8 branch is fairly new, and 
>> merging it over is fairly straight-forward.
>>
>> Thanks in advance for your comments!
>> - Will
>>
>>> There is a small change that enables correct calculation of arm sub 
>>> architectures while using the REPL on arm-linux.  As you may of may or may 
>>> not know, linux appends ‘l’ to arm architecture versions to denote little 
>>> endian.  This sometimes interferes with the determination of the 
>>> architecture in the triple.  I experimented with adding sub architecture 
>>> entries for these within lldb, but I discovered a simpler (and less 
>>> invasive) method.  Because LLVM already knows how to handle some of these 
>>> cases (I have a patch submitted for review that enables v6l; v7l already 
>>> works), I am relying on llvm to clean it up.  The gist of it is that the 
>>> llvm constructor (when given a triple string) retains the provided string 
>>> unless an accessor mutates it.  Meanwhile, the accessors for the components 
>>> go through the aliasing and parsing logic.  This code detects whether the 
>>> sub-architecture that armv6l or armv7l aliases to is detected, and re-sets 
>>> the architecture in the triple.  This overwrites the architecture that 
>>> comes from linux, thus sanitizing it.
>>>
>>> Some kind of solution is required for the REPL to work on arm-linux.  
>>> Without it, the REPL crashes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.8 Release] RC1 has been tagged

2016-01-26 Thread James Molloy via lldb-dev 
The test-suite shouldn't be being build with CMake for the release - the
CMake system is not yet ready. Have you accidentally checked out the
test-suite into /projects? if it's there it will auto-configure.

James

On Tue, 26 Jan 2016 at 16:01 Ismail Donmez via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Tue, Jan 26, 2016 at 1:56 PM, Nikola Smiljanic via llvm-dev
>  wrote:
> > Phase1 fails to build on openSUSE 13.2, can anyone see what's wrong from
> > this log file?
>
> Something wrong with the test-suite:
>
> make -f CMakeFiles/test-suite.dir/build.make
> CMakeFiles/test-suite.dir/depend
> make[2]: Entering directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/test-suite.dir/build.make:112: *** target pattern contains
> no '%'.  Stop.
> make[2]: Leaving directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/Makefile2:198: recipe for target
> 'CMakeFiles/test-suite.dir/all' failed
> make[1]: *** [CMakeFiles/test-suite.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.8 Release] RC1 has been tagged

2016-01-26 Thread Mehdi Amini via lldb-dev 
If the test-suite setup with CMake is broken, why not replace the CMake 
auto-detection of the test-suite with an error?
Something like:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index d96afc465177..918da6f6c945 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -693,11 +693,7 @@ endif()
 
 if( LLVM_INCLUDE_TESTS )
   if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite AND TARGET clang)
-include(LLVMExternalProjectUtils)
-llvm_ExternalProject_Add(test-suite 
${LLVM_MAIN_SRC_DIR}/projects/test-suite
-  USE_TOOLCHAIN
-  EXCLUDE_FROM_ALL
-  NO_INSTALL)
+message(FATAL_ERROR "The test-suite cannot be built in-tree with CMake at 
that time")
   endif()
   add_subdirectory(test)
   add_subdirectory(unittests)



— 
Mehdi


> On Jan 26, 2016, at 8:04 AM, James Molloy via cfe-dev 
>  wrote:
> 
> The test-suite shouldn't be being build with CMake for the release - the 
> CMake system is not yet ready. Have you accidentally checked out the 
> test-suite into /projects? if it's there it will auto-configure.
> 
> James
> 
> On Tue, 26 Jan 2016 at 16:01 Ismail Donmez via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> On Tue, Jan 26, 2016 at 1:56 PM, Nikola Smiljanic via llvm-dev
> mailto:llvm-...@lists.llvm.org>> wrote:
> > Phase1 fails to build on openSUSE 13.2, can anyone see what's wrong from
> > this log file?
> 
> Something wrong with the test-suite:
> 
> make -f CMakeFiles/test-suite.dir/build.make CMakeFiles/test-suite.dir/depend
> make[2]: Entering directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/test-suite.dir/build.make:112: *** target pattern contains
> no '%'.  Stop.
> make[2]: Leaving directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/Makefile2:198: recipe for target
> 'CMakeFiles/test-suite.dir/all' failed
> make[1]: *** [CMakeFiles/test-suite.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev 
> 
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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

Re: [lldb-dev] CFP for the 6th European LLVM conference on March 17-18, 2016 in Barcelona, Spain

2016-01-26 Thread Arnaud Allard de Grandmaison via lldb-dev 
For your information, we have decided to extend the CFP by a few days, up
to this Friday, May 29th.

So you still have 'till the end of this week to submit a presentation,
lightning talk, poster, tutorial or BoF to the EuroLLVM 2016.

Kind regards,
--
Arnaud A. de Grandmaison


On Sun, Dec 13, 2015 at 11:42 PM, Arnaud Allard de Grandmaison <
arnaud.ad...@gmail.com> wrote:

> We are pleased to announce the 6th European LLVM conference on March
> 17-18, 2016 in Barcelona, Spain.
>
> This will be a full two-day conference which aims to present the latest
> developments around LLVM and help strengthen the network of LLVM developers
> and users. The format will be similar to that of the previous meetings,
> with ample time for presentations, discussion, and networking between
> participants. The meeting is open to anyone whether from industry or
> academia, professional or enthusiast and is not restricted to those from
> Europe - attendees from all regions are welcome !
>
> EuroLLVM 2016 will be held at Princesa Sofia Hotel (
> http://www.princesasofia.com/en), collocated with the International
> Compiler Construction conference (http://cc2016.eew.technion.ac.il/) and
> CGO (http://cgo.org/cgo2016/)
>
> We invite academic, industrial and hobbyist speakers to present their work
> on developing or using LLVM, Clang, etc. Proposals for technical
> presentations, posters, workshops, demonstrations and BoFs are welcome.
> Material will be chosen to cover a broad spectrum of themes and topics at
> various depths, some technical deep-diving, some more community focused.
>
> We are looking for:
> - Keynote speakers.
> - Technical presentations (30 minutes plus questions and discussion)
> related to the development of LLVM, Clang, LLD, LLDB, Polly, ...
> - Presentations relating to academic or commercial use of LLVM, Clang
> etc.
> - Lightning talks (5 minutes, no questions, no discussion).
> - Workshops and in-depth tutorials (1-2 hours - please specify in your
> submission).
> - Poster presentations.
> - Birds of a Feather sessions (BoFs).
>
> **Important dates**
> The deadline for receiving submissions is January 25, 2016.
> Speakers will be notified of acceptance or rejection by February 15th,
> 2016.
>
> **Submissions**
> Submissions should be done using the Easychair platform:
> - https://easychair.org/conferences/?conf=eurollvm2016
>
> Please note that presentation materials and videos for the technical
> sessions will be posted on llvm.org after the conference. We have
> reserved additional spots for speakers, such that they can attend the
> conference even though we have reached our registration limit.
>
> In terms of submission style, we are looking for:
> - A title and an extended abstract,
> OR
> - A title, abstract and slides.
>
> Please make clear the status of the slides (are they a skeleton of your
> presentation with the detail missing ?), or, perhaps a section of detail
> that lacks introduction and conclusions?  Also make sure to give enough
> information in the extended abstract: the more you can give us and tell us
> the easier it will be for us to be positive about your submission.
>
> Proposals that are not sufficiently detailed (talks lacking a
> comprehensive abstract for example) are likely to be rejected. Slides and
> posters must be in PDF format.
>
> **About LLVM**
> The LLVM Infrastructure 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.
>
> For more information, please visit:
> - http://llvm.org/devmtg/2016-03/
>
> We are looking forward to seeing you in Barcelona !
> --
> Arnaud A. de Grandmaison
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] something just toasted the test suite on OS X

2016-01-26 Thread Zachary Turner via lldb-dev 
Can one of you guys try out this patch and see if it works?  If so I'll
commit it.

I don't know of a way to make this "elegant".  i.e. a single syntax /
paradigm that works in both versions without introducing any helper
functions.


On Tue, Jan 26, 2016 at 12:26 AM Zachary Turner  wrote:

> No worries, worst case scenario a sledgehammer solution is to change all
> the places where we write to the session file to convert to unicode first
> (which would be a trivial conversion, since everything is going to be
> ascii, which is already valid utf 8).
>
> The reason a problem arose at all is because TestCxxWcharT.py tried to
> write actual unicode characters to the session file.  I don't think there's
> any way to prevent that because the characters could appear in a backtrace,
> in a variable name, or in a test that is specifically testing unicode.  So
> we can't just have the one place that needs to write unicode encode it as
> bytes because there's no one place.
>
> I'll sleep on it and try to see if there's a better solution.  Maybe we
> can just make a function called write_session_file() that takes either a
> string or a unicode, converts it to a unicode if it's not already one, and
> then writes.
>
> On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala  wrote:
>
>> Okay we're back to green here:
>> http://lab.llvm.org:8080/green/job/lldb_build_test/16173/
>>
>> Thanks, Enrico!
>>
>> Zachary, I may let this rest until the morning.  If you want to try
>> something else, shoot me a patch and I'll gladly try it.
>>
>> -Todd
>>
>> On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala  wrote:
>>
>>> It's in item 3 from Effective Python, by Brett Slatkin, which goes over
>>> having methods that always go to unicode or to byte streams taking either
>>> unicode or byte style strings, for both Python 2 and Python 3.  Essentially
>>> you figure out what you want it to be in, and you write a couple helper
>>> routes to go in either the "to unicode" or the "to bytes" direction.  It
>>> basically looks at the type of the string/bytes you give it, and makes sure
>>> it becomes what you need.  It's going to assume an encoding like utf-8.
>>>
>>> On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
>>> wrote:
>>>
 I'm also not sure why Linux isn't failing.  Looking at the
 documentation for io.write object, i see this:

 write(*s*)
 

 Write the unicode
  string *s* to
 the stream and return the number of characters written.
 So clearly it does have to be a unicode object, and saying
 print(self.getvalue(), file=self.session) is clearly NOT printing a unicode
 string to the file.

 What's the pattern you're referring to?  You can't convert a string to
 a unicode without specifying an encoding, and it seems annoying to have to
 do that on every single call to print.

 On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner 
 wrote:

> sorry, yea I stuck around for a while after that patch waiting for
> emails, but nothing came through.  Please revert in the meantime, I'll 
> work
> on a fix tomorrow.
>
> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I think I see what happened w/r/t why no emails when out when the
>> build went heavy red.  (Well they went out internally, but not
>> externally).  When I made the change on Friday to improve the workflow 
>> for
>> the Green Dragon OS X builder and test output, I switched email over to 
>> the
>> builder step, which doesn't know anything about who made which changes.  
>> So
>> it didn't know who to put on the blame list for the broken build.  Drats,
>> I'll have to figure that out.
>>
>> I'd really prefer to have all those stages happening in one build
>> step to keep it clear what's going on.
>>
>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
>> wrote:
>>
>>> Well our whole test suite just stopped running, so yes.
>>>
>>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>>> wrote:
>>>

 On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

 Not sure exactly what it is, but all the tests are failing due to
 some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to 
 guess.


 Author: zturner
 Date: Mon Jan 25 18:59:42 2016
 New Revision: 258759

 URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
 Log:
 Write the session log file in UTF-8.

 Previously we were writing in the default encoding, which depends
 on the operating system and is not guaranteed to be unicode aware.
 On Python 3, this would lead to a situation where wri

[lldb-dev] [Bug 26322] New: Core load hangs

2016-01-26 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=26322

Bug ID: 26322
   Summary: Core load hangs
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: eugen...@hotmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

There are two problems with core load on Linux:

1. The thread ID are lost and there is FIXME in the code
2. If core dump is obtained from live process (i.e. gdb attach, gcore, detach)
then there is no thread that has any reason to stop. LLDB hangs forever on such
a core.

Here is the proposed fix for both:

diff --git a/include/lldb/Target/Process.h b/include/lldb/Target/Process.h
index 6bb7a3d..915ca15 100644
--- a/include/lldb/Target/Process.h
+++ b/include/lldb/Target/Process.h
@@ -3401,6 +3401,7 @@ protected:
 std::map m_resolved_indirect_addresses;
 bool m_destroy_in_process;
 bool m_can_interpret_function_calls; // Some targets, e.g the OSX kernel,
don't support the ability to modify the stack.
+bool m_load_core; // True if we are looking at a core dump, not at a
running program
 WarningsCollection  m_warnings_issued;  // A set of object
pointers which have already had warnings printed

 enum {
diff --git a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index 5b5d98a..fa057f1 100644
--- a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -559,11 +559,10 @@ ProcessElfCore::ParseThreadContextsFromNoteSegment(const
elf::ELFProgramHeader *
 have_prstatus = true;
 prstatus.Parse(note_data, arch);
 thread_data->signo = prstatus.pr_cursig;
+thread_data->tid = prstatus.pr_pid;
 header_size = ELFLinuxPrStatus::GetSize(arch);
 len = note_data.GetByteSize() - header_size;
 thread_data->gpregset = DataExtractor(note_data,
header_size, len);
-// FIXME: Obtain actual tid on Linux
-thread_data->tid = m_thread_data.size();
 break;
 case NT_FPREGSET:
 thread_data->fpregset = note_data;
diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp
index e4fe419..489b307 100644
--- a/source/Target/Process.cpp
+++ b/source/Target/Process.cpp
@@ -767,6 +767,7 @@ Process::Process(lldb::TargetSP target_sp, Listener
&listener, const UnixSignals
 m_last_broadcast_state (eStateInvalid),
 m_destroy_in_process (false),
 m_can_interpret_function_calls(false),
+m_load_core(false),
 m_warnings_issued (),
 m_can_jit(eCanJITDontKnow)
{
@@ -3088,6 +3089,7 @@ Process::LoadCore ()
 // We successfully loaded a core file, now pretend we stopped so we
can
 // show all of the threads in the core file and explore the crashed
 // state.
+m_load_core = true;
 SetPrivateState (eStateStopped);

 // Wait indefinitely for a stopped event since we just posted one
above...
@@ -3975,6 +3977,11 @@ Process::ShouldBroadcastEvent (Event *event_ptr)

 if (!was_restarted)
 should_resume = m_thread_list.ShouldStop (event_ptr) ==
false;
+
+ // ShouldStop() above has some side effects besides
calculating return value,
+ // so we better not skip it. But if we are loading core we
should not resume.
+ if (m_load_core)
+ should_resume = false;

 if (was_restarted || should_resume || m_resume_requested)
 {

-- 
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] something just toasted the test suite on OS X

2016-01-26 Thread Zachary Turner via lldb-dev 
Bump.  Can I re-submit this?

On Tue, Jan 26, 2016 at 10:54 AM Zachary Turner  wrote:

> Can one of you guys try out this patch and see if it works?  If so I'll
> commit it.
>
> I don't know of a way to make this "elegant".  i.e. a single syntax /
> paradigm that works in both versions without introducing any helper
> functions.
>
>
> On Tue, Jan 26, 2016 at 12:26 AM Zachary Turner 
> wrote:
>
>> No worries, worst case scenario a sledgehammer solution is to change all
>> the places where we write to the session file to convert to unicode first
>> (which would be a trivial conversion, since everything is going to be
>> ascii, which is already valid utf 8).
>>
>> The reason a problem arose at all is because TestCxxWcharT.py tried to
>> write actual unicode characters to the session file.  I don't think there's
>> any way to prevent that because the characters could appear in a backtrace,
>> in a variable name, or in a test that is specifically testing unicode.  So
>> we can't just have the one place that needs to write unicode encode it as
>> bytes because there's no one place.
>>
>> I'll sleep on it and try to see if there's a better solution.  Maybe we
>> can just make a function called write_session_file() that takes either a
>> string or a unicode, converts it to a unicode if it's not already one, and
>> then writes.
>>
>> On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala  wrote:
>>
>>> Okay we're back to green here:
>>> http://lab.llvm.org:8080/green/job/lldb_build_test/16173/
>>>
>>> Thanks, Enrico!
>>>
>>> Zachary, I may let this rest until the morning.  If you want to try
>>> something else, shoot me a patch and I'll gladly try it.
>>>
>>> -Todd
>>>
>>> On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala 
>>> wrote:
>>>
 It's in item 3 from Effective Python, by Brett Slatkin, which goes over
 having methods that always go to unicode or to byte streams taking either
 unicode or byte style strings, for both Python 2 and Python 3.  Essentially
 you figure out what you want it to be in, and you write a couple helper
 routes to go in either the "to unicode" or the "to bytes" direction.  It
 basically looks at the type of the string/bytes you give it, and makes sure
 it becomes what you need.  It's going to assume an encoding like utf-8.

 On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
 wrote:

> I'm also not sure why Linux isn't failing.  Looking at the
> documentation for io.write object, i see this:
>
> write(*s*)
> 
>
> Write the unicode
>  string *s* to
> the stream and return the number of characters written.
> So clearly it does have to be a unicode object, and saying
> print(self.getvalue(), file=self.session) is clearly NOT printing a 
> unicode
> string to the file.
>
> What's the pattern you're referring to?  You can't convert a string to
> a unicode without specifying an encoding, and it seems annoying to have to
> do that on every single call to print.
>
> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner 
> wrote:
>
>> sorry, yea I stuck around for a while after that patch waiting for
>> emails, but nothing came through.  Please revert in the meantime, I'll 
>> work
>> on a fix tomorrow.
>>
>> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> I think I see what happened w/r/t why no emails when out when the
>>> build went heavy red.  (Well they went out internally, but not
>>> externally).  When I made the change on Friday to improve the workflow 
>>> for
>>> the Green Dragon OS X builder and test output, I switched email over to 
>>> the
>>> builder step, which doesn't know anything about who made which changes. 
>>>  So
>>> it didn't know who to put on the blame list for the broken build.  
>>> Drats,
>>> I'll have to figure that out.
>>>
>>> I'd really prefer to have all those stages happening in one build
>>> step to keep it clear what's going on.
>>>
>>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
>>> wrote:
>>>
 Well our whole test suite just stopped running, so yes.

 On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata >>> > wrote:

>
> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Not sure exactly what it is, but all the tests are failing due to
> some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to 
> guess.
>
>
> Author: zturner
> Date: Mon Jan 25 18:59:42 2016
> New Revision: 258759
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
> Log:
> Write the session log file

Re: [lldb-dev] something just toasted the test suite on OS X

2016-01-26 Thread Todd Fiala via lldb-dev 
Oh missed this.  I'll give it a shot, hang on.

On Tue, Jan 26, 2016 at 5:14 PM, Zachary Turner  wrote:

> Bump.  Can I re-submit this?
>
> On Tue, Jan 26, 2016 at 10:54 AM Zachary Turner 
> wrote:
>
>> Can one of you guys try out this patch and see if it works?  If so I'll
>> commit it.
>>
>> I don't know of a way to make this "elegant".  i.e. a single syntax /
>> paradigm that works in both versions without introducing any helper
>> functions.
>>
>>
>> On Tue, Jan 26, 2016 at 12:26 AM Zachary Turner 
>> wrote:
>>
>>> No worries, worst case scenario a sledgehammer solution is to change all
>>> the places where we write to the session file to convert to unicode first
>>> (which would be a trivial conversion, since everything is going to be
>>> ascii, which is already valid utf 8).
>>>
>>> The reason a problem arose at all is because TestCxxWcharT.py tried to
>>> write actual unicode characters to the session file.  I don't think there's
>>> any way to prevent that because the characters could appear in a backtrace,
>>> in a variable name, or in a test that is specifically testing unicode.  So
>>> we can't just have the one place that needs to write unicode encode it as
>>> bytes because there's no one place.
>>>
>>> I'll sleep on it and try to see if there's a better solution.  Maybe we
>>> can just make a function called write_session_file() that takes either a
>>> string or a unicode, converts it to a unicode if it's not already one, and
>>> then writes.
>>>
>>> On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala  wrote:
>>>
 Okay we're back to green here:
 http://lab.llvm.org:8080/green/job/lldb_build_test/16173/

 Thanks, Enrico!

 Zachary, I may let this rest until the morning.  If you want to try
 something else, shoot me a patch and I'll gladly try it.

 -Todd

 On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala 
 wrote:

> It's in item 3 from Effective Python, by Brett Slatkin, which goes
> over having methods that always go to unicode or to byte streams taking
> either unicode or byte style strings, for both Python 2 and Python 3.
> Essentially you figure out what you want it to be in, and you write a
> couple helper routes to go in either the "to unicode" or the "to bytes"
> direction.  It basically looks at the type of the string/bytes you give 
> it,
> and makes sure it becomes what you need.  It's going to assume an encoding
> like utf-8.
>
> On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
> wrote:
>
>> I'm also not sure why Linux isn't failing.  Looking at the
>> documentation for io.write object, i see this:
>>
>> write(*s*)
>> 
>>
>> Write the unicode
>>  string *s* to
>> the stream and return the number of characters written.
>> So clearly it does have to be a unicode object, and saying
>> print(self.getvalue(), file=self.session) is clearly NOT printing a 
>> unicode
>> string to the file.
>>
>> What's the pattern you're referring to?  You can't convert a string
>> to a unicode without specifying an encoding, and it seems annoying to 
>> have
>> to do that on every single call to print.
>>
>> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner 
>> wrote:
>>
>>> sorry, yea I stuck around for a while after that patch waiting for
>>> emails, but nothing came through.  Please revert in the meantime, I'll 
>>> work
>>> on a fix tomorrow.
>>>
>>> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 I think I see what happened w/r/t why no emails when out when the
 build went heavy red.  (Well they went out internally, but not
 externally).  When I made the change on Friday to improve the workflow 
 for
 the Green Dragon OS X builder and test output, I switched email over 
 to the
 builder step, which doesn't know anything about who made which 
 changes.  So
 it didn't know who to put on the blame list for the broken build.  
 Drats,
 I'll have to figure that out.

 I'd really prefer to have all those stages happening in one build
 step to keep it clear what's going on.

 On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
 wrote:

> Well our whole test suite just stopped running, so yes.
>
> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata <
> egran...@apple.com> wrote:
>
>>
>> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Not sure exactly what it is, but all the tests are failing due to
>> some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had

Re: [lldb-dev] something just toasted the test suite on OS X

2016-01-26 Thread Todd Fiala via lldb-dev 
I'm still getting a lot of these:


Traceback (most recent call last):
  File "test/dotest.py", line 7, in 
lldbsuite.test.run_suite()
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/dotest.py",
line 1089, in run_suite
resultclass=test_result.LLDBTestResult).run(configuration.suite)
  File
"/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/runner.py",
line 162, in run
test(result)
  File
"/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
line 65, in __call__
return self.run(*args, **kwds)
  File
"/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
line 85, in run
self._wrapped_run(result)
  File
"/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
line 115, in _wrapped_run
test._wrapped_run(result, debug)
  File
"/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
line 117, in _wrapped_run
test(result)
  File
"/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/case.py",
line 433, in __call__
return self.run(*args, **kwds)
  File
"/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/case.py",
line 369, in run
self.dumpSessionInfo()
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1810, in dumpSessionInfo
print(u"Session info generated @", datetime.datetime.now().ctime(),
file=self.session)
TypeError: must be unicode, not str


On Tue, Jan 26, 2016 at 5:42 PM, Todd Fiala  wrote:

> Oh missed this.  I'll give it a shot, hang on.
>
> On Tue, Jan 26, 2016 at 5:14 PM, Zachary Turner 
> wrote:
>
>> Bump.  Can I re-submit this?
>>
>> On Tue, Jan 26, 2016 at 10:54 AM Zachary Turner 
>> wrote:
>>
>>> Can one of you guys try out this patch and see if it works?  If so I'll
>>> commit it.
>>>
>>> I don't know of a way to make this "elegant".  i.e. a single syntax /
>>> paradigm that works in both versions without introducing any helper
>>> functions.
>>>
>>>
>>> On Tue, Jan 26, 2016 at 12:26 AM Zachary Turner 
>>> wrote:
>>>
 No worries, worst case scenario a sledgehammer solution is to change
 all the places where we write to the session file to convert to unicode
 first (which would be a trivial conversion, since everything is going to be
 ascii, which is already valid utf 8).

 The reason a problem arose at all is because TestCxxWcharT.py tried to
 write actual unicode characters to the session file.  I don't think there's
 any way to prevent that because the characters could appear in a backtrace,
 in a variable name, or in a test that is specifically testing unicode.  So
 we can't just have the one place that needs to write unicode encode it as
 bytes because there's no one place.

 I'll sleep on it and try to see if there's a better solution.  Maybe we
 can just make a function called write_session_file() that takes either a
 string or a unicode, converts it to a unicode if it's not already one, and
 then writes.

 On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala 
 wrote:

> Okay we're back to green here:
> http://lab.llvm.org:8080/green/job/lldb_build_test/16173/
>
> Thanks, Enrico!
>
> Zachary, I may let this rest until the morning.  If you want to try
> something else, shoot me a patch and I'll gladly try it.
>
> -Todd
>
> On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala 
> wrote:
>
>> It's in item 3 from Effective Python, by Brett Slatkin, which goes
>> over having methods that always go to unicode or to byte streams taking
>> either unicode or byte style strings, for both Python 2 and Python 3.
>> Essentially you figure out what you want it to be in, and you write a
>> couple helper routes to go in either the "to unicode" or the "to bytes"
>> direction.  It basically looks at the type of the string/bytes you give 
>> it,
>> and makes sure it becomes what you need.  It's going to assume an 
>> encoding
>> like utf-8.
>>
>> On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
>> wrote:
>>
>>> I'm also not sure why Linux isn't failing.  Looking at the
>>> documentation for io.write object, i see this:
>>>
>>> write(*s*)
>>> 
>>>
>>> Write the unicode
>>>  string
>>> *s* to the stream and return the number of characters written.
>>> So clearly it does have to be a unicode object, and saying
>>> print(self.getvalue(), file=self.session) is clearly NOT printing a 
>>> unicode
>>> string to the file.
>>>
>>> What's the pattern you're referring to?  You can't convert a string
>>> to a unicode without specifying an encoding, and it seems

Re: [lldb-dev] something just toasted the test suite on OS X

2016-01-26 Thread Zachary Turner via lldb-dev 
Humm..  it's a unicode literal, not sure why it's complaining.  I guess
I'll have to crack open my linux machine and see what's going on tomorrow.

On Tue, Jan 26, 2016 at 6:12 PM Todd Fiala  wrote:

> I'm still getting a lot of these:
>
>
> Traceback (most recent call last):
>   File "test/dotest.py", line 7, in 
> lldbsuite.test.run_suite()
>   File
> "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/dotest.py",
> line 1089, in run_suite
> resultclass=test_result.LLDBTestResult).run(configuration.suite)
>   File
> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/runner.py",
> line 162, in run
> test(result)
>   File
> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
> line 65, in __call__
> return self.run(*args, **kwds)
>   File
> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
> line 85, in run
> self._wrapped_run(result)
>   File
> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
> line 115, in _wrapped_run
> test._wrapped_run(result, debug)
>   File
> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
> line 117, in _wrapped_run
> test(result)
>   File
> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/case.py",
> line 433, in __call__
> return self.run(*args, **kwds)
>   File
> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/case.py",
> line 369, in run
> self.dumpSessionInfo()
>   File
> "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
> line 1810, in dumpSessionInfo
> print(u"Session info generated @", datetime.datetime.now().ctime(),
> file=self.session)
> TypeError: must be unicode, not str
>
> On Tue, Jan 26, 2016 at 5:42 PM, Todd Fiala  wrote:
>
>> Oh missed this.  I'll give it a shot, hang on.
>>
>> On Tue, Jan 26, 2016 at 5:14 PM, Zachary Turner 
>> wrote:
>>
>>> Bump.  Can I re-submit this?
>>>
>>> On Tue, Jan 26, 2016 at 10:54 AM Zachary Turner 
>>> wrote:
>>>
 Can one of you guys try out this patch and see if it works?  If so I'll
 commit it.

 I don't know of a way to make this "elegant".  i.e. a single syntax /
 paradigm that works in both versions without introducing any helper
 functions.


 On Tue, Jan 26, 2016 at 12:26 AM Zachary Turner 
 wrote:

> No worries, worst case scenario a sledgehammer solution is to change
> all the places where we write to the session file to convert to unicode
> first (which would be a trivial conversion, since everything is going to 
> be
> ascii, which is already valid utf 8).
>
> The reason a problem arose at all is because TestCxxWcharT.py tried to
> write actual unicode characters to the session file.  I don't think 
> there's
> any way to prevent that because the characters could appear in a 
> backtrace,
> in a variable name, or in a test that is specifically testing unicode.  So
> we can't just have the one place that needs to write unicode encode it as
> bytes because there's no one place.
>
> I'll sleep on it and try to see if there's a better solution.  Maybe
> we can just make a function called write_session_file() that takes either 
> a
> string or a unicode, converts it to a unicode if it's not already one, and
> then writes.
>
> On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala 
> wrote:
>
>> Okay we're back to green here:
>> http://lab.llvm.org:8080/green/job/lldb_build_test/16173/
>>
>> Thanks, Enrico!
>>
>> Zachary, I may let this rest until the morning.  If you want to try
>> something else, shoot me a patch and I'll gladly try it.
>>
>> -Todd
>>
>> On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala 
>> wrote:
>>
>>> It's in item 3 from Effective Python, by Brett Slatkin, which goes
>>> over having methods that always go to unicode or to byte streams taking
>>> either unicode or byte style strings, for both Python 2 and Python 3.
>>> Essentially you figure out what you want it to be in, and you write a
>>> couple helper routes to go in either the "to unicode" or the "to bytes"
>>> direction.  It basically looks at the type of the string/bytes you give 
>>> it,
>>> and makes sure it becomes what you need.  It's going to assume an 
>>> encoding
>>> like utf-8.
>>>
>>> On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
>>> wrote:
>>>
 I'm also not sure why Linux isn't failing.  Looking at the
 documentation for io.write object, i see this:

 write(*s*)
 

 Write the unicode
  string
 *s* to

[lldb-dev] LLDB Windows MSVC buildbot out of memory errors

2016-01-26 Thread Zachary Turner via lldb-dev 
Hi all,

Cross posting to all groups because I'm getting a lot of email about this
recently.

Changes that have gone into clang over the past few months have increased
the strain on the linker, and it's to the point that MSVC cannot link
libclang.dll without going over the memory limits of a a 32-bit process.  I
submitted a patch to zorg to enable a 64-bit toolchain for x86 targets, but
somehow this buildbot got stuck with a 32-bit OS.  There's no fix short of
wiping the buildbot and starting over with a 64-bit OS.

I'm hoping to have this done in the next week, but just a heads up so
people know what's going on.

If you're reading this and you have a buildbot that uses MSVC, check to
make sure that this doesn't affect you as well (i.e. you might need to do
the same thing)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev