Certainly a bug. This bit:
if (inlined_die)
{
Block &function_block = sc.function->GetBlock (true);
sc.block = function_block.FindBlockByID (inlined_die.GetID());
if (sc.block == NULL)
sc.block = function_block.FindBlockByID
(inlined_die.GetOffset());
if (sc.block == NULL || sc.block->GetStartAddress (addr) == false)
addr.Clear();
}
from SymbolFileDwarf::ResolveFunction is most likely responsible. I don't
remember offhand how the blocks deal with the fact that this one die actually
represents multiple blocks, but it's going to be something related to that.
If you want to have a look, that would be great, otherwise file a bug and we
can take a look when we get some free time.
Jim
> On Sep 4, 2015, at 12:05 PM, Keno Fischer via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> I'm trying to set a breakpoint (using `b jl_apply`) on a function (jl_apply)
> that is inlined in a number of places. This generally works fine, but I have
> noticed that in certain cases LLDB fails to set a breakpoint even though when
> I step through manually, it does know which function the code belongs to.
> Investigating further, I have found that the difference comes from whether
> the inlined subroutine is described via DW_AT_low_pc or via DW_AT_ranges, so
> e.g.
>
> 0x0000f6c8: DW_TAG_inlined_subroutine [42] *
> DW_AT_abstract_origin [DW_FORM_ref4] (cu +
> 0x22e7 => {0x0000d394} "jl_apply")
> DW_AT_low_pc [DW_FORM_addr]
> (0x000000000000f768)
> DW_AT_high_pc [DW_FORM_addr]
> (0x000000000000f776)
> DW_AT_call_file [DW_FORM_data1]
> ("/Users/kfischer/Projects/julia-testpatch/src/gf.c")
> DW_AT_call_line [DW_FORM_data1] (34)
>
> will get a breakpoint while
>
> 0x0000f6ee: DW_TAG_inlined_subroutine [53] *
> DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x22e7
> => {0x0000d394} "jl_apply")
> DW_AT_ranges [DW_FORM_data4] (0x0000b790
> [0x000000000000f785 - 0x000000000000f788)
> [0x000000000000f79c - 0x000000000000f7b8))
> DW_AT_call_file [DW_FORM_data1]
> ("/Users/kfischer/Projects/julia-testpatch/src/gf.c")
> DW_AT_call_line [DW_FORM_data2] (1668)
>
> will not. Is this the intended behavior or a bug? If it's a bug, any ideas
> where to look to try to fix it?
>
> Thanks,
> Keno
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
