Re: [lldb-dev] [llvm-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

2015-08-23 Thread Dimitry Andric via lldb-dev
Finally, all building and testing succeeded, even with clang-tools-extra now 
(the tarballs became ~15% bigger). :)

Uploaded:

SHA256 (clang+llvm-3.7.0-rc3-i386-unknown-freebsd10.tar.xz) = 
319a7d6758bad7976dab2774309504432a69705c5662b38e05062018b71f655f
SHA256 (clang+llvm-3.7.0-rc3-amd64-unknown-freebsd10.tar.xz) = 
91997accc86379f7b2334ca9444a1fe017210871774153b87f4b1723125807fc

-Dimitry

> On 23 Aug 2015, at 01:33, Dimitry Andric via llvm-dev 
>  wrote:
> 
> Right, I found out the problem.  It's because clang-tools-extra's test 
> Makefile uses the temporary filename "lit.tmp" for both its main 
> lit.site.cfg, and for Unit/lit.site.cfg.  If these make jobs get run 
> simultaneously, one or the other temp file can unexpectedly disappear.
> 
> The following fixes it, similar to what is done in clang's own test Makefile. 
>  Hans, are you OK with me checking this in to clang-tools-extra trunk (not 
> sure who owns that), then merging it to the release_37 branch?  Then it is at 
> least fixed for the final build.
> 
> Index: tools/clang/tools/extra/test/Makefile
> ===
> --- tools/clang/tools/extra/test/Makefile   (revision 245796)
> +++ tools/clang/tools/extra/test/Makefile   (working copy)
> @@ -60,12 +60,12 @@
> Unit/lit.site.cfg: FORCE
>@echo "Making Unit/lit.site.cfg for Clang extra tools..."
>@$(MKDIR) $(dir $@)
> -   @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> lit.tmp
> -   @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> 
> lit.tmp
> -   @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> lit.tmp
> -   @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> 
> lit.tmp
> -   @sed -f lit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
> -   @-rm -f lit.tmp
> +   @$(ECHOPATH) s=@LLVM_LIBS_DIR@=$(LibDir)=g >> unit.tmp
> +   @$(ECHOPATH) s=@CLANG_TOOLS_BINARY_DIR@=$(PROJ_OBJ_DIR)/..=g >> 
> unit.tmp
> +   @$(ECHOPATH) s=@TARGET_TRIPLE@=$(TARGET_TRIPLE)=g >> unit.tmp
> +   @$(ECHOPATH) s=@CLANG_TOOLS_SOURCE_DIR@=$(PROJ_SRC_DIR)/..=g >> 
> unit.tmp
> +   @sed -f unit.tmp $(PROJ_SRC_DIR)/Unit/lit.site.cfg.in > $@
> +   @-rm -f unit.tmp
> 
> clean::
>@ find . -name Output | xargs rm -fr
> 
> -Dimitry
> 
>> On 23 Aug 2015, at 01:13, Dimitry Andric  wrote:
>> 
>> Still no complete go, doing the tests on i386 failed with some weird sed 
>> error:
>> 
>> [...]
>> Making Unit/lit.site.cfg for Clang extra tools...
>> sed: lit.tmp: No such file or directory
>> Makefile:61: recipe for target 'Unit/lit.site.cfg' failed
>> gmake[2]: *** [Unit/lit.site.cfg] Error 1
>> 
>> Strangely enough, this does not happen on amd64.  Maybe it is some sort of 
>> race condition?  Did anybody see this too?
>> 
>> Back to the investigation again... :(
>> 
>> -Dimitry
>> 
>>> On 22 Aug 2015, at 21:23, Dimitry Andric via llvm-dev 
>>>  wrote:
>>> 
>>> It's building with this patch now, already at Phase3, so it seems to work:
>>> 
>>> Index: trunk/utils/release/test-release.sh
>>> ===
>>> --- trunk/utils/release/test-release.sh (revision 245679)
>>> +++ trunk/utils/release/test-release.sh (working copy)
>>> @@ -266,43 +268,36 @@
>>>   check_valid_urls
>>> 
>>>   for proj in $projects ; do
>>> -if [ -d $proj.src ]; then
>>> -  echo "# Reusing $proj $Release-$RC sources"
>>> +case $proj in
>>> +llvm|openmp)
>>> +projsrc=$proj.src
>>> +;;
>>> +cfe)
>>> +projsrc=llvm.src/tools/clang
>>> +;;
>>> +clang-tools-extra)
>>> +projsrc=llvm.src/tools/clang/tools/extra
>>> +;;
>>> +compiler-rt|libcxx|libcxxabi|libunwind|test-suite)
>>> +projsrc=llvm.src/projects/$proj
>>> +;;
>>> +*)
>>> +echo "error: unknown project $proj"
>>> +exit 1
>>> +;;
>>> +esac
>>> +
>>> +if [ -d $projsrc ]; then
>>> +  echo "# Reusing $proj $Release-$RC sources in $projsrc"
>>> continue
>>>   fi
>>> -echo "# Exporting $proj $Release-$RC sources"
>>> -if ! svn export -q $Base_url/$proj/$ExportBranch $proj.src ; then
>>> +echo "# Exporting $proj $Release-$RC sources to $projsrc"
>>> +if ! svn export -q $Base_url/$proj/$ExportBranch $projsrc ; then
>>>   echo "error: failed to export $proj project"
>>>   exit 1
>>>   fi
>>>   done
>>> 
>>> -echo "# Creating symlinks"
>>> -cd $BuildDir/llvm.src/tools
>>> -if [ ! -h clang ]; then
>>> -ln -s ../../cfe.src clang
>>> -fi
>>> -cd $BuildDir/cfe.src/tools
>>> -if [ ! -h extra ]; then
>>> -ln -s ../../clang-tools-extra.src extra
>>> -fi
>>> -cd $BuildDir/llvm.src/projects
>>> -if [ -d $BuildDir/test-suite.src ] && [ ! -h test-suite ]; then
>>> -ln -s ../../test-suite.sr

Re: [lldb-dev] LLDB for bare-iron targets lacking support for qC /qfThreadInfo packet

2015-08-23 Thread Jaydeep Patil via lldb-dev
Hi Greg,

The '?' packet always returns 'S05'. There is no thread information available 
in any of the packets.

Regards,
Jaydeep

-Original Message-
From: Greg Clayton [mailto:clayb...@gmail.com] 
Sent: 21 August 2015 PM 09:43
To: Jaydeep Patil
Cc: lldb-dev@lists.llvm.org
Subject: Re: LLDB for bare-iron targets lacking support for qC /qfThreadInfo 
packet

One option is to send a ? packet to get a stop reply packet back. The stop 
reply should contain a "thread:;" key/value pair and you could just make 
the pid == tid == . We currently try these in the order below:

1 - qProcessInfo 
2 - qC
3 - qfThreadInfo

Now we could add a fourth:

4 - ?


> On Aug 21, 2015, at 12:23 AM, Jaydeep Patil  wrote:
> 
> Hi,
>  
> The gdb-stub running on a MIPS bare-iron board lacks support for qC 
> /qfThreadInfo packet.  Once the LLDB is connected to the target it cannot 
> proceed further as there is no process and/or thread information available 
> from the target. However GDB is able to debug the application as it ignores 
> the output of qC /qfThreadInfo packet if they are not supported. GDB assumes 
> that a process/thread X is available for debugging.
>  
> Is there any way in LLDB to support such bare-iron targets where qC 
> /qfThreadInfo packets are not supported?
>  
> Regards,
> Jaydeep

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