Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

Hi Tamas, Thanks for highlighting this - it shows that at least we should have a description of what it means for a bug to be assigned to someone. Your interpretation of a bug being “locked” doesn’t sound unreasonable to me without any other description being available. For the clang static an

Re: [lldb-dev] [cfe-dev] [RFC] LLVM bug lifecycle BoF - triaging

On 6 Oct 2018, at 23:50, Alex Rønne Petersen mailto:a...@alexrp.com>> wrote: Hello, I am not a frequent poster on the LLVM mailing lists, but I happened to notice this thread and thought I'd weigh in. Over 2 years ago, I reported this bug: https://bugs.llvm.org/show_bug.cgi?id=29102 We had

[lldb-dev] DW_OP_deref handling

Hi Greg, I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref. I wasn’t able to craft an easy C++ testcase, so I’ll start from my motivating (swift) example. Given the following code: func use(_ t : T) {} func single(_ t : T) { let x = t use(x) } let s = "hello" single(

Re: [lldb-dev] DW_OP_deref handling

The issue is DW_OP_deref dereferences a pointer and pushes it onto the stack. The code currently, for a load address that is on top of the stack does: Value::ValueType value_type = stack.back().GetValueType(); switch (value_type) { case Value::eValueTypeLoadAddress: if (exe_ctx) { if (proce

Re: [lldb-dev] DW_OP_deref handling

On Thu, Oct 11, 2018 at 11:16 AM Greg Clayton wrote: > > The issue is DW_OP_deref dereferences a pointer and pushes it onto the stack. > The code currently, for a load address that is on top of the stack does: > > Value::ValueType value_type = stack.back().GetValueType(); > switch (value_type) {

Re: [lldb-dev] DW_OP_deref handling

I am happy to look at any DWARF expressions you have and help figure out where the change needs to go or how the expression need to be fixed. Greg > On Oct 11, 2018, at 12:32 PM, Davide Italiano wrote: > > On Thu, Oct 11, 2018 at 11:16 AM Greg Clayton > wrote: >>

Re: [lldb-dev] DW_OP_deref handling

On Thu, Oct 11, 2018 at 1:38 PM Greg Clayton wrote: > > I am happy to look at any DWARF expressions you have and help figure out > where the change needs to go or how the expression need to be fixed. > Thank you for your help, it's greatly appreciated. hopefully we'll have a more precise debugge

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

I reverted things in r344318 now. > On Oct 10, 2018, at 5:02 PM, Jim Ingham wrote: > > Thanks for looking into this! > > When I was first working on inlined stepping, I found a bunch of cases where > the line table info and the ranges for the inlined subroutines disagreed. I > remember see

Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

> On Oct 11, 2018, at 4:42 PM, Matthias Braun wrote: > > I reverted things in r344318 now. > >> On Oct 10, 2018, at 5:02 PM, Jim Ingham wrote: >> >> Thanks for looking into this! >> >> When I was first working on inlined stepping, I found a bunch of cases where >> the line table info and