Re: [lldb-dev] LLDB behaviour for GCed sections

[Earlam, David via lldb-dev]

Hi James,

I performed a quick experiment with clang –g –ffunction-sections and link with 
–gc-sections with Hexagon DSP tools based on llvm3.5.

This shows an unused function as having DW_AT_low_pc as zero as you predict:

readelf –W extract of DWARF4 .debug_info)

<1><2b7>: Abbrev Number: 11 (DW_TAG_subprogram)
 DW_AT_low_pc  : 0
 DW_AT_high_pc : 168
 DW_AT_frame_base  :
 DW_AT_name: (indirect string, offset: 0x1bb): not_used
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 83
 DW_AT_prototyped  : 1
 DW_AT_type: <45d>
 DW_AT_external: 1
 DW_AT_accessibility: 1 

Yet  lldb 3.5.0  and lldb 3.9 both appear to _not_ ignore that DWARF DIE.

(lldb) expression ¬_used
(int (*)(unsigned char *, const unsigned char *, unsigned long)) $0 = 0x

and

(lldb) breakpoint set --name not_used
Breakpoint 1: where = hexlto.elf`not_used + 20 at lto_test.c:92, address = 
0x0014

Line 92 would be the first statement after prolog in that source file - if the 
function were used - but address 0x14 is just wrong
as it is inside the start-up code. I assume lldb is compensating for the 
instruction address offset to the first statement in that removed function.

The command ‘disassemble –name not_used’ reveals the confusion - which makes it 
appear as though not_used() is present but does not begin with the
typical Hexagon allocframe instruction that I’d expect for C and instead shows 
startup code.

The newest llvm3.9 linker for Hexagon (an internal unreleased version here) 
sets the DW_AT_low_pc to a none zero value apparently far beyond the end of the 
.text extent which might be a hint
to a DWARF consumer or a mistake. 

For a DW_TAG_subprogram would n’t it be more sensible for the linker to set 
DW_AT_low_pc and DW_AT_high_pc to the same value for garbage collected 
unreferenced code?
From the DWARF definition that the high_pc - when of class ADDRESS - is beyond 
the end of the subprogram extent - It then clearly has no machine code.
Or for high_pc to also be set to 0 -when of class CONSTANT - it then clearly 
has no machine code. 

For data  objects and a Harvard architecture address 0 is however valid, as 
weird as that may seem to C programmers. So for the Qualcomm Kalimba DSP and 
the XAP RISC CPU used in 
Bluetooth devices our proprietary debuggers look for a specific address  value 
that we hope is greater than we ever expect to be used as a real address of any 
memory attached to an embedded device.

As far as I know there’s no way for DWARF to convey that  something has been 
optimised away except a DW_AT_location empty location list for a variable.

Of course, a linker should be able to remove the DWARF DIEs for unreferenced 
code and data when it garbage collects.
But I’ve not come across one that does this yet. I believe it is difficult for 
linker implementors because of the inter-section references and relative 
offsets in DWARF. 

Not tried with llvm 4.0 or lld or gold.


David Earlam
Staff-Senior[Engineer]/Manager ? Software : Development Tools() {
Qualcomm Technologies International, Ltd.
.

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of James 
Henderson via lldb-dev
Sent: 06 March 2017 13:51
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] LLDB behaviour for GCed sections

Hi,
 
I’m currently investigating the behaviour of different debuggers when functions 
have been stripped by the linker because they are unused. I tried looking at 
the source code, but couldn’t really make enough sense of it to answer the 
question. Would someone be able to explain what LLDB’s behaviour is when it 
encounters a function in debug information with an address of zero (as is the 
case for lld and other linker output with --gc-sections)? In particular, does 
it simply ignore the relevant block of debug information, as appears to be the 
case for gdb? I’m coming at this from a DWARF perspective, if that makes any 
difference.
 
James
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Google Summer of Code 2017: Call for Mentors & Projects

[Anton Korobeynikov via lldb-dev]

Dear All,

On behalf of LLVM Foundation I would like to announce that LLVM will
be participating in Google Summer of Code this year. GSoC this year
will be quite different from what we saw over last years, so stay
tuned for updates!

Thanks to Vassil, 'Open Projects' pages received a major update this
year, but still please let me know, if:
 - You're LLVM contributor and would like to mentor some of projects
listed there
 - You're LLVM contributor and you're thinking you're having a decent
project for this summer

The 'Open Projects' pages could be found at:
http://llvm.org/OpenProjects.html#gsoc17

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Xcode and Pascal (FPC)

[via lldb-dev]

Hi,

For many years I’m using Xcode to compile and debug source code written in 
Pascal (Free Pascal Compiler).
Previously using the gdb-debugger.

With the lldb debugger the "Debug Bar-Proces Controls" and breakpoints still 
works fine.
Variables values are displayed in the "View variables”.
Thanks to the LLDB Debugger development team!

But the Pascal language is not case-sensitive.
All variable names are displayed in upper case, thus for printing values in the 
“View console output” the variable names has to be typed in upper case.
Consequently copy and past of the variable names from the source editor can’t 
be used.
Unfortunately also inspecting variables directly in the source editor will not 
work, unless they are typed in upper case.

Using the lldb-debugger would be much more practical if Pascal variable names 
could be copy/past directly from source editor into the console and/or Pascal 
variables could be inspected directly into the source editor.

Any workaround work around or recommendations how to solve this issue?

I really appreciate any help someone can provide.


Marc



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

Re: [lldb-dev] LLDB behaviour for GCed sections

[James Henderson via lldb-dev]

Thank you for the effort put into this response. It's interesting to see
that there are problems with LLDB's handling here. This might mean we need
to have a wider discussion about how LLD does its --gc-sections and/or how
LLDB treats this situation. From experience working with our proprietary
linker and debugger, this issue is something that both sides have to agree
on. It looks like we currently follow a similar policy to your tools.

Due to changes in how the compiler emitted DWARF information, we discovered
some time ago that we cannot simply patch the high_pc field to be the same
as the low_pc field, because the compiler started to use the high_pc field
to indicate the size instead. Whilst this reduces the number of relocations
the linker has to perform, it does make it difficult for the linker to
patch the high_pc field reliably, without parsing the debug_info section,
so it is necessary to come up with a different approach, hence the invalid
address approach used in some cases.

Anyway, thanks for this once again.

Regards,

James


On 9 March 2017 at 11:03, Earlam, David  wrote:

> Hi James,
>
> I performed a quick experiment with clang –g –ffunction-sections and link
> with –gc-sections with Hexagon DSP tools based on llvm3.5.
>
> This shows an unused function as having DW_AT_low_pc as zero as you
> predict:
>
> readelf –W extract of DWARF4 .debug_info)
>
> <1><2b7>: Abbrev Number: 11 (DW_TAG_subprogram)
>  DW_AT_low_pc  : 0
>  DW_AT_high_pc : 168
>  DW_AT_frame_base  :
>  DW_AT_name: (indirect string, offset: 0x1bb): not_used
>  DW_AT_decl_file   : 1
>  DW_AT_decl_line   : 83
>  DW_AT_prototyped  : 1
>  DW_AT_type: <45d>
>  DW_AT_external: 1
>  DW_AT_accessibility: 1
>
> Yet  lldb 3.5.0  and lldb 3.9 both appear to _not_ ignore that DWARF DIE.
>
> (lldb) expression ¬_used
> (int (*)(unsigned char *, const unsigned char *, unsigned long)) $0 =
> 0x
>
> and
>
> (lldb) breakpoint set --name not_used
> Breakpoint 1: where = hexlto.elf`not_used + 20 at lto_test.c:92, address =
> 0x0014
>
> Line 92 would be the first statement after prolog in that source file - if
> the function were used - but address 0x14 is just wrong
> as it is inside the start-up code. I assume lldb is compensating for the
> instruction address offset to the first statement in that removed function.
>
> The command ‘disassemble –name not_used’ reveals the confusion - which
> makes it appear as though not_used() is present but does not begin with the
> typical Hexagon allocframe instruction that I’d expect for C and instead
> shows startup code.
>
> The newest llvm3.9 linker for Hexagon (an internal unreleased version
> here) sets the DW_AT_low_pc to a none zero value apparently far beyond the
> end of the .text extent which might be a hint
> to a DWARF consumer or a mistake.
>
> For a DW_TAG_subprogram would n’t it be more sensible for the linker to
> set DW_AT_low_pc and DW_AT_high_pc to the same value for garbage collected
> unreferenced code?
> From the DWARF definition that the high_pc - when of class ADDRESS - is
> beyond the end of the subprogram extent - It then clearly has no machine
> code.
> Or for high_pc to also be set to 0 -when of class CONSTANT - it then
> clearly has no machine code.
>
> For data  objects and a Harvard architecture address 0 is however valid,
> as weird as that may seem to C programmers. So for the Qualcomm Kalimba DSP
> and the XAP RISC CPU used in
> Bluetooth devices our proprietary debuggers look for a specific address
> value that we hope is greater than we ever expect to be used as a real
> address of any memory attached to an embedded device.
>
> As far as I know there’s no way for DWARF to convey that  something has
> been optimised away except a DW_AT_location empty location list for a
> variable.
>
> Of course, a linker should be able to remove the DWARF DIEs for
> unreferenced code and data when it garbage collects.
> But I’ve not come across one that does this yet. I believe it is difficult
> for linker implementors because of the inter-section references and
> relative offsets in DWARF.
>
> Not tried with llvm 4.0 or lld or gold.
>
>
> David Earlam
> Staff-Senior[Engineer]/Manager ? Software : Development Tools() {
> Qualcomm Technologies International, Ltd.
> .
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> James Henderson via lldb-dev
> Sent: 06 March 2017 13:51
> To: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] LLDB behaviour for GCed sections
>
> Hi,
>
> I’m currently investigating the behaviour of different debuggers when
> functions have been stripped by the linker because they are unused. I tried
> looking at the source code, but couldn’t really make enough sense of it to
> answer the question. Would someone be able to explain what LLDB’s behaviour
> is when it encounters a function in debug information with an address of
> zero (as is the case for lld and other linker ou

Re: [lldb-dev] LLDB behaviour for GCed sections

[James Henderson via lldb-dev]

Thank you for the effort put into this response. It's interesting to see
that there are problems with LLDB's handling here. This might mean we need
to have a wider discussion about how LLD does its --gc-sections. From
experience working with our proprietary linker and debugger, this issue is
something that both sides have to agree on. We too ended up going with an
invalid address to mark the low_pc field for discarded elements.

Due to changes in how the compiler emitted DWARF information, we discovered
some time ago that we cannot simply patch the high_pc field to be the same
as the low_pc field, because the compiler started to use the high_pc field
to indicate the size instead. Whilst this reduces the number of relocations
the linker has to perform, it does make it difficult for the linker to
patch the high_pc field reliably, without parsing the debug_info section.

Regards,

James


On 9 March 2017 at 11:03, Earlam, David  wrote:

> Hi James,
>
> I performed a quick experiment with clang –g –ffunction-sections and link
> with –gc-sections with Hexagon DSP tools based on llvm3.5.
>
> This shows an unused function as having DW_AT_low_pc as zero as you
> predict:
>
> readelf –W extract of DWARF4 .debug_info)
>
> <1><2b7>: Abbrev Number: 11 (DW_TAG_subprogram)
>  DW_AT_low_pc  : 0
>  DW_AT_high_pc : 168
>  DW_AT_frame_base  :
>  DW_AT_name: (indirect string, offset: 0x1bb): not_used
>  DW_AT_decl_file   : 1
>  DW_AT_decl_line   : 83
>  DW_AT_prototyped  : 1
>  DW_AT_type: <45d>
>  DW_AT_external: 1
>  DW_AT_accessibility: 1
>
> Yet  lldb 3.5.0  and lldb 3.9 both appear to _not_ ignore that DWARF DIE.
>
> (lldb) expression ¬_used
> (int (*)(unsigned char *, const unsigned char *, unsigned long)) $0 =
> 0x
>
> and
>
> (lldb) breakpoint set --name not_used
> Breakpoint 1: where = hexlto.elf`not_used + 20 at lto_test.c:92, address =
> 0x0014
>
> Line 92 would be the first statement after prolog in that source file - if
> the function were used - but address 0x14 is just wrong
> as it is inside the start-up code. I assume lldb is compensating for the
> instruction address offset to the first statement in that removed function.
>
> The command ‘disassemble –name not_used’ reveals the confusion - which
> makes it appear as though not_used() is present but does not begin with the
> typical Hexagon allocframe instruction that I’d expect for C and instead
> shows startup code.
>
> The newest llvm3.9 linker for Hexagon (an internal unreleased version
> here) sets the DW_AT_low_pc to a none zero value apparently far beyond the
> end of the .text extent which might be a hint
> to a DWARF consumer or a mistake.
>
> For a DW_TAG_subprogram would n’t it be more sensible for the linker to
> set DW_AT_low_pc and DW_AT_high_pc to the same value for garbage collected
> unreferenced code?
> From the DWARF definition that the high_pc - when of class ADDRESS - is
> beyond the end of the subprogram extent - It then clearly has no machine
> code.
> Or for high_pc to also be set to 0 -when of class CONSTANT - it then
> clearly has no machine code.
>
> For data  objects and a Harvard architecture address 0 is however valid,
> as weird as that may seem to C programmers. So for the Qualcomm Kalimba DSP
> and the XAP RISC CPU used in
> Bluetooth devices our proprietary debuggers look for a specific address
> value that we hope is greater than we ever expect to be used as a real
> address of any memory attached to an embedded device.
>
> As far as I know there’s no way for DWARF to convey that  something has
> been optimised away except a DW_AT_location empty location list for a
> variable.
>
> Of course, a linker should be able to remove the DWARF DIEs for
> unreferenced code and data when it garbage collects.
> But I’ve not come across one that does this yet. I believe it is difficult
> for linker implementors because of the inter-section references and
> relative offsets in DWARF.
>
> Not tried with llvm 4.0 or lld or gold.
>
>
> David Earlam
> Staff-Senior[Engineer]/Manager ? Software : Development Tools() {
> Qualcomm Technologies International, Ltd.
> .
>
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> James Henderson via lldb-dev
> Sent: 06 March 2017 13:51
> To: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] LLDB behaviour for GCed sections
>
> Hi,
>
> I’m currently investigating the behaviour of different debuggers when
> functions have been stripped by the linker because they are unused. I tried
> looking at the source code, but couldn’t really make enough sense of it to
> answer the question. Would someone be able to explain what LLDB’s behaviour
> is when it encounters a function in debug information with an address of
> zero (as is the case for lld and other linker output with --gc-sections)?
> In particular, does it simply ignore the relevant block of debug
> information, as appears to be the case for gdb? I’m coming at t

Re: [lldb-dev] LLDB behaviour for GCed sections

[Jim Ingham via lldb-dev]

We encounter low pc values of 0 quite often macOS, since we leave the DWARF in 
.o file and then use a debug-map to fix up the addresses (and remove unused 
functions).  The first function in a .o file is often at 0.  Just a data point 
in favor of choosing something other than a low pc of 0 to mean discarded.

Jim


> On Mar 9, 2017, at 6:01 AM, James Henderson via lldb-dev 
>  wrote:
> 
> Thank you for the effort put into this response. It's interesting to see that 
> there are problems with LLDB's handling here. This might mean we need to have 
> a wider discussion about how LLD does its --gc-sections. From experience 
> working with our proprietary linker and debugger, this issue is something 
> that both sides have to agree on. We too ended up going with an invalid 
> address to mark the low_pc field for discarded elements.
> 
> Due to changes in how the compiler emitted DWARF information, we discovered 
> some time ago that we cannot simply patch the high_pc field to be the same as 
> the low_pc field, because the compiler started to use the high_pc field to 
> indicate the size instead. Whilst this reduces the number of relocations the 
> linker has to perform, it does make it difficult for the linker to patch the 
> high_pc field reliably, without parsing the debug_info section.
> 
> Regards,
> 
> James
> 
> 
> On 9 March 2017 at 11:03, Earlam, David  > wrote:
> Hi James,
> 
> I performed a quick experiment with clang –g –ffunction-sections and link 
> with –gc-sections with Hexagon DSP tools based on llvm3.5.
> 
> This shows an unused function as having DW_AT_low_pc as zero as you predict:
> 
> readelf –W extract of DWARF4 .debug_info)
> 
> <1><2b7>: Abbrev Number: 11 (DW_TAG_subprogram)
>  DW_AT_low_pc  : 0
>  DW_AT_high_pc : 168
>  DW_AT_frame_base  :
>  DW_AT_name: (indirect string, offset: 0x1bb): not_used
>  DW_AT_decl_file   : 1
>  DW_AT_decl_line   : 83
>  DW_AT_prototyped  : 1
>  DW_AT_type: <45d>
>  DW_AT_external: 1
>  DW_AT_accessibility: 1
> 
> Yet  lldb 3.5.0  and lldb 3.9 both appear to _not_ ignore that DWARF DIE.
> 
> (lldb) expression ¬_used
> (int (*)(unsigned char *, const unsigned char *, unsigned long)) $0 = 
> 0x
> 
> and
> 
> (lldb) breakpoint set --name not_used
> Breakpoint 1: where = hexlto.elf`not_used + 20 at lto_test.c:92, address = 
> 0x0014
> 
> Line 92 would be the first statement after prolog in that source file - if 
> the function were used - but address 0x14 is just wrong
> as it is inside the start-up code. I assume lldb is compensating for the 
> instruction address offset to the first statement in that removed function.
> 
> The command ‘disassemble –name not_used’ reveals the confusion - which makes 
> it appear as though not_used() is present but does not begin with the
> typical Hexagon allocframe instruction that I’d expect for C and instead 
> shows startup code.
> 
> The newest llvm3.9 linker for Hexagon (an internal unreleased version here) 
> sets the DW_AT_low_pc to a none zero value apparently far beyond the end of 
> the .text extent which might be a hint
> to a DWARF consumer or a mistake.
> 
> For a DW_TAG_subprogram would n’t it be more sensible for the linker to set 
> DW_AT_low_pc and DW_AT_high_pc to the same value for garbage collected 
> unreferenced code?
> From the DWARF definition that the high_pc - when of class ADDRESS - is 
> beyond the end of the subprogram extent - It then clearly has no machine code.
> Or for high_pc to also be set to 0 -when of class CONSTANT - it then clearly 
> has no machine code.
> 
> For data  objects and a Harvard architecture address 0 is however valid, as 
> weird as that may seem to C programmers. So for the Qualcomm Kalimba DSP and 
> the XAP RISC CPU used in
> Bluetooth devices our proprietary debuggers look for a specific address  
> value that we hope is greater than we ever expect to be used as a real 
> address of any memory attached to an embedded device.
> 
> As far as I know there’s no way for DWARF to convey that  something has been 
> optimised away except a DW_AT_location empty location list for a variable.
> 
> Of course, a linker should be able to remove the DWARF DIEs for unreferenced 
> code and data when it garbage collects.
> But I’ve not come across one that does this yet. I believe it is difficult 
> for linker implementors because of the inter-section references and relative 
> offsets in DWARF.
> 
> Not tried with llvm 4.0 or lld or gold.
> 
> 
> David Earlam
> Staff-Senior[Engineer]/Manager ? Software : Development Tools() {
> Qualcomm Technologies International, Ltd.
> .
> 
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org 
> ] On Behalf Of James Henderson via 
> lldb-dev
> Sent: 06 March 2017 13:51
> To: lldb-dev@lists.llvm.org 
> Subject: [lldb-dev] LLDB behaviour for GCed sections
> 
> Hi,

Re: [lldb-dev] [Release-testers] [4.0.0 Release] 'final' has been tagged

[Dimitry Andric via lldb-dev]

On 9 Mar 2017, at 01:52, Hans Wennborg via Release-testers 
 wrote:
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). There were no changes after rc4.
> 
> Please build the final binaries and upload to the sftp.

Built and tested OK on FreeBSD 10.  I have uploaded:

SHA256 (clang+llvm-4.0.0-i386-unknown-freebsd10.tar.xz) = 
f3bfd0e4778d5e6b94f774e4531a61a662c7688e08b54cef5e5fc53711e65243
SHA256 (clang+llvm-4.0.0-amd64-unknown-freebsd10.tar.xz) = 
e8878b589c2558aeb9733661e9a23fd47d41be0dc200aa50acf7a7eb1ab53eee

-Dimitry



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

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Release Candidate 4 has been tagged

[Renato Golin via lldb-dev]

On 7 March 2017 at 22:15, Hans Wennborg via Release-testers
 wrote:
> Dear testers,
>
> 4.0.0-rc4 was just tagged from the branch at r297204.
>
> This is very similar to rc3, with additional fixes for PR32142 and PR32153.

Both ARM and AArch64 look good. The weird fluke on AArch64 is gone.

I'm running the final now.

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

Re: [lldb-dev] [Release-testers] [4.0.0 Release] 'final' has been tagged

[Sylvestre Ledru via lldb-dev]

Le 09/03/2017 à 01:52, Hans Wennborg via Release-testers a écrit :
> Dear testers,
>
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). There were no changes after rc4.
>
> Please build the final binaries and upload to the sftp.
>
> For others following along: this means 4.0.0 is complete, but it will
> take a few days to get the tarballs ready and uploaded to the web
> page. I will send the announcement once everything's done.
>
> Many thanks for your hard work!
thank you for your work :)

Uploaded in Debian, currently building:
https://buildd.debian.org/status/package.php?p=llvm-toolchain-4.0
S

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

Re: [lldb-dev] [4.0.0 Release] 'final' has been tagged

[Hans Wennborg via lldb-dev]

On Wed, Mar 8, 2017 at 4:52 PM, Hans Wennborg  wrote:
> Dear testers,
>
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). There were no changes after rc4.
>
> Please build the final binaries and upload to the sftp.

Windows:

$ sha1sum *LLVM-4.0.0-win*.exe
b48a3dab37e2a1b5a5446b316832b9b80c6bd557  LLVM-4.0.0-win32.exe
5588c00484d5e1fe05bcce8201282b172448f6fc  LLVM-4.0.0-win64.exe

Build script attached.


build_llvm_400._bat_
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] 'final' has been tagged

[Bernhard Rosenkränzer via lldb-dev]

Hi,
built and passed core tests on OpenMandriva x86_64, aarch64, x86_32 and
armv7hl.

ttyl
bero

On 9 March 2017 at 01:52, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). There were no changes after rc4.
>
> Please build the final binaries and upload to the sftp.
>
> For others following along: this means 4.0.0 is complete, but it will
> take a few days to get the tarballs ready and uploaded to the web
> page. I will send the announcement once everything's done.
>
> Many thanks for your hard work!
>
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev