If llvm-dsymutil is dropping the name, then send me your example and I will
file a bug on them to get this fixed.
Greg Clayton
> On Sep 8, 2015, at 10:06 AM, Jim Ingham via lldb-dev
> wrote:
>
> Ah, okay. For a while the llvm-dsymutil folks were trying to make the output
> of dsymutil & llv
Ah, okay. For a while the llvm-dsymutil folks were trying to make the output
of dsymutil & llvm-dsymutil identical so that they could be sure llvm-dsymutil
was doing the right thing, so I'm a little surprised the two differ in this
regard. But if it works with .o files & llvm-dsymutil I think
Actually, it's not a clang bug either. The info is there in the .o file.
This only happens if lldb is looking in the .dSYM. If I delete that and let
lldb look in the .o files, it sets the breakpoint just fine, so I'll chalk
this up as a dsymutil bug. llvm-dsymutil works fine.
On Fri, Sep 4, 2015 a
Hi Jim,
I tried to work on this, but everything there actually seemed correct. It
now seems to me like those functions are simply missing from .apple_names
(compiled with latest Clang trunk), so this might not be an LLDB bug after
all.
Keno
On Fri, Sep 4, 2015 at 3:20 PM, Jim Ingham wrote:
> C
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
(in
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 belon
