Hi,
I've just tagged 7.0.1-rc3. This will hopefully be the last release candidate.
Please test and report results.
Thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
The ObjectFileBreakpad change (r348592) first got tested on the bot for:
http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/13712/
and immediately TestFunctionStarts started failing.
You probably didn't get a mail because the previous test run failed with one of
these "concurrent signal"
> On Dec 7, 2018, at 4:37 AM, Bruce Mitchener via lldb-dev
> wrote:
>
>> On Fri, Dec 7, 2018 at 6:11 PM Raphael Isemann via lldb-dev
>> wrote:
>> I think if we want to actually lower the entry barrier for
>> contributing/fixing things on the website, then the server should do
>> this. From
On Mon, Dec 3, 2018 at 2:04 PM Hans Wennborg wrote:
> I know 7.0.1 isn't out the door yet, and 8.0.0 isn't due for a while,
> so relax :-) But I would like to get the schedule decided before folks
> disappear over the holidays.
>
> According to the usual schedule, the branch would be created two
“Unknown” is a perfectly fine value for the os though, and I’m not
suggesting to change that.
My point is simply that Jason’s situation (baremetal) is one that is not
even expressible by the Triple syntax. As long as there’s some enum value
that describes the situation (of which unknown is a
We use 2 triples for Hexagon:
hexagon-unknown-elf (which becomes hexagon-unknown-unknown-elf internally), and
hexagon-unknown-linux.
We follow the Linux standard and add in magic to the elf to identify it as a
Linux binary. But in the hexagon-unknown-elf case we have no way to distinguish
> Thanks for reporting this problem. I cc:ed Mike, as he owns the bots,
and he should be able to help us with this.
> (I do have access to the Jenkins configuration but I don't feel
confident enough to make the change myself).
Hi Davide and Mike,
I have received an email from
Sure, I have created the reports:
https://bugs.llvm.org/show_bug.cgi?id=39909
https://bugs.llvm.org/show_bug.cgi?id=39910
And there was one already which I extended:
https://bugs.llvm.org/show_bug.cgi?id=22988
Gabor
On Thu, Dec 6, 2018 at 6:39 PM Davide Italiano
wrote:
> On Thu, Dec 6, 2018
https://bugs.llvm.org/show_bug.cgi?id=39910
Bug ID: 39910
Summary: Libcxx should be a dependency of check-lldb target
Product: lldb
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Severity:
https://bugs.llvm.org/show_bug.cgi?id=39909
Bug ID: 39909
Summary: Build docs for macOS should mention DevToolsSecurity
Product: lldb
Version: unspecified
Hardware: All
OS: MacOS X
Status: NEW
Severity:
I think if we want to actually lower the entry barrier for
contributing/fixing things on the website, then the server should do
this. From what I know the other LLVM projects also generate the HTML
on the server (at least I've never seen anyone commit generated HTML
files), so this hopefully
We can already say that with OSType::Unknown. That’s different than “i know
that no OS exists”
On Fri, Dec 7, 2018 at 12:00 AM Pavel Labath wrote:
> On 07/12/2018 01:22, Jason Molenda via lldb-dev wrote:
> > Oh sorry I missed that. Yes, I think a value added to the OSType for
> NoOS or
On 06/12/2018 18:02, Jonas Devlieghere via lldb-dev wrote:
Hi everyone,
The current LLDB website is written in HTML which is hard to maintain.
We have quite a bit of HTML code checked in which can make it hard to
differentiate between documentation written by us and documentation
generated
On 07/12/2018 01:22, Jason Molenda via lldb-dev wrote:
Oh sorry I missed that. Yes, I think a value added to the OSType for NoOS or something
would work. We need to standardize on a textual representation for this in a triple
string as well, like 'none'. Then with arm64-- and arm64-*-* as
14 matches
Mail list logo
