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

2016-01-21 Thread Renato Golin via lldb-dev 
On 20 January 2016 at 09:31, Sylvestre Ledru  wrote:
> What about creating a release management mailing list ?
> The testers are usually the same (hello folks!) :)

I second that! It'd also be much easier on mail filters... :)

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

[lldb-dev] [Bug 24953] Unusable with LLVM_LINK_LLVM_DYLIB=ON

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

lab...@google.com changed:

   What|Removed |Added

 CC||lab...@google.com
   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

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

[lldb-dev] [Bug 26230] New: LLDB generates superfluous "running" public events

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

Bug ID: 26230
   Summary: LLDB generates superfluous "running" public events
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

LLDB generates the following sequence of public events when stepping over a
conditional breakpoint (when the condition is false):

Got event: stopped , restarted:  True
Got event: running

the second event is unneeded as the first one has already had the "restarted"
bit set, and the process state has remained "running". We should make sure the
second event is not broadcast.

See  for
context.

-- 
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] [3.8 Release] RC1 has been tagged

2016-01-21 Thread Renato Golin via lldb-dev 
ARM and AArch64 seem both good. Uploaded.

On 19 January 2016 at 23:47, Hans Wennborg  wrote:
> Dear testers,
>
> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> r258223. (It took a little longer than I'd planned, sorry about that.)
>
> There are still a bunch of open merge requests and bug reports, but I
> wanted to get the tag in so we can see what the build and test status
> are on the various platforms.
>
> I verified that it currently builds and tests cleanly for me on x86_64
> Linux, Mac OS X* and Windows.
>
> Please build, test, and upload binaries to the sftp. Let me know if how it 
> goes.
>
> Thanks,
> Hans
>
>
> [*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`"
> CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work,
> otherwise stage-2 Clang couldn't find the SDK. I don't remember if I
> had to do this last time; maybe some upgrade changed something.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.8 Release] We have branched

2016-01-21 Thread Renato Golin via lldb-dev 
On 20 January 2016 at 17:49, Hans Wennborg  wrote:
> Did you send this before I sent the rc1 email, or what things are you
> referring to? :-)

Damn it, my filter isn't working as well as I expected! :) Sorry about
the noise.

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

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

2016-01-21 Thread Daniel Sanders via lldb-dev 
I still haven't built rc1 yet but I've found the cause of most (if not all) of 
the libc++ failures. This system does not have the en_US.UTF-8 locale.

I'm currently putting a patch together to add appropriate REQUIRES lines to 
tests that require en_US.UTF-8. Once I've done that and committed it, I'm going 
to enable this locale along with the others that lit is complaining about 
(fr_FR.UTF-8, ru_RU.UTF-8, zh_CN.UTF-*, fr_CA.ISO8859-1, and cs_CZ.ISO8859-2).

> -Original Message-
> From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Daniel
> Sanders via cfe-dev
> Sent: 20 January 2016 10:30
> To: Hans Wennborg; Ben Pope; Dimitry Andric; Nikola Smiljanić; Brian Cain;
> Renato Golin; Sylvestre Ledru
> Cc: llvm-dev; cfe-dev; openmp-...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [cfe-dev] [3.8 Release] RC1 has been tagged
> 
> This isn't rc1 but the tip of the release branch had some X86 test failures on
> my most recent build:
> Failing Tests (24):
> libc++ ::
> std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
> libc++ ::
> std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
> libc++ :: std/input.output/iostream.format/ext.manip/get_time.pass.cpp
> libc++ :: std/input.output/iostream.format/ext.manip/put_time.pass.cpp
> libc++ ::
> std/input.output/iostreams.base/ios.base/ios.base.callback/register_callbac
> k.pass.cpp
> libc++ ::
> std/input.output/iostreams.base/ios.base/ios.base.locales/imbue.pass.cpp
> libc++ ::
> std/input.output/iostreams.base/ios/basic.ios.members/imbue.pass.cpp
> libc++ ::
> std/input.output/stream.buffers/streambuf/streambuf.cons/copy.pass.cpp
> libc++ ::
> std/input.output/stream.buffers/streambuf/streambuf.cons/default.pass.c
> pp
> libc++ ::
> std/input.output/stream.buffers/streambuf/streambuf.protected/streamb
> uf.assign/assign.pass.cpp
> libc++ ::
> std/input.output/stream.buffers/streambuf/streambuf.protected/streamb
> uf.assign/swap.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.collate/locale.collate.byname/has
> h.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.collate/locale.collate.byname/typ
> es.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.ctype/locale.codecvt.byname/cto
> r_wchar_t.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.ctype/locale.ctype.byname/types
> .pass.cpp
> libc++ :: std/localization/locales/locale/locale.cons/default.pass.cpp
> libc++ :: std/localization/locales/locale/locale.members/name.pass.cpp
> libc++ :: std/localization/locales/locale/locale.operators/eq.pass.cpp
> libc++ :: std/localization/locales/locale/locale.statics/global.pass.cpp
> libc++ :: std/re/re.regex/re.regex.locale/imbue.pass.cpp
> libc++ :: std/re/re.traits/default.pass.cpp
> libc++ :: std/re/re.traits/getloc.pass.cpp
> libc++ :: std/re/re.traits/imbue.pass.cpp
> libomp :: barrier/omp_barrier.c
> 
> Big-endian mips gave this during phase 3:
>   CMake Error at cmake/modules/HandleLLVMOptions.cmake:43
> (message):
> Host Clang must be able to find libstdc++4.7 or newer!
> It's possible that this is a machine config issue. We moved offices over the
> weekend (just across the street) and my normal machine somehow lost the
> ability to boot in the process. I'm borrowing a replacement at the moment.
> 
> Little-endian mips is just about to finish Phase 2 so I'll know if it's a more
> general problem soon.
> 
> > -Original Message-
> > From: hwennb...@google.com [mailto:hwennb...@google.com] On
> Behalf
> > Of Hans Wennborg
> > Sent: 19 January 2016 23:56
> > To: Ben Pope; Dimitry Andric; Daniel Sanders; Nikola Smiljanić; Brian Cain;
> > Renato Golin; Sylvestre Ledru
> > Cc: cfe-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; llvm-dev
> > Subject: Re: [3.8 Release] RC1 has been tagged
> >
> > (cc'ing non-legacy llvm-dev this time; apologies if you get this
> > twice. Please don't reply-all to the first one.)
> >
> > On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg 
> > wrote:
> > > Dear testers,
> > >
> > > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> > > r258223. (It took a little longer than I'd planned, sorry about that.)
> > >
> > > There are still a bunch of open merge requests and bug reports, but I
> > > wanted to get the tag in so we can see what the build and test status
> > > are on the various platforms.
> > >
> > > I verified that it currently builds and tests cleanly for me on x86_64
> > > Linux, Mac OS X* and Windows.
> > >
> > > Please build, test, and upload binaries to the sftp. Let me know if how it
> > goes.
> > >
> > > Thanks,
> > > Hans
> > >
> > >
> > > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`"
> > > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work,
> > > otherwise stage-2 Clang couldn't find

Re: [lldb-dev] Inquiry for performance monitors

2016-01-21 Thread Ravitheja Addepally via lldb-dev 
Hello,
  Regarding the questions in this thread please find the answers ->

How are you going to present this information to the user? (I know
debugserver can report some performance data... Have you looked into
how that works? Do you plan to reuse some parts of that
infrastructure?) and How will you get the information from the server to
the client?

 Currently I plan to show a list of instructions that have been executed so
far, I saw the
implementation suggested by pavel, the already present infrastructure is a
little bit lacking in terms of the needs of the
project, but I plan to follow a similar approach, i.e to extract the raw
trace data by querying the server (which can use the
perf_event_open to get the raw trace data from the kernel) and transport it
through gdb packets ( qXfer packets
https://sourceware.org/gdb/onlinedocs/gdb/Branch-Trace-Format.html#Branch-Trace-Format).
At the client side the raw trace data
could be passed on to python based command that could decode the data. This
also eliminates the dependency of libipt since LLDB
would not decode the data itself.

There is also the question of this third party library.  Do we take a hard
dependency on libipt (probably a non-starter), or only use it if it's
available (much better)?

With the above mentioned way LLDB would not need the library, who ever
wants to use the python command would have to install it separately but
LLDB wont need it

With the performance counters, the interface would still be
perf_event_open, so if there was a perf_wrapper in LLDB server then it
could be reused to configure and use the
software performance counters as well, you would just need to pass
different attributes in the perf_event_open system call, plus I think the
perf_wrapper could be reused to
get CoreSight information as well (see https://lwn.net/Articles/664236/ )


On Wed, Oct 21, 2015 at 8:57 PM, Greg Clayton  wrote:

> one main benefit to doing this externally is allow this to be done
> remotely over any debugger connection. If you can run expressions to
> enable/disable/setup the memory buffer/access the buffer contents, then you
> don't need to add code into the debugger to actually do this.
>
> Greg
>
> > On Oct 21, 2015, at 11:54 AM, Greg Clayton  wrote:
> >
> > IMHO the best way to provide this information is to implement reverse
> debugging packets in a GDB server (lldb-server). If you enable this feature
> via some packet to lldb-server, and that enables the gathering of data that
> keeps the last N instructions run by all threads in some buffer that gets
> overwritten. The lldb-server enables it and gives a buffer to the
> perf_event_interface(). Then clients can ask the lldb-server to step back
> in any thread. Only when the data is requested do we actually use the data
> to implement the reverse stepping.
> >
> > Another way to do this would be to use a python based command that can
> be added to any target that supports this. The plug-in could install a set
> of LLDB commands. To see how to create new lldb command line commands in
> python, see the section named "CREATE A NEW LLDB COMMAND USING A PYTHON
> FUNCTION" on the http://lldb.llvm.org/python-reference.html web page.
> >
> > Then you can have some commands like:
> >
> > intel-pt-start
> > intel-pt-dump
> > intel-pt-stop
> >
> > Each command could have options and arguments as desired. The
> "intel-pt-start" command could make an expression call to enable the
> feature in the target by running and expression that runs the some
> perf_event_interface calls that would allocate some memory and hand it to
> the Intel PT stuff. The "intel-pt-dump" could just give a raw dump all of
> history for one or more threads (again, add options and arguments as needed
> to this command). The python code could bridge to C and use the intel
> libraries that know how to process the data.
> >
> > If this all goes well we can think about building it into LLDB as a
> built in command.
> >
> >
> >> On Oct 21, 2015, at 9:50 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> There are two different kinds of performance counters: OS performance
> counters and CPU performance counters.  It sounds like you're talking about
> the latter, but it's worth considering whether this could be designed in a
> way to support both (i.e. even if you don't do both yourself, at least make
> the machinery reusable and apply to both for when someone else wanted to
> come through and add OS perf counters).
> >>
> >> There is also the question of this third party library.  Do we take a
> hard dependency on libipt (probably a non-starter), or only use it if it's
> available (much better)?
> >>
> >> As Pavel said, how are you planning to present the information to the
> user?  Through some sort of top level command like "perfcount
> instructions_retired"?
> >>
> >> On Wed, Oct 21, 2015 at 8:16 AM Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>

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

2016-01-21 Thread Hans Wennborg via lldb-dev 
On Thu, Jan 21, 2016 at 5:18 AM, Renato Golin  wrote:
> On 20 January 2016 at 09:31, Sylvestre Ledru  wrote:
>> What about creating a release management mailing list ?
>> The testers are usually the same (hello folks!) :)
>
> I second that! It'd also be much easier on mail filters... :)

Tanya, can you help us set up an llvm-release-testers mailing list?

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

Re: [lldb-dev] clang-format now supports return type on separate line

2016-01-21 Thread Todd Fiala via lldb-dev 
Glad to see clang-format getting some improvements.



On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner  wrote:

> As far as I'm aware, this is the last major incompatibility between LLDB's
> style and clang-format's feature set.
>
> I would appreciate it if more people could try it out with a few of their
> patches, and let me know if any LLDB style incompatibilities arise in the
> formatted code.
>
> I would eventually like to move towards requiring that all patches be
> clang-formatted before committing to LLDB.
>

Question to the group on that last part.  I think if we have a large body
of code that is just getting a few tweaks to a method, having the patch run
through the formatter could lead to some pretty ugly code.  Imagine a few
lines of a file awkwardly formatted related to the rest of the file.  Since
we're not trying to reformat everything at once (which makes for difficult
code traceability), and given there was a large code base to start with
before LLDB was part of LLVM, I'm not sure we want a blanket statement that
says it must go through clang-format.  (I personally would be fine with
doing whole new functions and other logical blocks of code via clang-format
when inserted into existing code, but I think it probably extreme when
we're talking about new little sections within existing functions).

Thoughts?


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

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

2016-01-21 Thread Dimitry Andric via lldb-dev 
On 20 Jan 2016, at 21:18, Dimitry Andric via llvm-dev  
wrote:
...
>>> * Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the 
>>> last version that can build without C++11 support), and it crashes with a 
>>> segfault during building of CGBlocks.cpp.  I'll need to find some way to 
>>> work around this failure, since we cannot upgrade the compiler easily on 
>>> FreeBSD 10.x.
>> 
>> This sounds like the biggest problem. Is there a PR for the crash? I
>> suppose the alternatives are either to try not to tickle the crash in
>> our source, or fixing the 3.4.1 compiler?
> 
> There is no PR, but I did a bisection, and the crash turns out to be fixed by 
> r210467 ("[DAG] Expose NoSignedWrap, NoUnsignedWrap and Exact flags to 
> SelectionDAG.") by Andrea DiBiagio.

And I finally found out this was a red herring, and I had already solved this 
issue before, in July 2015 [1], with excellent help from Andrea!  This was 
originally known as PR24249, and eventually turned out to be solved by llvm 
r219009.

However, the two build VMs I have been using for LLVM release testing were 
never updated to include the fix, and were still at the version of FreeBSD from 
roughly May 2015.

I have now been able to do a successful build of the llvm, clang and (for 
amd64) openmp.  Uploaded the following tarballs:

SHA256 (clang+llvm-3.8.0-rc1-amd64-unknown-freebsd10.tar.xz) = 
28b8f7758736dab181da9e5e445eb734b134a579ed79bcf8b040d4a7d5c9d31d
SHA256 (clang+llvm-3.8.0-rc1-i386-unknown-freebsd10.tar.xz) = 
ba9712964c56bcc9ba50f511f2a98757d321d5cd1c7989790029dd64c3db6db4

I will now spend some time to see if I can get more components to build for the 
next release candidate.

-Dimitry

[1] https://svnweb.freebsd.org/base?view=revision=286033
[2] https://llvm.org/bugs/show_bug.cgi?id=24249
[3] http://llvm.org/viewvc/llvm-project?view=revision=219009



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

2016-01-21 Thread Hans Wennborg via lldb-dev 
On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg  wrote:
> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> r258223. (It took a little longer than I'd planned, sorry about that.)
>
> There are still a bunch of open merge requests and bug reports, but I
> wanted to get the tag in so we can see what the build and test status
> are on the various platforms.
>
> I verified that it currently builds and tests cleanly for me on x86_64
> Linux, Mac OS X* and Windows.
>
> Please build, test, and upload binaries to the sftp. Let me know if how it 
> goes.

Uploaded Win binaries to the sftp:
842c6b6165089cd0771020c0bdb542456690aab9  LLVM-3.8.0-rc1-win32.exe
5031bd338856b3cd06fce260c9cc1c2445536963  LLVM-3.8.0-rc1-win64.exe

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

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

2016-01-21 Thread Eric Fiselier via lldb-dev 
On Wed, Jan 20, 2016 at 1:18 PM, Dimitry Andric via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On 20 Jan 2016, at 18:23, Hans Wennborg  wrote:
> >
> > On Wed, Jan 20, 2016 at 5:25 AM, Dimitry Andric 
> wrote:
> >> Unfortunately I'm having lots of trouble with rc1 at this point:
> >> * libcxxabi can't build, because it requires unwind.h, which we do not
> yet have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is
> not ready for general consumption).
> >> * The test-release.sh script has no option to disable only libcxxabi,
> you can only disable libcxx, libcxxabi and libunwind together (maybe this
> can be improved)
> >
> > Yes, I'd be happy to take a patch for this, or I suppose you could
> > just hack it out locally when building.
>
> It's not terribly important right now, as libcxx isn't succeeding its
> tests anyway.  I can locally hack it in, but I hope I won't forget it
> later. :)
>
>
> >> * Last time I hand-built libcxx, it still had a lot of test failures in
> the locale parts, but I haven't had time to investigate.
> >
> > Did we have that for 3.7 too?
>
> With 3.7, we used autoconf builds for FreeBSD, and that skipped libcxx
> altogether.  I did a few builds by hand, and I remember I saw similar
> failures.  This is just something that nobody (from FreeBSD) has seriously
> looked at, and I never had the time for it.  There are only so much hours
> in a day...
>
> For example, recently with trunk r256945, I saw these:
>
> Failing Tests (39):
> libc++ :: std/depr/depr.c.headers/stddef_h.pass.cpp
> libc++ :: std/depr/depr.c.headers/wchar_h.pass.cpp
> libc++ :: std/language.support/support.types/max_align_t.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_1.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_many.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_1.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_many.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_zh_CN.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_zh_CN.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.time/locale.time.get.byname/get_date.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.time/locale.time.get.byname/get_date_wide.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.time/locale.time.get.byname/get_one.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.time/locale.time.put.byname/put1.pass.cpp
> libc++ ::
> std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/grouping.pass.cpp
> libc++ ::
> std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp
> libc++ :: std/re/re.alg/re.alg.match/basic.pass.cpp
> libc++ :: std/re/re.alg/re.alg.match/ecma.pass.cpp
> libc++ :: std/re/re.alg/re.alg.match/extended.pass.cpp
> libc++ :: std/re/re.alg/re.alg.search/awk.pass.cpp
> libc++ :: std/re/re.alg/re.alg.search/basic.pass.cpp
> libc++ :: std/re/re.alg/re.alg.search/ecma.pass.cpp
> libc++ :: std/re/re.alg/re.alg.search/extended.pass.cpp
>

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

2016-01-21 Thread Eric Fiselier via lldb-dev 
On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> SuSE Linux Enterprise Server 11SP3 x86_64
>
> Looks like I see several failures that weren't in 3.7.1.  Is there any way
> to tell whether these are regressions vs new-to-3.8.0-but-failing?  The
> MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were
> not in 3.7.1.
>
>
All of the libc++ failures seem like non-issues and should be in 3.7.1. Did
you change or upgrade your platform or libc version?  I'm not sure about
the libc++abi error though.


> 
> Failing Tests (27):
> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async
> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier
> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs
> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture
> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction
> MemorySanitizer :: Linux/obstack.cc
> MemorySanitizer :: Linux/process_vm_readv.cc
> MemorySanitizer :: fork.cc
> MemorySanitizer :: iconv.cc
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r
> SanitizerCommon-Unit ::
> Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize
> ThreadSanitizer :: Linux/mutex_robust.cc
> ThreadSanitizer :: Linux/mutex_robust2.cc
> ThreadSanitizer :: thread_name2.cc
> libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp
>

This is caused because the system does not provide a uchar.h header.


> libc++ ::
> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
> libc++ ::
> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
>


These are marked XFAIL on open-suse, They should probably be marked as
XFAIL on your platform as well.
Can you send me the output of Python's "platform.linux_distribution()"?


> libc++abi :: cxa_thread_atexit_test.pass.cpp
>

Not sure about this failure. Can you send me the output?


>
>   Expected Passes: 31153
>   Expected Failures  : 203
>   Unsupported Tests  : 518
>   Unexpected Failures: 27
> ~~
>
> Uploads:
> 7b837b2c4b7884a4277b947b795948ecd983b0f3
>  clang+llvm-3.8.0-rc1-linux-x86_64-sles11.3.tar.xz
>
>
> On Tue, Jan 19, 2016 at 5:55 PM, Hans Wennborg  wrote:
>
>> (cc'ing non-legacy llvm-dev this time; apologies if you get this
>> twice. Please don't reply-all to the first one.)
>>
>> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg  wrote:
>> > Dear testers,
>> >
>> > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> > r258223. (It took a little longer than I'd planned, sorry about that.)
>> >
>> > There are still a bunch of open merge requests and bug reports, but I
>> > wanted to get the tag in so we can see what the build and test status
>> > are on the various platforms.
>> >
>> > I verified that it currently builds and tests cleanly for me on x86_64
>> > Linux, Mac OS X* and Windows.
>> >
>> > Please build, test, and upload binaries to the sftp. Let me know if how
>> it goes.
>> >
>> > Thanks,
>> > Hans
>> >
>> >
>> > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`"
>> > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work,
>> > otherwise stage-2 Clang couldn't find the SDK. I don't remember if I
>> > had to do this last time; maybe some upgrade changed something.
>>
>
>
>
> --
> -Brian
>
> ___
> 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

[lldb-dev] [Bug 26248] New: Disassembly incorrect for x64 RIP-relative

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

Bug ID: 26248
   Summary: Disassembly incorrect for x64 RIP-relative
   Product: lldb
   Version: 3.4
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: m...@microsoft.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15687
  --> https://llvm.org/bugs/attachment.cgi?id=15687=edit
Program demonstrates incorrect disassembly for x64 RIP relative.

The disassemble command for x64 RIP relative addressing modes displays the
wrong disassembly. As an example, the byte sequence

  49 8b 05 78 56 34 12

disassembles to three instructions like

(lldb) di -c3 -b -s 
  0x7fff5fbff740: 49 8b 05  movq   (%r13), %rax
  0x7fff5fbff743: 78 56 js 0x7fff5fbff79b
  0x7fff5fbff745: 34 12 xorb   $0x12, %al

when it should produce a single instruction like

  0x7fff5fbff740: 49 8b 05 78 56 34 12  movq   (%rip + 12345679), %rax

I've attached a small C++ program to demonstrate the problem in the debugger.
The program just declares an array to hold the byte sequence above and then
prints out instructions to copy/paste into the LLDB. Here are the instructions
from the attached program (note that g++ on the Mac maps to LLVM).

REPRO STEPS:

g++ -g lldb-disassemble-rip.cxx
lldb a.out
breakpoint set -f lldb-disassemble-rip.cxx -l 7
r
di -c3 -b -s 

EXPECT:
  Something like
  (lldb) di -c3 -b -s 
0x7fff5fbff740: 49 8b 05 78 56 34 12  movq   (%rip + 12345679), %rax

OBSERVE:
  Something like
  (lldb) di -c3 -b -s 
0x7fff5fbff740: 49 8b 05  movq   (%r13), %rax
0x7fff5fbff743: 78 56 js 0x7fff5fbff79b
0x7fff5fbff745: 34 12 xorb   $0x12, %al

I am seeing this problem on Mac OS X Yosemite Version 10.10.5 with
lldb-340.4.110.1.

This bug may be more impactful than incorrect output if it prevents lldb from
single stepping. In order to test whether lldb single stepping is broken, one
would need an example with the correct stack unwinding provisions.

-- 
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] clang-format now supports return type on separate line

2016-01-21 Thread Sean Callanan via lldb-dev 
I tend to agree with Zachary on the overall principle – and I would be willing 
to clang-format functions when I modify them.  I’m concerned about a specific 
class of functions, though.  Let’s say I have a function that has had lots of 
activity (I’m thinking of, for example, ParseType off in the DWARF parser).  
Unfortunately, such functions tend to be the ones that benefit most from 
clang-format.

In such a function, there’s a lot of useful history available via svn blame 
that helps when fixing bugs.  My concern is that if someone clang-formats this 
function after applying the kth fix, suddenly I've lost convenient access to 
that history.  It’s only available with a fair amount of pain, and this pain 
increases as more fixes are applied because now I need to interleave the info 
before and after reformatting.

Would it be reasonable to mark such functions as “Don’t clang-format”?  That 
could be also interpreted as a “// TODO add comments so what this does is more 
understandable”

Sean

> On Jan 21, 2016, at 10:59 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Also this is the same standard that applies to the rest of LLVM.  
> clang-format your patches.  Just because we haven't been consistently 
> following the rules until now doesn't mean we should continue to not follow 
> the rules going forward.  This way eventually the codebase slowly converges 
> towards a properly formatted one.  If clang-format does something that you 
> think looks awkward with respect to the surrounding code (perhaps within a 
> single logical block or whatever else) then just touch a line of code in the 
> surrounding area so that clang-format will do it too. Since it only formats 
> the differential, you have as much control as you need to produce something 
> that a) is consistent with the rules, and b) doesn't look awkward with 
> respect to surrounding code.
> 
> On Thu, Jan 21, 2016 at 10:11 AM Zachary Turner  > wrote:
> I'm not sure I agree.  I don't think anything will be awkwardly formatted 
> with regards to the rest of the file.  The biggest thing this is going to fix 
> are whitespace at the end of lines, line breakign conventions, and space 
> between function name and parentheses.
> 
> If we're not going to enforce a coding style, why have one at all?  
> clang-format enforces it.
> 
> On Thu, Jan 21, 2016 at 8:41 AM Todd Fiala  > wrote:
> Glad to see clang-format getting some improvements.
> 
> 
> 
> On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner  > wrote:
> As far as I'm aware, this is the last major incompatibility between LLDB's 
> style and clang-format's feature set.
> 
> I would appreciate it if more people could try it out with a few of their 
> patches, and let me know if any LLDB style incompatibilities arise in the 
> formatted code.
> 
> I would eventually like to move towards requiring that all patches be 
> clang-formatted before committing to LLDB.  
> 
> Question to the group on that last part.  I think if we have a large body of 
> code that is just getting a few tweaks to a method, having the patch run 
> through the formatter could lead to some pretty ugly code.  Imagine a few 
> lines of a file awkwardly formatted related to the rest of the file.  Since 
> we're not trying to reformat everything at once (which makes for difficult 
> code traceability), and given there was a large code base to start with 
> before LLDB was part of LLVM, I'm not sure we want a blanket statement that 
> says it must go through clang-format.  (I personally would be fine with doing 
> whole new functions and other logical blocks of code via clang-format when 
> inserted into existing code, but I think it probably extreme when we're 
> talking about new little sections within existing functions).
> 
> Thoughts?
> 
> 
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Re: [lldb-dev] clang-format now supports return type on separate line

2016-01-21 Thread Zachary Turner via lldb-dev 
On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan  wrote:

> I tend to agree with Zachary on the overall principle – and I would be
> willing to clang-format functions when I modify them.  I’m concerned about
> a specific class of functions, though.  Let’s say I have a function that
> has had lots of activity (I’m thinking of, for example, ParseType off in
> the DWARF parser).  Unfortunately, such functions tend to be the ones that
> benefit most from clang-format.
>
> In such a function, there’s a lot of useful history available via svn
> blame that helps when fixing bugs.  My concern is that if someone
> clang-formats this function after applying the *k*th fix, suddenly I've
> lost convenient access to that history.  It’s only available with a fair
> amount of pain, and this pain increases as more fixes are applied because
> now I need to interleave the info before and after reformatting.
>
> Would it be reasonable to mark such functions as “Don’t clang-format”?
> That could be also interpreted as a “// TODO add comments so what this does
> is more understandable”
>

Well again by default it's only going to format the code you touch in yoru
diff plus 1 or 2 surrounding lines.  So having it format an entire function
is something you would have to explicitly go out of your way to do.  So
it's a judgement call.  If you think the function would be better off
clang-formatting the entire thing, do that.  If you just want to format the
lines you're touching because you were in there anyway, that's the default
behavior.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev