[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 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 the SDK. I don't remem

[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


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 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] [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


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:
> >> [ Moving this discussion back to the li

Re: [lldb-dev] marking new summary output for expected timeouts

2016-01-21 Thread Todd Fiala via lldb-dev
Great.  Actually there is a latent bug in there we hit yesterday, when
there is a platform set but it doesn't start with "remote-" (we assume the
match result has a first matched group and blow up).  I'll submit a patch
that both fixes that up and strips out the darwin ones.  I think the rerun
logic now fully covers us on the Darwin side.

On Wed, Jan 20, 2016 at 5:18 AM, Pavel Labath  wrote:

> Hi,
>
> I have removed all of our expected timeouts from dosep.py (there are
> still some freebsd and darwin ones left, but I don't know If anyone is
> looking at those), so I think we're not using any part of the old test
> runner at the moment. All clear for removal on our part.
>
> pl
>
>
> On 14 December 2015 at 16:06, Todd Fiala  wrote:
> > Oh yeah, that's fine.  I won't take that code out.
> >
> > Hmm at least some of the builds went through this weekend, I made a
> number
> > of changes Saturday morning (US Pacific time) that I saw go through the
> > Ubuntu 14.04 cmake bot.
> >
> > On Mon, Dec 14, 2015 at 6:29 AM, Pavel Labath  wrote:
> >>
> >> Hi,
> >>
> >> we've had an unrelated breaking change, so the buildbots were red over
> >> the weekend. I've fixed it now, and it seems to be turning green.
> >> We've also had power outage during the weekend and not all of the
> >> buildbots are back up yet, as we need to wait for MTV to wake up. I'd
> >> like to give this at least one more day, to give them a chance to
> >> stabilize. Is this blocking you from making further changes to the
> >> test event system?
> >>
> >> pl
> >>
> >> On 12 December 2015 at 00:20, Todd Fiala  wrote:
> >> > Hey Pavel and/or Tamas,
> >> >
> >> > Let me know when we're definitely all clear on the expected timeout
> >> > support
> >> > I added to the (now once again) newer default test results.
> >> >
> >> > As soon as we don't need the legacy summary results anymore, I'm going
> >> > to
> >> > strip out the code that manages it.  It is quite messy and duplicates
> >> > the
> >> > content that is better handled by the test event system.
> >> >
> >> > Thanks!
> >> >
> >> > -Todd
> >> >
> >> > On Fri, Dec 11, 2015 at 2:03 PM, Todd Fiala 
> >> > wrote:
> >> >>
> >> >> I went ahead and added the expected timeout support in r255363.
> >> >>
> >> >> I'm going to turn back on the new BasicResultsFormatter as the
> default.
> >> >> We can flip this back off if it is still not doing everything we
> need,
> >> >> but I
> >> >> *think* we cover the issue you saw now.
> >> >>
> >> >> -Todd
> >> >>
> >> >> On Fri, Dec 11, 2015 at 10:14 AM, Todd Fiala 
> >> >> wrote:
> >> >>>
> >> >>> Hi Pavel,
> >> >>>
> >> >>> I'm going to adjust the new summary output for expected timeouts.  I
> >> >>> hope
> >> >>> to do that in the next hour or less.  I'll put that in and flip the
> >> >>> default
> >> >>> back on for using the new summary output.
> >> >>>
> >> >>> I'll do those two changes separately, so you can revert the flip
> back
> >> >>> on
> >> >>> to flip it back off if we still have an issue.
> >> >>>
> >> >>> Sound good?
> >> >>>
> >> >>> (This can be orthogonal to the new work to mark up expected
> timeouts).
> >> >>> --
> >> >>> -Todd
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> -Todd
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > -Todd
> >
> >
> >
> >
> > --
> > -Todd
>



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

2016-01-21 Thread Hans Wennborg via lldb-dev
On Wed, Jan 20, 2016 at 5:02 PM, Ben Pope via cfe-dev
 wrote:
> On Thursday, January 21, 2016 01:28 AM, Hans Wennborg via cfe-dev wrote:
>>
>> On Wed, Jan 20, 2016 at 7:54 AM, Ben Pope  wrote:
>>>
>>> On Wednesday, January 20, 2016 07:47 AM, 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.)
>>
>>
>>> Some issues:
>>>
>>> LNT didn't finish: perhaps my checkout is incomplete, this bit seems to
>>> have
>>> changed with the switch to cmake.  Some unexpected failures on Ubuntu
>>> 14.04,
>>> but 15.10 was great.
>>
>>
>> How did you build LNT? I think previously it used to get configured
>> automatically, but not built. Recently someone added a cmake file to
>> it, which didn't work, so I excluded it from the test-release build in
>> r257791
>
>
> I only checked out the test-suite and ran LNT as I normally do. Do I need to
> "build" the test suite?

OK, that sounds good. I was worried it was getting pulled in and
failing through the CMake build in test-release.sh.
___
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 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 Zachary Turner via lldb-dev
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] Problems with core load on Linux and proposed solution

2016-01-21 Thread Eugene Birukov via lldb-dev
Hi,
LLDB 3.8 has much better support for core load on Linux than 3.7 - thanks a 
lot! But there are still two problems.
1. The thread ID are lost and there is FIXME in the code2. 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 fix that works for me for both problems.
Thanks,Eugene
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)


{ ___
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 Dimitry Andric via lldb-dev
On 20 Jan 2016, at 22:26, Hans Wennborg  wrote:
> 
> On Wed, Jan 20, 2016 at 12:18 PM, Dimitry Andric  wrote:
...
>> The way I fixed this during the 3.7 test phase, is by changing 
>> test-release.sh so it exports directly into these locations:
>> 
>> # Exporting llvm 3.7.0-rc3 sources to llvm.src
>> # Exporting cfe 3.7.0-rc3 sources to llvm.src/tools/clang
>> # Exporting clang-tools-extra 3.7.0-rc3 sources to 
>> llvm.src/tools/clang/tools/extra
>> # Exporting compiler-rt 3.7.0-rc3 sources to llvm.src/projects/compiler-rt
>> # Exporting libcxx 3.7.0-rc3 sources to llvm.src/projects/libcxx
>> # Exporting libcxxabi 3.7.0-rc3 sources to llvm.src/projects/libcxxabi
>> # Exporting libunwind 3.7.0-rc3 sources to llvm.src/projects/libunwind
>> # Exporting test-suite 3.7.0-rc3 sources to llvm.src/projects/test-suite
>> 
>> This is probably not so handy if you want to create tarballs of the 
>> individual components, though.
> 
> Actually, I use export.sh for creating the tarballs, so that's not a
> problem. Maybe just exporting into the right directories is the way to
> go.

I have created http://reviews.llvm.org/D16420 for this change.  Please review.

-Dimitry



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

2016-01-21 Thread Zachary Turner via lldb-dev
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


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&revision=286033
[2] https://llvm.org/bugs/show_bug.cgi?id=24249
[3] http://llvm.org/viewvc/llvm-project?view=revision&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] 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 Todd Fiala via lldb-dev
Jim, I think you and I have talked about this in the past.  Care to comment?

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”
>
> Sean
>
> On Jan 21, 2016, at 10:59 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> 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
>
>
>


-- 
-Todd
___
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


Re: [lldb-dev] Inquiry for performance monitors

2016-01-21 Thread Greg Clayton via lldb-dev
One thing to think about is you can actually just run an expression in the 
program that is being debugged without needing to change anything in the GDB 
remote server. So this can all be done via python commands and would require no 
changes to anything. So you can run an expression to enable the buffer. Since 
LLDB supports multiple line expression that can define their own local 
variables and local types. So the expression could be something like:

int perf_fd = (int)perf_event_open(...);
struct PerfData
{
void *data;
size_t size;
};
PerfData result = read_perf_data(perf_fd);
result


The result is then a structure that you can access from your python command (it 
will be a SBValue) and then you can read memory in order to get the perf data.

You can also split things up into multiple calls where you can run 
perf_event_open() on its own and return the file descriptor:

(int)perf_event_open(...)

This expression will return the file descriptor

Then you could allocate memory via the SBProcess:

(void *)malloc(1024);

The result of this expression will be the buffer that you use...

Then you can read 1024 bytes at a time into this newly created buffer.

So a solution that is completely done in python would be very attractive.

Greg


> On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally  
> wrote:
> 
> 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_e

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

2016-01-21 Thread Brian Cain via lldb-dev
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.


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
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
libc++abi :: cxa_thread_atexit_test.pass.cpp

  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
___
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&action=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 &a
  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 &a

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

OBSERVE:
  Something like
  (lldb) di -c3 -b -s &a
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] [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


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
> libc++ :: std/re/re.traits/lookup_c

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

2016-01-21 Thread Brian Cain via lldb-dev
On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier  wrote:

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

I don't recall any changes to libc.  Attached is the testing log from 3.7.1
rc2 (I don't have logs from -final handy).

I can repeat a 3.7.1 release build on this system now.  I don't think the
results will change, 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()"?
>
>

Ok, I'll be able to get this tomorrow.  But I suspect it will be "('SUSE
Linux Enterprise Server ', '11', 'x86_64')"


> libc++abi :: cxa_thread_atexit_test.pass.cpp
>>
>
> Not sure about this failure. Can you send me the output?
>
>
That one failed in 3.7.1 also.  IIRC this libstdc++ doesn't have
cxa_thread_atexit.


Compilation failed unexpectedly!

Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 272.89s

Failing Tests (18):
MemorySanitizer :: Linux/obstack.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++abi :: cxa_thread_atexit_test.pass.cpp

  Expected Passes: 24070
  Expected Failures  : 132
  Unsupported Tests  : 374
  Unexpected Failures: 18
make[3]: *** [CMakeFiles/check-all] Error 1
make[3]: Target `CMakeFiles/check-all.dir/build' not remade because of errors.
make[2]: *** [CMakeFiles/check-all.dir/all] Error 2
make[1]: *** [CMakeFiles/check-all.dir/rule] Error 2
make[

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

2016-01-21 Thread Todd Fiala via lldb-dev
Okay, sounds like a reasonable thing to try.  We can always review it if it
causes any real issues.

On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner  wrote:

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



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