[lldb-dev] [Bug 19311] LLDB does not stop at breakpoint on resumed-to instruction (on FreeBSD) -- ThreadPlanStepOverBreakpoint skips subsequent braeakpoint

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=19311

abhiinnit...@gmail.com changed:

   What|Removed |Added

 CC||abhiinnit...@gmail.com
   Assignee|lldb-dev@lists.llvm.org |abhiinnit...@gmail.com

--- Comment #2 from abhiinnit...@gmail.com ---
I am working on resolving this issue. I will upstream the fix soon.

-- 
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 23039] DynamicValueChildCountTestCase.test_get_dynamic_vals_with_dwarf failure

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=23039

abhiinnit...@gmail.com changed:

   What|Removed |Added

 CC||abhiinnit...@gmail.com
   Assignee|lldb-dev@lists.llvm.org |abhiinnit...@gmail.com

--- Comment #2 from abhiinnit...@gmail.com ---
I am working on resolving this issue. I will upstream the fix soon.

-- 
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] Patch to fix REPL for ARMv7 & ARMv6 on linux

[Omair Javaid via lldb-dev]

Hi Will,

I dont understand REPL and thus the benefits it will have by making
change to architecture name. I would not recommend to drop any
information that we get from the host operating system.

LLDB maintains core information alongwith triple in ArchSpec, may be
you can parse triple to reflect correct core and use core instead of
architecture name where needed.

Kindly elaborate in a bit detail what are we getting out of this
change for more accurate comments.

Thanks!

On 26 January 2016 at 14:47, Pavel Labath  wrote:
> + Omair
>
> I don't really understand arm (sub)-architectures or REPL. The patch
> seems mostly harmless, but it also feels like a hack to me. A couple
> of questions:
> - why does this only pose a problem for REPL?
> - If I understand correctly, the problem is that someone is looking at
> the architecture string contained in the Triple, and not finding what
> it expects. Is that so? Could you point me to (some of) the places
> that do that.
>
> Omair, any thoughts on this?
>
> cheers,
> pl
>
>
> On 25 January 2016 at 18:55, Hans Wennborg  wrote:
>> This patch looks reasonable to me, but I don't know enough about LLDB
>> to actually review it.
>>
>> +Renato or Pavel maybe?
>>
>> On Thu, Jan 14, 2016 at 11:32 AM, William Dillon via lldb-dev
>>  wrote:
>>> Hi again, everyone
>>>
>>> I’d like to ping on this patch now that the 3.8 branch is fairly new, and 
>>> merging it over is fairly straight-forward.
>>>
>>> Thanks in advance for your comments!
>>> - Will
>>>
 There is a small change that enables correct calculation of arm sub 
 architectures while using the REPL on arm-linux.  As you may of may or may 
 not know, linux appends ‘l’ to arm architecture versions to denote little 
 endian.  This sometimes interferes with the determination of the 
 architecture in the triple.  I experimented with adding sub architecture 
 entries for these within lldb, but I discovered a simpler (and less 
 invasive) method.  Because LLVM already knows how to handle some of these 
 cases (I have a patch submitted for review that enables v6l; v7l already 
 works), I am relying on llvm to clean it up.  The gist of it is that the 
 llvm constructor (when given a triple string) retains the provided string 
 unless an accessor mutates it.  Meanwhile, the accessors for the 
 components go through the aliasing and parsing logic.  This code detects 
 whether the sub-architecture that armv6l or armv7l aliases to is detected, 
 and re-sets the architecture in the triple.  This overwrites the 
 architecture that comes from linux, thus sanitizing it.

 Some kind of solution is required for the REPL to work on arm-linux.  
 Without it, the REPL crashes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26335] New: lldb (after 3.7.x) compilation fails at link-time with shared library

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26335

Bug ID: 26335
   Summary: lldb (after 3.7.x) compilation fails at link-time with
shared library
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: voyageu...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15726
  --> https://llvm.org/bugs/attachment.cgi?id=15726&action=edit
Build log showing lldb link failure

Link operation fails in lllb for versions > 3.7 (3.7.1 works fine), with shared
library and --as-needed link flag (enabled by default in most distributions).
There are many errors "undefined reference to `llvm::*". I am attaching a full
build log (bzipped for size).
It would be nice to have this one fixed for 3.8 release

Note: this is on trunk build, but I saw it too before the 3.8 branch (the
Gentoo ebuild for 3.8 rc1 is not ready yet)

FAILED: : && /usr/bin/x86_64-pc-linux-gnu-g++   -march=native -O2 -pipe  -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-Werror=date-time -std=c++11 -ffunction-sections -fdata-sections
-Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing
-Wno-deprecated-register -Wno-vla-extension  -fno-exceptions -fno-rtti  -Wl,-O1
-Wl,--as-needed -Wl,-allow-shlib-undefined -Wl,-O3 -Wl,--gc-sections
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/Acceptor.cpp.o
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-gdbserver.cpp.o
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-platform.cpp.o
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-server.cpp.o
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/LLDBServerUtilities.cpp.o
 -o bin/lldb-server-3.9.0  lib64/liblldb.so.3.9.0 -lcurses -lform -lpanel
-lcurses -lpython2.7 -lxml2 -lpthread -ldl -lcurses -lform -lpanel
lib64/libLLVMBPFCodeGen.so lib64/libLLVMBPFAsmPrinter.so
lib64/libLLVMBPFDesc.so lib64/libLLVMBPFInfo.so
lib64/libLLVMCppBackendCodeGen.so lib64/libLLVMCppBackendInfo.so
lib64/libLLVMX86CodeGen.so lib64/libLLVMX86AsmPrinter.so
lib64/libLLVMX86AsmParser.so lib64/libLLVMX86Desc.so lib64/libLLVMX86Info.so
lib64/libLLVMX86Disassembler.so lib64/libLLVMInterpreter.so
lib64/libLLVMAsmParser.so lib64/libLLVMBitReader.so lib64/libLLVMBitWriter.so
lib64/libLLVMCodeGen.so lib64/libLLVMipo.so lib64/libLLVMSelectionDAG.so
lib64/libLLVMMC.so lib64/libLLVMMCJIT.so lib64/libLLVMCore.so
lib64/libLLVMMCDisassembler.so lib64/libLLVMExecutionEngine.so
lib64/libLLVMRuntimeDyld.so lib64/libLLVMOption.so lib64/libLLVMSupport.so
-Wl,--start-group lib64/liblldbBase.a lib64/liblldbBreakpoint.a
lib64/liblldbCommands.a lib64/liblldbDataFormatters.a lib64/liblldbHost.a
lib64/liblldbCore.a lib64/liblldbExpression.a lib64/liblldbInitialization.a
lib64/liblldbInterpreter.a lib64/liblldbSymbol.a lib64/liblldbTarget.a
lib64/liblldbUtility.a lib64/liblldbPluginDisassemblerLLVM.a
lib64/liblldbPluginSymbolFileDWARF.a lib64/liblldbPluginSymbolFileSymtab.a
lib64/liblldbPluginDynamicLoaderStatic.a
lib64/liblldbPluginDynamicLoaderPosixDYLD.a
lib64/liblldbPluginDynamicLoaderHexagonDYLD.a
lib64/liblldbPluginDynamicLoaderWindowsDYLD.a
lib64/liblldbPluginCPlusPlusLanguage.a lib64/liblldbPluginGoLanguage.a
lib64/liblldbPluginObjCLanguage.a lib64/liblldbPluginObjCPlusPlusLanguage.a
lib64/liblldbPluginObjectFileELF.a lib64/liblldbPluginObjectFileJIT.a
lib64/liblldbPluginSymbolVendorELF.a
lib64/liblldbPluginObjectContainerBSDArchive.a
lib64/liblldbPluginObjectContainerMachOArchive.a
lib64/liblldbPluginProcessGDBRemote.a lib64/liblldbPluginProcessUtility.a
lib64/liblldbPluginPlatformAndroid.a lib64/liblldbPluginPlatformGDB.a
lib64/liblldbPluginPlatformFreeBSD.a lib64/liblldbPluginPlatformKalimba.a
lib64/liblldbPluginPlatformLinux.a lib64/liblldbPluginPlatformNetBSD.a
lib64/liblldbPluginPlatformPOSIX.a lib64/liblldbPluginPlatformWindows.a
lib64/liblldbPluginPlatformMacOSX.a
lib64/liblldbPluginDynamicLoaderMacOSXDYLD.a
lib64/liblldbPluginUnwindAssemblyInstEmulation.a
lib64/liblldbPluginUnwindAssemblyX86.a lib64/liblldbPluginAppleObjCRuntime.a
lib64/liblldbPluginRenderScriptRuntime.a lib64/liblldbPluginLanguageRuntimeGo.a
lib64/liblldbPluginCXXItaniumABI.a lib64/liblldbPluginABIMacOSX_arm.a
lib64/liblldbPluginABIMacOSX_arm64.a lib64/liblldbPluginABIMacOSX_i386.a
lib64/liblldbPluginABISysV_arm.a lib64/liblldbPluginABISysV_arm64.a
lib64/liblldbPluginABISysV_i386.a lib64/liblldbPluginABISysV_x86_64.a
lib64/liblldbPluginABISysV_hexagon.a lib64/liblldbPluginABISysV_ppc.a
lib64/liblldbPluginABISysV_ppc64.a lib64/liblldbPluginABISysV_mips.a
lib64/liblldbPluginABISysV_mips64.a lib64/liblldbPluginIn

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

[Daniel Sanders via lldb-dev]

> Have you accidentally checked out the test-suite into /projects? if it's 
> there it will auto-configure

We fixed it for rc1 but test-release.sh used to put the test-suite there.

From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of James 
Molloy via llvm-dev
Sent: 26 January 2016 16:05
To: Ismail Donmez; Nikola Smiljanic
Cc: Ben Pope; llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB 
Dev
Subject: Re: [llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged

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

James

On Tue, 26 Jan 2016 at 16:01 Ismail Donmez via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:
On Tue, Jan 26, 2016 at 1:56 PM, Nikola Smiljanic via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:
> Phase1 fails to build on openSUSE 13.2, can anyone see what's wrong from
> this log file?

Something wrong with the test-suite:

make -f CMakeFiles/test-suite.dir/build.make CMakeFiles/test-suite.dir/depend
make[2]: Entering directory
'/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
CMakeFiles/test-suite.dir/build.make:112: *** target pattern contains
no '%'.  Stop.
make[2]: Leaving directory
'/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
CMakeFiles/Makefile2:198: recipe for target
'CMakeFiles/test-suite.dir/all' failed
make[1]: *** [CMakeFiles/test-suite.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
___
cfe-dev mailing list
cfe-...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26335] lldb (after 3.7.x) compilation fails at link-time with shared library

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26335

lab...@google.com changed:

   What|Removed |Added

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

--- Comment #1 from lab...@google.com ---
It's a bit shot in the dark, but could you try if

solves your problem?

-- 
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] Fixing OS X Xcode build

[Todd Fiala via lldb-dev]

Hi all,

At the current moment the OS X Xcode build is broken.  I'll be working on
fixing it today.  As has been discussed in the past, post llvm/clang-3.8
the configure/automake system was getting stripped out of LLVM and clang.
The OS X Xcode build has a legacy step in it that still uses the
configure-based build system.  I'll be cleaning that up today.

In the meantime, expect if you use the Xcode build that you'll either need
to work with llvm/clang from earlier than yesterday (along with locally
undoing any changes in lldb for llvm/clang changes - there was at least one
yesterday), or just sit tight a bit.

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

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

[Todd Fiala via lldb-dev]

Okay.  I'm stuck fixing the OS X build, but if you have something else to
check, feel free to send it over my way and I can run it on another machine.

On Tue, Jan 26, 2016 at 7:52 PM, Zachary Turner  wrote:

> Humm..  it's a unicode literal, not sure why it's complaining.  I guess
> I'll have to crack open my linux machine and see what's going on tomorrow.
>
> On Tue, Jan 26, 2016 at 6:12 PM Todd Fiala  wrote:
>
>> I'm still getting a lot of these:
>>
>>
>> Traceback (most recent call last):
>>   File "test/dotest.py", line 7, in 
>> lldbsuite.test.run_suite()
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/dotest.py",
>> line 1089, in run_suite
>> resultclass=test_result.LLDBTestResult).run(configuration.suite)
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/runner.py",
>> line 162, in run
>> test(result)
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
>> line 65, in __call__
>> return self.run(*args, **kwds)
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
>> line 85, in run
>> self._wrapped_run(result)
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
>> line 115, in _wrapped_run
>> test._wrapped_run(result, debug)
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
>> line 117, in _wrapped_run
>> test(result)
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/case.py",
>> line 433, in __call__
>> return self.run(*args, **kwds)
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/third_party/Python/module/unittest2/unittest2/case.py",
>> line 369, in run
>> self.dumpSessionInfo()
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>> line 1810, in dumpSessionInfo
>> print(u"Session info generated @", datetime.datetime.now().ctime(),
>> file=self.session)
>> TypeError: must be unicode, not str
>>
>> On Tue, Jan 26, 2016 at 5:42 PM, Todd Fiala  wrote:
>>
>>> Oh missed this.  I'll give it a shot, hang on.
>>>
>>> On Tue, Jan 26, 2016 at 5:14 PM, Zachary Turner 
>>> wrote:
>>>
 Bump.  Can I re-submit this?

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

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

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

> I'm also not su

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

[Todd Fiala via lldb-dev]

Hi Pavel,

Will is trying to get this working downstream of here IIRC.

Greg, can you have a look and see what you think of the patch?  (Also see
Pavel's comments).

Thanks!

-Todd

On Wed, Jan 27, 2016 at 1:28 AM, Omair Javaid via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi Will,
>
> I dont understand REPL and thus the benefits it will have by making
> change to architecture name. I would not recommend to drop any
> information that we get from the host operating system.
>
> LLDB maintains core information alongwith triple in ArchSpec, may be
> you can parse triple to reflect correct core and use core instead of
> architecture name where needed.
>
> Kindly elaborate in a bit detail what are we getting out of this
> change for more accurate comments.
>
> Thanks!
>
> On 26 January 2016 at 14:47, Pavel Labath  wrote:
> > + Omair
> >
> > I don't really understand arm (sub)-architectures or REPL. The patch
> > seems mostly harmless, but it also feels like a hack to me. A couple
> > of questions:
> > - why does this only pose a problem for REPL?
> > - If I understand correctly, the problem is that someone is looking at
> > the architecture string contained in the Triple, and not finding what
> > it expects. Is that so? Could you point me to (some of) the places
> > that do that.
> >
> > Omair, any thoughts on this?
> >
> > cheers,
> > pl
> >
> >
> > On 25 January 2016 at 18:55, Hans Wennborg  wrote:
> >> This patch looks reasonable to me, but I don't know enough about LLDB
> >> to actually review it.
> >>
> >> +Renato or Pavel maybe?
> >>
> >> On Thu, Jan 14, 2016 at 11:32 AM, William Dillon via lldb-dev
> >>  wrote:
> >>> Hi again, everyone
> >>>
> >>> I’d like to ping on this patch now that the 3.8 branch is fairly new,
> and merging it over is fairly straight-forward.
> >>>
> >>> Thanks in advance for your comments!
> >>> - Will
> >>>
>  There is a small change that enables correct calculation of arm sub
> architectures while using the REPL on arm-linux.  As you may of may or may
> not know, linux appends ‘l’ to arm architecture versions to denote little
> endian.  This sometimes interferes with the determination of the
> architecture in the triple.  I experimented with adding sub architecture
> entries for these within lldb, but I discovered a simpler (and less
> invasive) method.  Because LLVM already knows how to handle some of these
> cases (I have a patch submitted for review that enables v6l; v7l already
> works), I am relying on llvm to clean it up.  The gist of it is that the
> llvm constructor (when given a triple string) retains the provided string
> unless an accessor mutates it.  Meanwhile, the accessors for the components
> go through the aliasing and parsing logic.  This code detects whether the
> sub-architecture that armv6l or armv7l aliases to is detected, and re-sets
> the architecture in the triple.  This overwrites the architecture that
> comes from linux, thus sanitizing it.
> 
>  Some kind of solution is required for the REPL to work on arm-linux.
> Without it, the REPL crashes.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>



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

[lldb-dev] [Bug 26339] New: TestCPPAuto.py fails on Windows

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26339

Bug ID: 26339
   Summary: TestCPPAuto.py fails on Windows
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: amcca...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

On Windows, expression commands like this:

  (lldb) expr struct Test { int x; int y; Test() : x(123), y(456) {} }; auto t
= Test(); t

result in:

  error: Can't run the expression locally: (null)

This requires more research to understand the root problem.

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

[Nikola Smiljanic via lldb-dev]

It seems that test-release was fixed, thanks everyone. Builds are OK but
I'd like to know where did test-suite go? All I see is the llvm.src
directory, am I supposed to export test-suite myself?

On Wed, Jan 27, 2016 at 9:47 PM, Daniel Sanders 
wrote:

> > Have you accidentally checked out the test-suite into /projects? if it's
> there it will auto-configure
>
>
>
> We fixed it for rc1 but test-release.sh used to put the test-suite there.
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] *On Behalf Of *James
> Molloy via llvm-dev
> *Sent:* 26 January 2016 16:05
> *To:* Ismail Donmez; Nikola Smiljanic
> *Cc:* Ben Pope; llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org);
> LLDB Dev
> *Subject:* Re: [llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged
>
>
>
> The test-suite shouldn't be being build with CMake for the release - the
> CMake system is not yet ready. Have you accidentally checked out the
> test-suite into /projects? if it's there it will auto-configure.
>
>
>
> James
>
>
>
> On Tue, 26 Jan 2016 at 16:01 Ismail Donmez via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
> On Tue, Jan 26, 2016 at 1:56 PM, Nikola Smiljanic via llvm-dev
>  wrote:
> > Phase1 fails to build on openSUSE 13.2, can anyone see what's wrong from
> > this log file?
>
> Something wrong with the test-suite:
>
> make -f CMakeFiles/test-suite.dir/build.make
> CMakeFiles/test-suite.dir/depend
> make[2]: Entering directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/test-suite.dir/build.make:112: *** target pattern contains
> no '%'.  Stop.
> make[2]: Leaving directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/Makefile2:198: recipe for target
> 'CMakeFiles/test-suite.dir/all' failed
> make[1]: *** [CMakeFiles/test-suite.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev