https://bugs.llvm.org/show_bug.cgi?id=32300
Bug ID: 32300
Summary: Wrong resolving boost::variant template arguments by
formatters API
Product: lldb
Version: 3.9
Hardware: Macintosh
OS: MacOS X
S
Hi,
I have no answer received yet to this question.
Maybe this list / forum is not the appropriate place for this kind of question.
If this is the case please advise me to whom I should address myself.
…or is it just a wast of time to try to improve displaying Pascal variable
names (not case-se
https://bugs.llvm.org/show_bug.cgi?id=32301
Bug ID: 32301
Summary: LLDB fails to build: readline.cpp:9:31: fatal error:
editline/readline.h: No such file or directory
Product: lldb
Version: 4.0
Hardware: PC
On 16 March 2017 at 00:43, Kamil Rytarowski wrote:
> On 01.03.2017 10:13, Kamil Rytarowski wrote:
>> Hello,
>>
>> The contract for the LLDB port on NetBSD has been prolonged by The
>> NetBSD Foundation. The additional time will cover the features that were
>> delayed in order to address blockers t
A random idea: Instead of parsing demangled C++ method names what people
think about writing or reusing a demangler what can gave back both the
demangled name and the parsed name in some form?
My guess is that it would be both more efficient (we already have most of
information during demangling)
I think clang-format's parser would be a better candidate for code
reuse, but even that might be too much, as we don't need that level of
detail (basically we just need to split the name into function name,
return type and argument list), and we can make a lot of simplifying
assumptions here (e.g.
I am not an LLDB developer, but based on the symptom you reported,
there are a couple of different possibilities for why it occurs.
One possibility is that FPC up-shifts all the names in the debug info,
but does not add the "case-insensitive" indication. This would be a
bug in the compiler.
Anothe
On 16.03.2017 11:55, Pavel Labath wrote:
> On 16 March 2017 at 00:43, Kamil Rytarowski wrote:
>>
>> TODO:
>> - Fixing software breakpoints support,
Fixed!
267->596 of succeeded tests out of 1200+ - please scroll for details.
>> - Special Registers (Floating Point..) reading/writing,
>> - Unl
> On Mar 16, 2017, at 2:43 PM, Kamil Rytarowski via lldb-dev
> wrote:
>
> On 16.03.2017 11:55, Pavel Labath wrote:
>> On 16 March 2017 at 00:43, Kamil Rytarowski wrote:
>>>
>>> TODO:
>>> - Fixing software breakpoints support,
>
> Fixed!
>
> 267->596 of succeeded tests out of 1200+ - please
On 16.03.2017 22:59, Jim Ingham wrote:
> But it looks like all the "whole process" events you are talking about are
> not stop reasons but more start actions. That makes sense, but what whole
> process stop events do you mean?
A process can be stopped with a signal. A signal can be emitted to:
The main consumer of thread stop reasons is the execution control (ThreadPlans
- which handle stepping & function calling - and StopInfo::PerformAction which
handles breakpoint/watchpoint hits). The only bad effect of populating all the
threads with the whole process signals is if any of the pl
11 matches
Mail list logo
