[lldb-dev] [Bug 24702] New: LLDB crashes when inferior passes bogus values over GDB JIT interface
https://llvm.org/bugs/show_bug.cgi?id=24702 Bug ID: 24702 Summary: LLDB crashes when inferior passes bogus values over GDB JIT interface Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: lab...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified If the inferior claims it has just JITted a large object, LLDB will try to allocate memory to hold it, but will crash due to a bad_alloc exception. TestJITLoaderGDB.py reproduces this situation. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] top-of-tree build failure when using configure on Linux?
Hey Sylvestre, On the Debian side, are we still counting on Makefile support for distribution building? -Todd On Thu, Sep 3, 2015 at 8:33 PM, Bruce Mitchener wrote: > There were 2 changes made this week that broke both the cmake and one that > broke the Makefile builds. I checked in fixes for the cmake build, but no > one has done similar for the Makefile build (as far as I've noticed). > (Notably, there's no Makefile support for > source/Plugins/ExpressionParser/Clang.) > > If we're going to leave that broken, maybe we could, instead, be the > pioneers in LLVM-land and remove the Makefile-based build system instead. > It doesn't seem like any of the people doing steady work on LLDB use it. > > - Bruce > > > On Fri, Sep 4, 2015 at 1:34 AM, Ted Woodward via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> We forced a clean build because it wasn’t picking up an enum change that >> affected the swig python bindings, and the objective c problem popped up. >> >> >> >> I’ve built with cmake on that machine, and it worked. I think the right >> answer is switch to cmake. >> >> >> >> -- >> >> Qualcomm Innovation Center, Inc. >> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux Foundation Collaborative Project >> >> >> >> *From:* Zachary Turner [mailto:ztur...@google.com] >> *Sent:* Thursday, September 03, 2015 12:42 PM >> *To:* Todd Fiala; Ted Woodward >> *Cc:* LLDB >> *Subject:* Re: [lldb-dev] top-of-tree build failure when using configure >> on Linux? >> >> >> >> Can you change it to CMake instead of configure? I know that's not what >> you want to hear, but the configure build is on its way out, so you're >> going to have to do this at some point anyway. >> >> >> >> On Thu, Sep 3, 2015 at 10:25 AM Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> I haven't seen that one myself. Are you still seeing it? >> >> >> >> Is it possible the buildbot's commands are possibly using older/stale >> object files? Is distcc/ccache involved? Does the build force a clean >> build? If not, does the issue go away on a clean build? Is it >> configure-based or cmake based? >> >> >> >> Just some thoughts. Good luck resolving! >> >> >> >> -Todd >> >> >> >> On Fri, Aug 28, 2015 at 10:56 AM, Ted Woodward via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> Our Ubuntu 14.10 buildbot at >> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.10 is failing, >> and I’ve been tasked to fix it because I’m the LLDB guy. >> >> >> >> It fails with things like: >> >> /var/lib/buildbot/slaves/hexagon-build-03/lldb-x86_64-ubuntu-14.10/llvm.obj/Release+Asserts/lib/libclangCodeGen.a(BackendUtil.o): >> In function `addObjCARCOptPass(llvm::PassManagerBuilder const&, >> llvm::legacy::PassManagerBase&)': >> >> BackendUtil.cpp:(.text._ZL17addObjCARCOptPassRKN4llvm18PassManagerBuilderERNS_6legacy15PassManagerBaseE+0x21): >> undefined reference to `llvm::createObjCARCOptPass()' >> >> >> >> I get the same error when I manually build using the same steps as the >> bot, but when I use cmake it works. >> >> >> >> Has anyone seen this behavior using configure? >> >> >> >> -- >> >> Qualcomm Innovation Center, Inc. >> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux Foundation Collaborative Project >> >> >> >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> >> >> >> >> -- >> >> -Todd >> >> ___ >> 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 >> >> > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges
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.
0xf6c8: DW_TAG_inlined_subroutine [42] *
DW_AT_abstract_origin [DW_FORM_ref4](cu
+ 0x22e7 => {0xd394} "jl_apply")
DW_AT_low_pc [DW_FORM_addr]
(0xf768)
DW_AT_high_pc [DW_FORM_addr]
(0xf776)
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
0xf6ee: DW_TAG_inlined_subroutine [53] *
DW_AT_abstract_origin [DW_FORM_ref4] (cu +
0x22e7 => {0xd394} "jl_apply")
DW_AT_ranges [DW_FORM_data4] (0xb790
[0xf785 - 0xf788)
[0xf79c - 0xf7b8))
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
Re: [lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges
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
> 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.
>
> 0xf6c8: DW_TAG_inlined_subroutine [42] *
> DW_AT_abstract_origin [DW_FORM_ref4](cu +
> 0x22e7 => {0xd394} "jl_apply")
> DW_AT_low_pc [DW_FORM_addr]
> (0xf768)
> DW_AT_high_pc [DW_FORM_addr]
> (0xf776)
> 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
>
> 0xf6ee: DW_TAG_inlined_subroutine [53] *
> DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x22e7
> => {0xd394} "jl_apply")
> DW_AT_ranges [DW_FORM_data4] (0xb790
> [0xf785 - 0xf788)
> [0xf79c - 0xf7b8))
> 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
[lldb-dev] [Bug 24708] New: parallel dotest.py does not work properly in parallel mode with non-argument test dirs specified on the end
https://llvm.org/bugs/show_bug.cgi?id=24708
Bug ID: 24708
Summary: parallel dotest.py does not work properly in parallel
mode with non-argument test dirs specified on the end
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
dotest.py {some args} [dir [dir [...]]
used to work fine.
dotest.py --no-multiprocess {as above}
continues to work fine.
dotest.py --test-subdir [one-dir] works fine.
But, dotest.py {some args} [dir [dir [...]]
where it now runs multiprocessing and we're using the non-option directories at
the end does not work fine. Converting to one of the --test-subdir or
--no-multiprocessing forms is a workaround.
Fix this so that we skip using the multiprocessing test runner when the unnamed
directory args are specified. (Or, make the parallel test runner use them but
not add the whole directory tree underneath them to match the correct
behavior).
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24708] parallel dotest.py does not work properly in parallel mode with non-argument test dirs specified on the end
https://llvm.org/bugs/show_bug.cgi?id=24708 Todd Fiala changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24709] New: dotest.py parallel mode does not gracefully quit with ^C
https://llvm.org/bugs/show_bug.cgi?id=24709 Bug ID: 24709 Summary: dotest.py parallel mode does not gracefully quit with ^C Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified dotest.py in parallel mode, like dosep.py before it, does not actually break out correctly when we hit ^C. Instead, the user is left with a ton of worker threads in various states that keep chugging away and a terminal that does not return. Make ^C work in parallel execution mode. KNOWN WORKAROUNDS The POSIX-y workaround for this has typically been a 'killall python' (or a slightly more sophisticated script that limits to the dotest.py python processes). Another workaround is to use --no-multiprocess if the user is doing a single test or test dir and wants to view it in realtime, as ^C is working fine in non-parallel mode. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24709] dotest.py parallel mode does not gracefully quit with ^C
https://llvm.org/bugs/show_bug.cgi?id=24709 Todd Fiala changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Note to buildbot/testbot runners
A few notes to dotest.py users: * If you want to limit a test run to a test subdirectory *tree*, you can use the new --test-subdir flag. It covers what used to be the supported unnamed argument in dosep.py. It is specified relative to the lldb/test dir. * If you want to use the unnamed arguments to specify single directory levels in which to execute tests, you'll either want to convert to using --test-subdir, or add --no-multiprocess, until I fix a bug I found just recently (and filed a bugzilla bug on it). * dosep.py's --threads used to also have a '-t' abbreviation. Since all of dosep's (3-ish) arguments moved over to dotest.py and now live in dotest.py's argument namespace, I had to avoid collisions with existing dotest.py single-letter argument abbreviations. '-t' already belonged to "Turn on tracing of lldb command and other detailed test executions", so -t no longer specifies thread count. Use the longer --threads or the environment variable for it. * dosep.py's --output-on-success had a '-s' abbreviation. This collides with dotest.py's already-existing session-dir-setting command. So, you must now specify the --output-on-success long form of the argument if you want the parallel test runner to do that. * The supported nameless arg in dosep.py has been moved to the dotest.py --test-subdir arg. Other than that, I expect none of the behavior to differ aside from the bug I just filed on dosep.py's inconvenient failure to handle ^C correctly. (This existed forever in dosep.py but it is more annoying for it to be broken for the default usage of dotest.py, so I'll use this opportunity to fix it). Thanks! -Todd On Thu, Sep 3, 2015 at 12:12 PM, Todd Fiala wrote: > Hi all, > > TL;DR: if you call dosep.py directly, you'll need to modify your flow to > call dotest.py. > > *Details:* > > *dotest.py now runs in parallel test runner mode by default* > > Starting with lldb svn revision 246794, if you run buildbots or testbots > and you directly called dosep.py as a build step, you'll need to replace > that with dotest.py. You will continue to get the parallel test execution > speed improvements. You no longer need to wrap dotest.py parameters in a > -o options block. > > *dotest.py now takes an optional --no-multiprocess argument* > > If you really want to run exactly like the old dotest runner, you can > still get that behavior by specifying --no-multiprocess on the dotest.py > command line. > > *dosep.py's unnamed argument (test-subdir) has moved to --test-subdir* > > dosep.py's arguments have moved into dotest.py under the Parallel test > execution argument group. The only difference is that the unnamed final > argument available in dosep.py was moved to a named argument in dotest.py > as dotest.py already used unnamed arguments for something and the collision > needed to be resolved. The new argument that dotest.py takes, and is only > used when the test is running in parallel execution mode, is the > --test-subdir argument, handled the same way dosep.py's unnamed argument > used to work. (test subdirectory relative to the lldb/test root, that > limits all parallel test running to the specified subdirectory tree). > > While dosep.py is still around as an implementation detail, calling it > directly will now result in a stderr message and will return with a > non-zero exit code. This is for two reasons: (1) we are no longer > supporting dosep.py as a callable test driver, and (2) the methods for > calling it have changed to support dotest.py's implementation of running > the parallel test runner and having args parsed already and passed to it. > Thus, any buildbot/testbot that directly called dosep.py is going to need > to change to call over to dotest.py. > > Thanks, all! > > -Todd > -- > -Todd > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24717] New: MiBreakTestCase.test_lldbmi_break_insert_function_pending is marked expectedFlakeyLinux, but still fails
https://llvm.org/bugs/show_bug.cgi?id=24717
Bug ID: 24717
Summary: MiBreakTestCase.test_lldbmi_break_insert_function_pend
ing is marked expectedFlakeyLinux, but still fails
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: sivachan...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
It fails on the bot while marked expectedFlakeyLinux means it is failing twice
in a row sometimes. It fails with this:
ERROR: test_lldbmi_break_insert_function_pending (TestMiBreak.MiBreakTestCase)
Test that 'lldb-mi --interpreter' works for pending function breakpoints.
--
Traceback (most recent call last):
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/lldbtest.py",
line 500, in wrapper
return func(self, *args, **kwargs)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/lldbtest.py",
line 745, in wrapper
func(*args, **kwargs)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/tools/lldb-mi/breakpoint/TestMiBreak.py",
line 35, in test_lldbmi_break_insert_function_pending
self.expect("=breakpoint-modified,bkpt={number=\"1\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\",addr=\"(?!0x)0x[0-9a-f]+\",func=\".+?\",file=\".+?\",fullname=\".+?\",line=\"(-1|\d+)\",pending=\[\"printf\"\],times=\"0\",original-location=\"printf\"}")
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/tools/lldb-mi/lldbmi_testcase.py",
line 48, in expect
return self.child.expect(pattern, *args, **kwargs)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/pexpect-2.4/pexpect.py",
line 1316, in expect
return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/pexpect-2.4/pexpect.py",
line 1330, in expect_list
return self.expect_loop(searcher_re(pattern_list), timeout,
searchwindowsize)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/test/pexpect-2.4/pexpect.py",
line 1414, in expect_loop
raise TIMEOUT (str(e) + '\n' + str(self))
TIMEOUT: Timeout exceeded in read_nonblocking().
version: 2.4 ($Revision: 516 $)
command: /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb-mi
args: ['/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb-mi',
'--interpreter']
searcher: searcher_re:
0:
re.compile("=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="(?!0x)0x[0-9a-f]+",func=".+?",file=".+?",fullname=".+?",line="(-1|\d+)",pending=\["printf"\],times="0",original-location="printf"}")
buffer (last 100 chars):
"_IO_printf",args=[],file="??",fullname="??",line="-1"},thread-id="1",stopped-threads="all"
(gdb)
before (last 100 chars):
"_IO_printf",args=[],file="??",fullname="??",line="-1"},thread-id="1",stopped-threads="all"
(gdb)
after:
match: None
match_index: None
exitstatus: None
flag_eof: False
pid: 14864
child_fd: 3
closed: False
timeout: 30
delimiter:
logfile: None
logfile_read:
logfile_send: None
maxread: 2000
ignorecase: False
searchwindowsize: None
delaybeforesend: 0.05
delayafterclose: 0.1
delayafterterminate: 0.1
Config=i386-clang
--
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges
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:
> 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.
> >
> > 0xf6c8: DW_TAG_inlined_subroutine [42] *
> > DW_AT_abstract_origin [DW_FORM_ref4]
> (cu + 0x22e7 => {0xd394} "jl_apply")
> > DW_AT_low_pc [DW_FORM_addr]
> (0xf768)
> > DW_AT_high_pc [DW_FORM_addr]
> (0xf776)
> > 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
> >
> > 0xf6ee: DW_TAG_inlined_subroutine [53] *
> > DW_AT_abstract_origin [DW_FORM_ref4] (cu +
> 0x22e7 => {0xd394} "jl_apply")
> > DW_AT_ranges [DW_FORM_data4] (0xb790
> > [0xf785 - 0xf788)
> > [0xf79c - 0xf7b8))
> > 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
Re: [lldb-dev] Breakpoints on inlined functions described by DW_AT_ranges
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 at 9:41 PM, Keno Fischer
wrote:
> 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:
>
>> 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.
>> >
>> > 0xf6c8: DW_TAG_inlined_subroutine [42] *
>> > DW_AT_abstract_origin [DW_FORM_ref4]
>> (cu + 0x22e7 => {0xd394} "jl_apply")
>> > DW_AT_low_pc [DW_FORM_addr]
>> (0xf768)
>> > DW_AT_high_pc [DW_FORM_addr]
>> (0xf776)
>> > 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
>> >
>> > 0xf6ee: DW_TAG_inlined_subroutine [53] *
>> > DW_AT_abstract_origin [DW_FORM_ref4] (cu +
>> 0x22e7 => {0xd394} "jl_apply")
>> > DW_AT_ranges [DW_FORM_data4] (0xb790
>> > [0xf785 - 0xf788)
>> > [0xf79c - 0xf7b8))
>> > 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
