https://llvm.org/bugs/show_bug.cgi?id=26230
Bug ID: 26230
Summary: LLDB generates superfluous "running" public events
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
I still haven't built rc1 yet but I've found the cause of most (if not all) of
the libc++ failures. This system does not have the en_US.UTF-8 locale.
I'm currently putting a patch together to add appropriate REQUIRES lines to
tests that require en_US.UTF-8. Once I've done that and committed it,
https://llvm.org/bugs/show_bug.cgi?id=24953
lab...@google.com changed:
What|Removed |Added
CC||lab...@google.com
Assignee|lldb-de
On 20 January 2016 at 17:49, Hans Wennborg wrote:
> Did you send this before I sent the rc1 email, or what things are you
> referring to? :-)
Damn it, my filter isn't working as well as I expected! :) Sorry about
the noise.
--renato
___
lldb-dev mailin
ARM and AArch64 seem both good. Uploaded.
On 19 January 2016 at 23:47, Hans Wennborg wrote:
> Dear testers,
>
> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> r258223. (It took a little longer than I'd planned, sorry about that.)
>
> There are still a bunch of open merge r
On 20 January 2016 at 09:31, Sylvestre Ledru wrote:
> What about creating a release management mailing list ?
> The testers are usually the same (hello folks!) :)
I second that! It'd also be much easier on mail filters... :)
--renato
___
lldb-dev maili
Hello,
Regarding the questions in this thread please find the answers ->
How are you going to present this information to the user? (I know
debugserver can report some performance data... Have you looked into
how that works? Do you plan to reuse some parts of that
infrastructure?) and How wi
Great. Actually there is a latent bug in there we hit yesterday, when
there is a platform set but it doesn't start with "remote-" (we assume the
match result has a first matched group and blow up). I'll submit a patch
that both fixes that up and strips out the darwin ones. I think the rerun
logi
Glad to see clang-format getting some improvements.
On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner wrote:
> As far as I'm aware, this is the last major incompatibility between LLDB's
> style and clang-format's feature set.
>
> I would appreciate it if more people could try it out with a few o
On Wed, Jan 20, 2016 at 5:02 PM, Ben Pope via cfe-dev
wrote:
> On Thursday, January 21, 2016 01:28 AM, Hans Wennborg via cfe-dev wrote:
>>
>> On Wed, Jan 20, 2016 at 7:54 AM, Ben Pope wrote:
>>>
>>> On Wednesday, January 20, 2016 07:47 AM, Hans Wennborg wrote:
Dear testers,
>>
On Thu, Jan 21, 2016 at 5:18 AM, Renato Golin wrote:
> On 20 January 2016 at 09:31, Sylvestre Ledru wrote:
>> What about creating a release management mailing list ?
>> The testers are usually the same (hello folks!) :)
>
> I second that! It'd also be much easier on mail filters... :)
Tanya, can
I'm not sure I agree. I don't think anything will be awkwardly formatted
with regards to the rest of the file. The biggest thing this is going to
fix are whitespace at the end of lines, line breakign conventions, and
space between function name and parentheses.
If we're not going to enforce a co
Hi,
LLDB 3.8 has much better support for core load on Linux than 3.7 - thanks a
lot! But there are still two problems.
1. The thread ID are lost and there is FIXME in the code2. If core dump is
obtained from live process (i.e. gdb attach, gcore, detach) then there is no
thread that has any reaso
On 20 Jan 2016, at 22:26, Hans Wennborg wrote:
>
> On Wed, Jan 20, 2016 at 12:18 PM, Dimitry Andric wrote:
...
>> The way I fixed this during the 3.7 test phase, is by changing
>> test-release.sh so it exports directly into these locations:
>>
>> # Exporting llvm 3.7.0-rc3 sources to llvm.src
Also this is the same standard that applies to the rest of LLVM.
clang-format your patches. Just because we haven't been consistently
following the rules until now doesn't mean we should continue to not follow
the rules going forward. This way eventually the codebase slowly converges
towards a p
On 20 Jan 2016, at 21:18, Dimitry Andric via llvm-dev
wrote:
...
>>> * Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the
>>> last version that can build without C++11 support), and it crashes with a
>>> segfault during building of CGBlocks.cpp. I'll need to find some wa
I tend to agree with Zachary on the overall principle – and I would be willing
to clang-format functions when I modify them. I’m concerned about a specific
class of functions, though. Let’s say I have a function that has had lots of
activity (I’m thinking of, for example, ParseType off in the
Jim, I think you and I have talked about this in the past. Care to comment?
On Thu, Jan 21, 2016 at 11:18 AM, Sean Callanan wrote:
> I tend to agree with Zachary on the overall principle – and I would be
> willing to clang-format functions when I modify them. I’m concerned about
> a specific c
On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan wrote:
> I tend to agree with Zachary on the overall principle – and I would be
> willing to clang-format functions when I modify them. I’m concerned about
> a specific class of functions, though. Let’s say I have a function that
> has had lots of
One thing to think about is you can actually just run an expression in the
program that is being debugged without needing to change anything in the GDB
remote server. So this can all be done via python commands and would require no
changes to anything. So you can run an expression to enable the
On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg wrote:
> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> r258223. (It took a little longer than I'd planned, sorry about that.)
>
> There are still a bunch of open merge requests and bug reports, but I
> wanted to get the tag in
SuSE Linux Enterprise Server 11SP3 x86_64
Looks like I see several failures that weren't in 3.7.1. Is there any way
to tell whether these are regressions vs new-to-3.8.0-but-failing? The
MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were
not in 3.7.1.
Fai
https://llvm.org/bugs/show_bug.cgi?id=26248
Bug ID: 26248
Summary: Disassembly incorrect for x64 RIP-relative
Product: lldb
Version: 3.4
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> SuSE Linux Enterprise Server 11SP3 x86_64
>
> Looks like I see several failures that weren't in 3.7.1. Is there any way
> to tell whether these are regressions vs new-to-3.8.0-but-failing? The
> MSan ones
On Wed, Jan 20, 2016 at 1:18 PM, Dimitry Andric via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On 20 Jan 2016, at 18:23, Hans Wennborg wrote:
> >
> > On Wed, Jan 20, 2016 at 5:25 AM, Dimitry Andric
> wrote:
> >> Unfortunately I'm having lots of trouble with rc1 at this point:
> >> * libcxxabi ca
On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier wrote:
>
> On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> SuSE Linux Enterprise Server 11SP3 x86_64
>>
>> Looks like I see several failures that weren't in 3.7.1. Is there any
>> way to tell whether t
Okay, sounds like a reasonable thing to try. We can always review it if it
causes any real issues.
On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner wrote:
>
>
> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan
> wrote:
>
>> I tend to agree with Zachary on the overall principle – and I would be
>
27 matches
Mail list logo
