I agree.
I plan to remove the two backends (well, at least submit requests for)
in 3 weeks from today.
There are a lot of moving pieces right now and I'd really love for
things to stabilize but also give people an opportunity to speak up,
if they want to.
--
Davide
On Tue, Jan 30, 2018 at 5:30 AM
https://bugs.llvm.org/show_bug.cgi?id=36156
Bug ID: 36156
Summary: lldb-mi does not report watchpoint stops
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
https://bugs.llvm.org/show_bug.cgi?id=36155
Bug ID: 36155
Summary: FastDemangle performance problem
Product: lldb
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote:
> so I'm writing this email to see if there's anyone
> else interested in this topic, and to try to synchronize our efforts.
I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer
for GDB (but not producing/
> On Jan 30, 2018, at 7:49 AM, Pavel Labath wrote:
>
> On 30 January 2018 at 15:41, Adrian Prantl wrote:
>>
>>
>>> On Jan 30, 2018, at 7:35 AM, Pavel Labath wrote:
>>>
>>> Hello all,
>>>
>>> I am looking for feedback regarding implementation of the case folding
>>> algorithm for .debug_na
> On Jan 30, 2018, at 3:35 PM, Pavel Labath wrote:
>
> Hello all,
>
> I am looking for feedback regarding implementation of the case folding
> algorithm for .debug_names hashes.
>
> Unlike the apple tables, the .debug_names hashes are computed from
> case-folded names (to enable case-insensit
On 30 January 2018 at 15:41, Adrian Prantl wrote:
>
>
>> On Jan 30, 2018, at 7:35 AM, Pavel Labath wrote:
>>
>> Hello all,
>>
>> I am looking for feedback regarding implementation of the case folding
>> algorithm for .debug_names hashes.
>>
>> Unlike the apple tables, the .debug_names hashes are
> On Jan 30, 2018, at 7:35 AM, Pavel Labath wrote:
>
> Hello all,
>
> I am looking for feedback regarding implementation of the case folding
> algorithm for .debug_names hashes.
>
> Unlike the apple tables, the .debug_names hashes are computed from
> case-folded names (to enable case-insensit
> "Pavel" == Pavel Labath writes:
Pavel> Yes, but it still adds another manual step to the setup process, which
Pavel> means most developers will not do it. It also exposes us to a
Pavel> non-determinism coming from different versions of the rust compiler
Pavel> people will have.
I see what
Hello all,
I am looking for feedback regarding implementation of the case folding
algorithm for .debug_names hashes.
Unlike the apple tables, the .debug_names hashes are computed from
case-folded names (to enable case-insensitive lookups for languages
where that makes sense). The dwarf5 document
Originally I added the Java support to work with the Android ART runtime
and it has some pretty hard beaked in dependencies on the debug info ART
generates and on the version of ART available at that time (Android N) even
though I don't think this limitation is communicated clearly in source code
o
Right, so, independently of this thread here, we've had an internal
discussion about reviving java support. However, it is still very
uncertain that this will actually happen , so I'm not opposed to
removing it as we can always add it back later (with better testing,
hopefully).
Regardless of what
On 29 January 2018 at 18:39, Tom Tromey wrote:
>> "Pavel" == Pavel Labath writes:
>
> Pavel> To these very insightful emails from Greg and Jim, I'd just like to
> Pavel> add one request. Please consider the testing strategy of the code you
> Pavel> write early on. One of the problems that we
https://bugs.llvm.org/show_bug.cgi?id=36146
Bug ID: 36146
Summary: TestWithGmodulesDebugInfo.test_specialized_typedef_fro
m_pch_gmodules fails on i386 linux
Product: lldb
Version: unspecified
Hardware: PC
OS
14 matches
Mail list logo
