[I thought I had already sent this out weeks ago…]
> On Oct 2, 2020, at 2:13 PM, Greg Clayton via lldb-dev
> wrote:
>
> Yes this is bad, and GetDescription() is used as a convenience to print out
> the module path (which might be a .o file within a .a file) and optionally
https://bugs.llvm.org/show_bug.cgi?id=47826
Bug ID: 47826
Summary: Cannot attach to a process with exited leader thread
(TID==PID)
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
https://bugs.llvm.org/show_bug.cgi?id=47820
Bug ID: 47820
Summary: Correct vFile:pread/pwrite packet format
incompatibility with gdb
Product: lldb
Version: 11.0
Hardware: All
OS: All
Status: NEW
I am pleased to announce that LLVM 11 is now finally available.
Get it here: https://releases.llvm.org/download.html#11.0.0
This release is the result of the LLVM community's efforts over the
past six months (up to 2e10b7a3 on trunk plus commits up to 176249bd
on the release/11.x branch).
One
Hi,
Uploaded Arm & AArch64:
95449841c1c4b0164414e58b1053a3877e3bd73d9b1b3e15e5d1d4c2fd5cae1e
clang+llvm-11.0.0-rc6-aarch64-linux-gnu.tar.xz
40ba7c35c5430cc2775b8dbf0bc4687d7a466c29332b89193de903ea4557fb05
clang+llvm-11.0.0-rc6-armv7a-linux-gnueabihf.tar.xz
Same as previous rc's.
Cheers,
Diana
On 7 Oct 2020, at 16:40, Hans Wennborg via Release-testers
wrote:
>
> A few more issues appeared, so here is yet another release candidate:
> llvmorg-11.0.0-rc6 was just tagged.
I've built rc6, and again this did not need any patches.
Main results on amd64-freebsd11:
Unsupported:
> On Oct 8, 2020, at 10:37 PM, Greg Clayton wrote:
>
>
>
>> On Oct 8, 2020, at 10:29 PM, Jason Molenda wrote:
>>
>>
>>
>>> On Oct 8, 2020, at 10:06 PM, Jason Molenda wrote:
>>>
>>>
>>>
On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
> On Oct 8, 2020, at
> On Oct 8, 2020, at 10:29 PM, Jason Molenda wrote:
>
>
>
>> On Oct 8, 2020, at 10:06 PM, Jason Molenda wrote:
>>
>>
>>
>>> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
>>>
>>>
>>>
On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote:
Good bug find!
It seems
> On Oct 8, 2020, at 10:06 PM, Jason Molenda wrote:
>
>
>
>> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
>>
>>
>>
>>> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote:
>>>
>>> Good bug find!
>>>
>>> It seems to me that DWARFCallFrameInfo should push the initial CIE register
>>>
> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
>
>
>
>> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote:
>>
>> Good bug find!
>>
>> It seems to me that DWARFCallFrameInfo should push the initial CIE register
>> setup instructions as being the state at offset 0 in the function (in fact
> On Oct 8, 2020, at 9:17 PM, Greg Clayton wrote:
>
>
>
>> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote:
>>
>> Good bug find!
>>
>> It seems to me that DWARFCallFrameInfo should push the initial CIE register
>> setup instructions as being the state at offset 0 in the function (in fact
> On Oct 8, 2020, at 8:55 PM, Jason Molenda wrote:
>
> Good bug find!
>
> It seems to me that DWARFCallFrameInfo should push the initial CIE register
> setup instructions as being the state at offset 0 in the function (in fact
> I'd say it's a bug if it's not). If that were done, then
Good bug find!
It seems to me that DWARFCallFrameInfo should push the initial CIE register
setup instructions as being the state at offset 0 in the function (in fact I'd
say it's a bug if it's not). If that were done, then getting RowAtIndex(0)
should be synonymous with
On 2020-10-08, Greg Clayton via lldb-dev wrote:
Hello LLDB devs,
This is a deep dive into an issue I found in the LLDB handling of DWARF call
frame information, so no need to read further if this doesn't interest you!
I am in the process of adding some support to LLVM for parsing the opcode
Hello LLDB devs,
This is a deep dive into an issue I found in the LLDB handling of DWARF call
frame information, so no need to read further if this doesn't interest you!
I am in the process of adding some support to LLVM for parsing the opcode state
machines for CIE and FDE objects that
https://bugs.llvm.org/show_bug.cgi?id=47766
Bug ID: 47766
Summary: String formatter regex wrongly catching
multi-dimensional types as well.
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
https://bugs.llvm.org/show_bug.cgi?id=47758
Bug ID: 47758
Summary: Stop with a watchpoint, only on register values
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
> On Oct 7, 2020, at 5:29 PM, Greg Clayton wrote:
>
>
>
>> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>
>>
>>
>>> On Oct 7, 2020, at 12:11 PM, Pavel Labath >> <mailto
> On Oct 7, 2020, at 12:16 PM, Jim Ingham via lldb-dev
> wrote:
>
>
>
>> On Oct 7, 2020, at 12:11 PM, Pavel Labath wrote:
>>
>> On 07/10/2020 21:01, Jim Ingham wrote:
>>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath >>> <mailto:pa.
> On Oct 7, 2020, at 12:11 PM, Pavel Labath wrote:
>
> On 07/10/2020 21:01, Jim Ingham wrote:
>>> On Oct 7, 2020, at 11:44 AM, Pavel Labath >> <mailto:pa...@labath.sk>> wrote:
>>>
>>> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
&g
On 07/10/2020 21:01, Jim Ingham wrote:
On Oct 7, 2020, at 11:44 AM, Pavel Labath <mailto:pa...@labath.sk>> wrote:
On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
There isn’t a built-in summary formatter for two dimensional arrays
of chars, but the type is matching the regex fo
> On Oct 7, 2020, at 11:44 AM, Pavel Labath wrote:
>
> On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
>> There isn’t a built-in summary formatter for two dimensional arrays of
>> chars, but the type is matching the regex for the one-dimensional
>> StringSumm
On 07/10/2020 20:42, Jim Ingham via lldb-dev wrote:
There isn’t a built-in summary formatter for two dimensional arrays of
chars, but the type is matching the regex for the one-dimensional
StringSummaryFormat, but that doesn’t actually know how to format two
dimensional arrays of chars
first and the match is granted to
the first hit, so if you need this yourself, in the meantime you could write
your own formatter and it should fire.
Jim
> On Oct 7, 2020, at 5:26 AM, Chirag Patel via lldb-dev
> wrote:
>
> Hello all,
>
> While debugging and printing struc
https://bugs.llvm.org/show_bug.cgi?id=47743
lab...@google.com changed:
What|Removed |Added
Assignee|lldb-dev@lists.llvm.org |lab...@google.com
--- Comment #3 from
Hi,
I'm trying to run the lldb tests on Windows (fresh installs of VS2019 16.7.5,
Python 3.8.5, and Swig 4.0.2). The API tests crash immediately in python
initialization code:
Windows fatal exception: access violation
Current thread 0x693c (most recent call first):
File "", line 219 in
Hello once again,
A few more issues appeared, so here is yet another release candidate:
llvmorg-11.0.0-rc6 was just tagged.
Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc6
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc6
Pre-built binaries
Hello all,
While debugging and printing struct with multi-dimensional char array, gdb
successfully prints string while lldb bails out with only printing address.
For simple C testcase,
struct b {
char i[2][4];
};
int main() {
struct b z;
z.i[0][0] = 'F';
https://bugs.llvm.org/show_bug.cgi?id=47743
Bug ID: 47743
Summary: LLDB displays wrong values for packed bitfields
Product: lldb
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
On 02/10/2020 23:13, Greg Clayton wrote:
Yes this is bad, and GetDescription() is used as a convenience to print out the
module path (which might be a .o file within a .a file) and optionally
architecture of the module. It probably shouldn't be taking the module lock as
the only member
Hi,
Uploaded arm & aarch64:
3e2dbe0dcdaa82aaba4480c9b5d042846858903bff743259a1b63a36c75ba9d7
clang+llvm-11.0.0-rc4-armv7a-linux-gnueabihf.tar.xz
8fa05ddb6fe4e49c4347f3decdbcaa623f3b0e88fc6a264058f05fc0ed3d71e0
clang+llvm-11.0.0-rc4-aarch64-linux-gnu.tar.xz
No new regressions.
Cheers,
Diana
On
the mutex in GetDescription? Seems
like this deadlock is easy to trigger if you have DWARF with errors or warnings
inside of it.
Greg
> On Oct 2, 2020, at 6:50 AM, Dmitry Antipov via lldb-dev
> wrote:
>
> I'm observing the following deadlock:
>
> One thread calls Module::Prel
> On Oct 2, 2020, at 3:51 AM, Pavel Labath wrote:
>
> On 01/10/2020 22:32, Walter wrote:
>> After a chat with Greg, we agreed on this set of commands
>>
>>
>> trace load /path/to/json process trace start/stop process trace save
>> /path/to/json thread trace start/stop thread trace dump
I'm observing the following deadlock:
One thread calls Module::PreloadSymbols() which takes m_mutex of this Module.
Module::PreloadSymbols()
calls ManualDWARFIndex::Index(), which, in turn, creates thread pool and waits
for all threads completion:
(gdb)
#0 futex_wait_cancelable (private=0,
On 01/10/2020 22:32, Walter wrote:
> After a chat with Greg, we agreed on this set of commands
>
>
> trace load /path/to/json process trace start/stop process trace save
> /path/to/json thread trace start/stop thread trace dump [instructions |
> functions]
>
Thanks. The new commands look good
Uploaded binaries for SLES12 and Ubuntu 16 x86_64. I realized that I'd
forgotten rc3,4 ones so I uploaded them too.
$ cat clang+llvm-11.0.0-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sha256
clang+llvm-11.0.0-rc3-x86_64-linux-sles12.4.tar.xz.sha256
| functions]
>>
>>
>> Il giorno gio 1 ott 2020 alle ore 13:21 Greg Clayton > <mailto:clayb...@gmail.com>> ha scritto:
>>
>>
>> > On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev
>> > mailto:lldb-dev@lists.llvm.org>> wrote:
>> >
>
gmail.com>> ha scritto:
>
>
> > On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > Thank you for writing this Walter. I think this document will be a
> > useful reference both now and in the fut
ersion that is about to
be released.
Greg
> On Sep 16, 2020, at 9:03 AM, le wang via lldb-dev
> wrote:
>
> Hello,everyone:
> I've got a problem, when debugging my process with lldb tool on linux
> OS(CentOS7).While I use lldb command to set breakpoints, and launch m
gt; On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Thank you for writing this Walter. I think this document will be a
> > useful reference both now and in the future.
> >
> > The part that's not clear to me
> On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev
> wrote:
>
> Thank you for writing this Walter. I think this document will be a
> useful reference both now and in the future.
>
> The part that's not clear to me is what is the story with multi-process
> traces.
> While we could certainly make "target create --trace" create multiple
> targets, that would be fairly unusual. OTOH, the whole concept of having
> multiple targets share something is a pretty unusual thing for lldb.
> That's why I'd like to hear more about where you want to go with
On 30 Sep 2020, at 20:07, Hans Wennborg via Release-testers
wrote:
>
> We had to pick up another bug fix, so here is another release
> candidate: llvmorg-11.0.0-rc5 tag was just created.
I've built both rc4 and rc5, and again these did not need any patches.
Main results on amd64-freebsd11:
n is the multi-process traces.
While we could certainly make "target create --trace" create multiple
targets, that would be fairly unusual. OTOH, the whole concept of having
multiple targets share something is a pretty unusual thing for lldb.
That's why I'd like to hear more about where you w
Glad we know why at least! Thanks for bringing this to our attention.
Greg
> On Sep 30, 2020, at 2:53 AM, Dmitry Antipov wrote:
>
> On 9/29/20 11:40 PM, Greg Clayton wrote:
>
>> How could LLDB even function then? We are using the standard std::mutex +
>> std::condition workflow here. Not
Hello again,
We had to pick up another bug fix, so here is another release
candidate: llvmorg-11.0.0-rc5 tag was just created.
Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc5
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc5
Pre-built
On 9/29/20 11:40 PM, Greg Clayton wrote:
How could LLDB even function then? We are using the standard std::mutex +
std::condition workflow here. Not sure how LLDB could even function if it
locking was nor working as expected.
Well, obviously this is an issue (and probably the same one) with
How could LLDB even function then? We are using the standard std::mutex +
std::condition workflow here. Not sure how LLDB could even function if it
locking was nor working as expected.
Doing a quick web search, this seems to be due to a mismatched libc++ and
libstdc++:
On 9/25/20 5:53 PM, Dmitry Antipov wrote:
On 9/24/20 9:14 PM, Greg Clayton wrote:
This must be a valgrind issue, there would be major problems if the OS isn't able to lock mutex objects correctly ("mutex is locked simultaneously by two threads"). It is getting confused by a
recursive mutex?
which all
processes receive (from the operating system) when one of their children
dies. They just mean that your process has executed some subprocess and
that subprocess has terminated.
pl
On 21/09/2020 11:48, le wang via lldb-dev wrote:
> Hello,everyone:
> I've got a problem, when debu
Hello everyone,
A little less than a week after rc3, the llvmorg-11.0.0-rc4 tag was
just created.
Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc4
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc4
Pre-built binaries will be added as they
https://bugs.llvm.org/show_bug.cgi?id=47648
Bug ID: 47648
Summary: Lack of persistent history
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority:
https://bugs.llvm.org/show_bug.cgi?id=47647
Jonas Devlieghere changed:
What|Removed |Added
Assignee|lldb-dev@lists.llvm.org |jdevliegh...@apple.com
--
You are
https://bugs.llvm.org/show_bug.cgi?id=47647
Bug ID: 47647
Summary: Use fzf (fuzzy finder) for search backward through
history
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
On 9/24/20 9:14 PM, Greg Clayton wrote:
This must be a valgrind issue, there would be major problems if the OS isn't able to lock
mutex objects correctly ("mutex is locked simultaneously by two threads"). It
is getting confused by a recursive mutex? LLDB uses recursive mutexes.W
LLDB's
Hi Paul,
I took it rather as a set of suggested topics depending on who is
interested rather than a proposed agenda.
-eric
On Wed, Sep 23, 2020 at 7:20 AM Robinson, Paul
wrote:
> Hi Eric & Orlando,
>
>
>
> It’s great to see interest in a lot of different aspects of debug info. At
> the same
... if instruction.GetAddress() == pc:
... print(instruction)
... break
...
a.out[0x10f34]: movl -0xc(%rbp), %eax
>>> print(i)
8
Now you can backup as many instructions as you want and not fear that you will
end up in the middle of an x86 instruction.
Greg
> O
This must be a valgrind issue, there would be major problems if the OS isn't
able to lock mutex objects correctly ("mutex is locked simultaneously by two
threads"). It is getting confused by a recursive mutex? LLDB uses recursive
mutexes.
> On Sep 24, 2020, at 1:55 AM, Dmitry Ant
I have a very simple lldb script:
thread select 1
disassemble --start-address $pc-24 --end-address $pc+24
When I run lldb with -o "process launch -s" and -s "dis.lldb", I get odd output
- the disassembly from "thread select 1" and from the disassemble command run
together.
This is what I see
wish to focus on the
most.
thanks for sorting this out Orlando, looking forward to it.
Tom W
On Thu, 24 Sep 2020 at 09:00, Cazalet-Hyams, Orlando via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Forwarding to lldb-dev now that I’ve signed up.
>
>
>
> *From:* llvm-dev *On
Does anyone has an explanation of this weird run of 'valgrind --tool=drd':
==2715== drd, a thread error detector
==2715== Copyright (C) 2006-2017, and GNU GPL'd, by Bart Van Assche.
==2715== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==2715== Command:
Forwarding to lldb-dev now that I’ve signed up.
From: llvm-dev On Behalf Of Cazalet-Hyams,
Orlando via llvm-dev
Sent: 24 September 2020 08:54
To: Robinson, Paul ; Eric Christopher
; LLDB Dev ;
'llvm-...@lists.llvm.org'
Subject: Re: [llvm-dev] Optimised-code debugging experience Round Table
On 22 Sep 2020, at 17:12, Hans Wennborg via Release-testers
wrote:
>
> After some delay, the llvmorg-11.0.0-rc3 tag was just created.
This rc3, like rc2, I could finally build and test without adding any
patches! :)
Main results on amd64-freebsd11:
Unsupported: 5122 (rc2: 5121)
On Tue, 2020-09-22 at 17:12 +0200, Hans Wennborg via Release-testers
wrote:
> Hello everyone,
>
> After some delay, the llvmorg-11.0.0-rc3 tag was just created.
>
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc3
> and
>
Hi Eric & Orlando,
It’s great to see interest in a lot of different aspects of debug info. At the
same time, I’m concerned about a risk to making the topic so broad that we
don’t have time to get through all the things people want to get through. I’m
thinking there’s a different way to slice
+LLDB Dev
I'll sign up. :)
My particular interests are:
- Og (and O1 as Og)
- Correctness testing tools
Past that the rest of your list seems quite specific, but the overall "line
tables" and "variable locations" are important.
Relatedly we have a number of DWARF committee members in llvm
Hello everyone,
After some delay, the llvmorg-11.0.0-rc3 tag was just created.
Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc3
and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc3
Pre-built binaries will be added as they become ready.
Please
her via lldb-dev wrote:
> >Hi Walter,
> >
> >I've only done a brief scan of the document but, in general, I'm favorable
> >of the goals, aim, and approach. Something I think would be good would be
> >to compare/contrast against rr as an "exploring alternative
anks so much for starting this and looking forward to the work and
> collaboration.
>
> -eric
>
> On Thu, Sep 17, 2020 at 8:28 PM Walter via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all,
>>
>>
>>
>> Here I propose, along with Greg Clayton,
Hello,everyone:
I've got a problem, when debugging my process with lldb tool on linux
OS(CentOS7).While I use lldb command to set breakpoints, and launch my
process, my process will execute a binary code which contains debug
information, but when my process launched, all breakpoints can not be
On 2020-09-18, Eric Christopher via lldb-dev wrote:
Hi Walter,
I've only done a brief scan of the document but, in general, I'm favorable
of the goals, aim, and approach. Something I think would be good would be
to compare/contrast against rr as an "exploring alternatives&quo
Hi Walter & Greg,
Thanks for sharing this RFC, and for your work in this area.
> On Sep 17, 2020, at 5:28 PM, Walter via lldb-dev
> wrote:
>
> Hi all,
>
> Here I propose, along with Greg Clayton, Processor Trace support for LLDB.
> I’m attaching a link to t
Hi Hans,
Here are the PowerPC release notes for 11.0.0:
Optimization:
- Improved Loop Unroll-and-Jam legality checks, allowing it to handle
more than two level loop nests
- Improved Loop Unroll to be able to unroll more loops
- Implemented an option to allow loop fusion
https://bugs.llvm.org/show_bug.cgi?id=47528
Bug ID: 47528
Summary: LLDB isn't checking signatures when loading modules
from a minidump
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
https://bugs.llvm.org/show_bug.cgi?id=47524
Bug ID: 47524
Summary: Calling functions with a null
pointer-to-typedef-of-anonymous-struct argument fail
Product: lldb
Version: 11.0
Hardware: PC
OS: Linux
https://bugs.llvm.org/show_bug.cgi?id=47522
Bug ID: 47522
Summary: Assertion `isHandleInSync() && "invalid iterator
access!"' failed
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Hello everyone,
As those following along have noticed, the release is late.
There are currently six blocking bugs at
https://bugs.llvm.org/show_bug.cgi?id=46725
I'm trying to nudge those along as best as I can, but any help would
be very welcome.
Once those issues are resolved, the plan is to
I've figured out some of the *what* but I still don't understand the *why*.
I checked the Windows registry, and found some remnants referencing Python
3.6. I doubt that's related, but I obliterated them anyway.
I scrutinized the very noisy output of Cmake and discovered two things:
1. Cmake
After rebasing, my local LLDB builds have again broken because it goes
looking for the wrong Python DLL. I'm searching through git logs, but I'm
not seeing a related change.
Does anyone know what causes CMake to get confused about which Python
versions are installed?
LINK : fatal error LNK1104:
These are the ones I found so far:
* [libmicrohttpd](https://www.gnu.org/software/libmicrohttpd/) is used by
elfutils' debuginfod, but it's LGPL licensed.
* [libcURL](https://curl.haxx.se/libcurl/) would be an option for the
client, but we'd need a different library for the server.
*
On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> There are several options, I've looked at couple of them and the one I
> like the most so far is https://github.com/yhirose/cpp-httplib for a few
> reasons:
>
> * It's MIT licensed.
> * It supports Linux,
On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek wrote:
> There are several options, I've looked at couple of them and the one I
> like the most so far is https://github.com/yhirose/cpp-httplib for a few
> reasons:
>
> * It's MIT licensed.
>
I hesitate to get into it on the list, not-a-lawyer, etc.
+LLDB Dev as well for visibility. +Pavel Labath
since he and I have talked about such things.
On Mon, Aug 31, 2020 at 7:26 PM David Blaikie wrote:
> [+debug info folks, just as FYI - since the immediate question's more
> about 3rd party library deps than the nuances of DWARF, etc]
>
> I'd
On Thu, 2020-08-20 at 22:34 +0200, Hans Wennborg via Release-testers
wrote:
> Hello everyone,
>
> The llvmorg-11.0.0-rc2 tag was just created.
>
> Source code and docs are available at
> https://prereleases.llvm.org/11.0.0/#rc2 and
>
On 20 Aug 2020, at 22:34, Hans Wennborg via Release-testers
wrote:
>
> The llvmorg-11.0.0-rc2 tag was just created.
This rc2, I could finally build and test without adding any patches! :)
Main results on amd64-freebsd11:
Unsupported: 5121 (rc1: 5121)
Passed : 69739
Hello everyone,
With the release drawing near, it would be great to get the release
notes into better shape.
You can see the notes from rc2 online here:
https://prereleases.llvm.org/11.0.0/#rc2
The release notes are typically the first thing people look at after
the release, so it's a great
https://bugs.llvm.org/show_bug.cgi?id=47284
Hans Wennborg changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Uploaded Ubuntu 16 and SLES12 binaries:
$ cat clang+llvm-11.0.0-rc2-x86_64-linux-gnu-ubuntu-16.04.tar.xz.sha256
clang+llvm-11.0.0-rc2-x86_64-linux-sles12.4.tar.xz.sha256
051d288dfc6ef9ff8e37d97b722695390427c617d3b538a93f2d0d413fb6f54a
clang+llvm-11.0.0-rc2-x86_64-linux-gnu-ubuntu-16.04.tar.xz
https://bugs.llvm.org/show_bug.cgi?id=47284
Bug ID: 47284
Summary: [lldb] Merge 1ce07cd614be into 11.0
Product: lldb
Version: 11.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Hello everyone,
The llvmorg-11.0.0-rc2 tag was just created.
Source code and docs are available at
https://prereleases.llvm.org/11.0.0/#rc2 and
https://github.com/llvm/llvm-project/releases/tag/llvmorg-11.0.0-rc2
Pre-built binaries will be added as they become ready.
Please file bug reports
ady uses this in some way? (presumably just for Apple
platforms?)
> I am working on a kernel patch which will make this information available via
> siginfo, and once the tag becomes available from the kernel you shouldn't
> need to decode the instruction.
Great! I'll keep an eye on it.
https://bugs.llvm.org/show_bug.cgi?id=45112
Raphael Isemann changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hi,
I finished testing llvm-11.0.0-rc1 on Power PC 64bit Little Endian for
- Ubuntu 18.04
- Red Hat 7.4
I have uploaded the binaries from IBM. The sha1 files are attached.
PR46995 opened for the bug found. Other than that I saw errors as reported
by others for matrix-types-spec.cpp (no matching
On Mon, Aug 10, 2020 at 3:41 AM David Spickett via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi all,
>
> What follows is my proposal for supporting AArch64's memory tagging
> extension in LLDB. I think the link in the first paragraph is a good
> introduction if you haven
implementation from my side will be
>> an overlap with what you guys have done already. There can also be design
>> conflicts and I would really appreciate it if we can come on some common
>> ground regarding upstreaming of Apple's downstream pointer authentication
>> patche
nwinder support.
>
> Thanks!
>
> On Tue, 11 Aug 2020 at 04:13, Jason Molenda via lldb-dev
> wrote:
> Hi David, thanks for the great writeup. I hadn't been following the gdb MTE
> support.
>
> This all looks reasonable to me. A few quick thoughts --
>
> T
authentication patches. We may collaborate and upstream unwinder support.
Thanks!
On Tue, 11 Aug 2020 at 04:13, Jason Molenda via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi David, thanks for the great writeup. I hadn't been following the gdb
> MTE support.
>
> This all look
On 04/08/2020 02:37, Jonas Devlieghere via lldb-dev wrote:
> Hi Nathan,
>
> Thanks for bringing this up. I've been expecting this question for a
> while now.
>
> Python 2 is end-of-life and we should move to Python 3. I'm pretty sure
> nobody here disagrees with that. Unf
https://bugs.llvm.org/show_bug.cgi?id=47100
Jonas Devlieghere changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.llvm.org/show_bug.cgi?id=47101
Jonas Devlieghere changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
701 - 800 of 7531 matches
Mail list logo
