Re: [lldb-dev] Where "thread until " should set breakpoints?
On Thu, Aug 2, 2018 at 3:32 AM, Jim Ingham wrote: > > > > On Jul 24, 2018, at 9:05 PM, Ramana via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > On the subject line, the ToT lldb (see code around > CommandObjectThread.cpp:1230) sets the breakpoint on the first exact > matching line of 'line-number' or the closest line number > 'line-number' > i.e. the best match. > > > > And along with that, starting from the above exact/best matching line > number index in the line table, the breakpoints are also being set on every > other line number available in the line table in the current function > scope. This latter part, I believe, is incorrect. > > Why do you think this is incorrect? > > The requirements for "thread until " are: > > a) If any code contributed by is executed before leaving the > function, stop > b) If you end up leaving the function w/o triggering (a), then stop > Understood and no concerns on this. > Correct or incorrect should be determined by how well the implementation > fits those requirements. > > There isn't currently a reliable indication from the debug information or > line tables that "line N will always be entered starting with the block at > 0x123". So you can't tell without doing control flow analysis, which if > any of the separate entries in the line table for the same line will get > hit in the course of executing the function. So the safest thing to do is > to set breakpoints on them all. >From the above, I understand that we have to do this when the debug line table has more than one entry for a particular source line. And this is what I referred to as "machine code for one single source line is scattered across" in my previous mail. Thanks for sharing why we had to do that. Besides setting a few more breakpoints - which should be pretty cheap - I > don't see much downside to the way it is currently implemented. > > Anyway, why did this bother you? > > Jim > However, I am concerned about the below 'thread until' behaviour. For the attached test case (kernels.cpp - OpenCL code), following is the debug line table generated by the compiler. File nameLine numberStarting address ./kernels.cpp:[++] kernels.cpp9 0xacc74d00 kernels.cpp 12 0xacc74d00 kernels.cpp 14 0xacc74d40 kernels.cpp 13 0xacc74dc0 kernels.cpp 14 0xacc74e00 kernels.cpp 25 0xacc74e80 kernels.cpp 25 0xacc74ec0 kernels.cpp 26 0xacc74f00 kernels.cpp 26 0xacc74f40 kernels.cpp 26 0xacc74f80 kernels.cpp 17 0xacc74fc0 kernels.cpp 18 0xacc75000 kernels.cpp 18 0xacc75040 kernels.cpp 19 0xacc75080 kernels.cpp 27 0xacc750c0 kernels.cpp 27 0xacc75140 kernels.cpp 28 0xacc75180 kernels.cpp 28 0xacc751c0 kernels.cpp 29 0xacc75200 kernels.cpp 29 0xacc75240 kernels.cpp 30 0xacc75280 With the ToT lldb, when I am at line 12 (0xacc74d00), if I say 'thread until 18', the lldb log gives me the following w.r.t breakpoints. GDBRemoteCommunicationClient::SendGDBStoppointTypePacket() add at addr = 0xacc75280 Thread::PushPlan(0x0xa48b38f0): "Stepping from address 0xacc74d00 until we reach one of: 0xacc75000 (bp: -4) 0xacc75040 (bp: -5) 0xacc75080 (bp: -6) 0xacc750c0 (bp: -7) 0xacc75140 (bp: -8) 0xacc75180 (bp: -9) 0xacc751c0 (bp: -10) 0xacc75200 (bp: -11) 0xacc75240 (bp: -12) 0xacc75280 (bp: -13) Setting two breakpoints for line number 18 i.e. at 0xacc75000 and 0xacc75040 is understandable from your above reasoning and since we are anyway setting a breakpoint at the end of the function (line 30 - 0xacc75280), is it necessary to set the breakpoints on line numbers 19, 27, 28, 29 as well i.e. at 0xacc75080 (line 19), 0xacc750c0 (line 27), 0xacc75140 (line 27), 0xacc75180 (line 28), 0xacc751c0 (line 28), 0xacc75200 (line 29), 0xacc75240 (line 29)? The latter part i.e. setting breakpoints on 19, 27, 28, 29 as well is what I think is incorrect. Am I missing something here? > > > > What, I think, should happen is we just set only one breakpoint on the > first exact/best match for the given 'line-number' and another on the > return address
Re: [lldb-dev] Where "thread until " should set breakpoints?
> On Jul 24, 2018, at 9:05 PM, Ramana via lldb-dev > wrote: > > On the subject line, the ToT lldb (see code around > CommandObjectThread.cpp:1230) sets the breakpoint on the first exact matching > line of 'line-number' or the closest line number > 'line-number' i.e. the > best match. > > And along with that, starting from the above exact/best matching line number > index in the line table, the breakpoints are also being set on every other > line number available in the line table in the current function scope. This > latter part, I believe, is incorrect. Why do you think this is incorrect? The requirements for "thread until " are: a) If any code contributed by is executed before leaving the function, stop b) If you end up leaving the function w/o triggering (a), then stop Correct or incorrect should be determined by how well the implementation fits those requirements. There isn't currently a reliable indication from the debug information or line tables that "line N will always be entered starting with the block at 0x123". So you can't tell without doing control flow analysis, which if any of the separate entries in the line table for the same line will get hit in the course of executing the function. So the safest thing to do is to set breakpoints on them all. Besides setting a few more breakpoints - which should be pretty cheap - I don't see much downside to the way it is currently implemented. Anyway, why did this bother you? Jim > > What, I think, should happen is we just set only one breakpoint on the first > exact/best match for the given 'line-number' and another on the return > address from the current frame. And this leaves us with one special case > where the machine code for one single source line is scattered across (aka > scheduled across) and I do not know what is the expected behaviour in this > case. > > If I my above understanding is correct and after discussing here on how to > handle the scattered code scenario, I will submit a patch. > > Regards, > Venkata Ramanaiah > ___ > 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] Process launch view duplication
Generally, the driver will print stop info every time a stop event is forwarded
from the private event queue to the public event queue. You can check the
output of the event log (log enable lldb event) to see if you are indeed
sending two events. If you are sending two events, you can add the -S option
to the log command to see the stack trace when the events were broadcast to the
public event queue and see if there's an obvious way to suppress one of them.
Jim
> On Jul 23, 2018, at 8:51 AM, Dávid Bolvanský via lldb-dev
> wrote:
>
> Hello,
>
> Our slightly modified LLDB based on v6.0 with custom platform and process has
> a strange problem during process launch. We see the debugger view twice.
> After stepping over, we see it correctly - just once. Does anybody know where
> the problem could be?
>
> Process, platform, thread, event logs: https://pastebin.com/3Ecns4W5
>
> (lldb) target create "/home/davidbolvansky/Plocha/file.xexe"
> Current executable set to '/home/davidbolvansky/Plocha/file.xexe'.
> (lldb) b main
> Breakpoint 1: where = file.xexe`main + 32 at bitcnt.c:76, address = 0x01ec
> (lldb) r
> info: dynamic port 45999
> info: Waiting for a client...
> Process 1 launched: '/home/davidbolvansky/Plocha/file.xexe'.
> Process 1 stopped
> * thread #1, stop reason = breakpoint 1.1
> frame #0: 0x01ec file.xexe`main(argc=1, argv=0x08c0) at
> bitcnt.c:76
>73 long i, j;
>74 unsigned long count;
>75
> -> 76 for (i = 0; i < BENCHMARK_RUNS; i++)
>77 {
>78 count = 0;
>79 for (j = 0; j < DATA_TAB_SIZE; j++)
> Process 1 stopped
> * thread #1, stop reason = breakpoint 1.1
> frame #0: 0x01ec file.xexe`main(argc=1, argv=0x08c0) at
> bitcnt.c:76
>73 long i, j;
>74 unsigned long count;
>75
> -> 76 for (i = 0; i < BENCHMARK_RUNS; i++)
>77 {
>78 count = 0;
>79 for (j = 0; j < DATA_TAB_SIZE; j++)
> ___
> 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] The mysterious case of unsupported DW_FORMs
I'm sharing some notes on a strange LLDB issue I hit locally, in case anyone else hits the same problem. The symptoms are symbols unexpectedly not working for some modules and/or warning messages complaining about "unsupported DW_FORMs", ex: *warning: (x86_64) /lib/x86_64-linux-gnu/libz.so.1.2.8 unsupported DW_FORM > values: 0x2 0x1b 0x1c 0x1d 0x1e 0x1f 0x21 0x22 0x23 0x24 0x25 0x26 0x27 > 0x28 0x29 ... lots more values ...* Tools like dwarfdump, objdump and realelf didn't raise any complains about the affected symbols so the symbols themselves seemed fine. The LLDB warning was fired during parsing the .debug_abbrev section but dumping it showed nothing out of the ordinary(*) The first hint that the problem was on the LLDB/LLVM side came from llvm-dwarfdump: .debug_info contents: > error: failed to decompress '.debug_aranges', zlib is not available > error: failed to decompress '.debug_info', zlib is not available > error: failed to decompress '.debug_abbrev', zlib is not available ... Sure enough, the sections were compressed. LLDB tried to decompress, but when failed to do so it carried on returning and alter attempting to parse the compressed bytes as is. Why weren't my local LLVM & LLDB builds able to decompress the sections? CMake! Apparently the project files didn't get correctly regenerated and my CMakeCache.txt had an unfortunate set of flags: LLVM_ENABLE_ZLIB:BOOL=ON (great!) > HAVE_LIBZ_ZLIB:INTERNAL= (empty, hmm...) It should have something like this instead: LLVM_ENABLE_ZLIB:BOOL=ON > HAVE_ZLIB_H:INTERNAL=1 So there you have it folks. If it doesn't work, *reboot* regenerate your cmake projects and try again. *(*) none of the tools bothered to make a note that the sections are compressed (SHF_COMPRESSED)* ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Phabricator repository
Ah, my bad, that makes more sense. I dropped them an email with the request. - Raphael Am Mi., 1. Aug. 2018 um 09:58 Uhr schrieb : > > > > > -Original Message- > > From: Raphael Isemann [mailto:teempe...@gmail.com] > > Sent: Wednesday, August 01, 2018 12:21 PM > > To: Robinson, Paul > > Cc: Pavel Labath; ioe...@google.com; LLDB Dev > > Subject: Re: [lldb-dev] Phabricator repository > > > > The list is not public, so someone with access needs to mail them > > (which is not true for me :) ). > > This is the prescribed method for admin-style requests. If you're > not subscribed to llvm-admin, the message goes to the moderation > queue, and it will still be seen. Anyone is supposed to be able > to make a request. > --paulr > > > > > - Raphael > > Am Mi., 1. Aug. 2018 um 09:11 Uhr schrieb : > > > > > > Email to llvm-admin should do it. > > > --paulr > > > > > > > -Original Message- > > > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > > Pavel > > > > Labath via lldb-dev > > > > Sent: Wednesday, August 01, 2018 3:52 AM > > > > To: Raphael Isemann; Eric Liu > > > > Cc: LLDB > > > > Subject: Re: [lldb-dev] Phabricator repository > > > > > > > > Sounds like a good idea, though I'm not sure what specifically needs > > > > to be done to make that happen. Eric might know more... > > > > On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev > > > > wrote: > > > > > > > > > > Could we get LLDB into this repository list here? > > > > > https://reviews.llvm.org/diffusion/ > > > > > > > > > > Beside that it's a bit confusing to the user that lldb is the only > > > > > missing project there, it also breaks phabricator/arcanist which > > seems > > > > > to list LLDB commits as LLVM-repo commits (at least my commits get > > > > > automatically an LLVM prefix and sometimes get assigned to the LLVM > > > > > repo). > > > > > > > > > > - Raphael > > > > > ___ > > > > > 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 mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Phabricator repository
> -Original Message- > From: Raphael Isemann [mailto:teempe...@gmail.com] > Sent: Wednesday, August 01, 2018 12:21 PM > To: Robinson, Paul > Cc: Pavel Labath; ioe...@google.com; LLDB Dev > Subject: Re: [lldb-dev] Phabricator repository > > The list is not public, so someone with access needs to mail them > (which is not true for me :) ). This is the prescribed method for admin-style requests. If you're not subscribed to llvm-admin, the message goes to the moderation queue, and it will still be seen. Anyone is supposed to be able to make a request. --paulr > > - Raphael > Am Mi., 1. Aug. 2018 um 09:11 Uhr schrieb : > > > > Email to llvm-admin should do it. > > --paulr > > > > > -Original Message- > > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of > Pavel > > > Labath via lldb-dev > > > Sent: Wednesday, August 01, 2018 3:52 AM > > > To: Raphael Isemann; Eric Liu > > > Cc: LLDB > > > Subject: Re: [lldb-dev] Phabricator repository > > > > > > Sounds like a good idea, though I'm not sure what specifically needs > > > to be done to make that happen. Eric might know more... > > > On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev > > > wrote: > > > > > > > > Could we get LLDB into this repository list here? > > > > https://reviews.llvm.org/diffusion/ > > > > > > > > Beside that it's a bit confusing to the user that lldb is the only > > > > missing project there, it also breaks phabricator/arcanist which > seems > > > > to list LLDB commits as LLVM-repo commits (at least my commits get > > > > automatically an LLVM prefix and sometimes get assigned to the LLVM > > > > repo). > > > > > > > > - Raphael > > > > ___ > > > > 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 mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Phabricator repository
The list is not public, so someone with access needs to mail them (which is not true for me :) ). - Raphael Am Mi., 1. Aug. 2018 um 09:11 Uhr schrieb : > > Email to llvm-admin should do it. > --paulr > > > -Original Message- > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel > > Labath via lldb-dev > > Sent: Wednesday, August 01, 2018 3:52 AM > > To: Raphael Isemann; Eric Liu > > Cc: LLDB > > Subject: Re: [lldb-dev] Phabricator repository > > > > Sounds like a good idea, though I'm not sure what specifically needs > > to be done to make that happen. Eric might know more... > > On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev > > wrote: > > > > > > Could we get LLDB into this repository list here? > > > https://reviews.llvm.org/diffusion/ > > > > > > Beside that it's a bit confusing to the user that lldb is the only > > > missing project there, it also breaks phabricator/arcanist which seems > > > to list LLDB commits as LLVM-repo commits (at least my commits get > > > automatically an LLVM prefix and sometimes get assigned to the LLVM > > > repo). > > > > > > - Raphael > > > ___ > > > 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 mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [7.0.0 Release] The release branch is open; trunk is now 8.0.0
Hi everyone, The release branch for 7.0.0 was created off trunk at r338536 earlier today, and the trunk version was subsequently bumped to 8.0.0. Release blockers are tracked by https://llvm.org/PR38406 Please mark any bugs, old or new, that need to be fixed for the release as blocking that. To get a change committed to the branch, first commit it to trunk as usual, and then request it to be merged -- ideally by filing a blocker bug on https://llvm.org/PR38406, or by cc'ing me on the commit email. (Please try not to request merges over IRC, as they're easy to miss.) Please help with the release by notifying me about any bugs, commits, or other issues you think might be relevant. If it's not marked as blocking PR38406, or I'm not cc'd on an email about it, I'll probably miss it. What's next? In a day or two, once the branch appears reasonable stable, release candidate 1 will be tagged and testing of that can begin. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Phabricator repository
Email to llvm-admin should do it. --paulr > -Original Message- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel > Labath via lldb-dev > Sent: Wednesday, August 01, 2018 3:52 AM > To: Raphael Isemann; Eric Liu > Cc: LLDB > Subject: Re: [lldb-dev] Phabricator repository > > Sounds like a good idea, though I'm not sure what specifically needs > to be done to make that happen. Eric might know more... > On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev > wrote: > > > > Could we get LLDB into this repository list here? > > https://reviews.llvm.org/diffusion/ > > > > Beside that it's a bit confusing to the user that lldb is the only > > missing project there, it also breaks phabricator/arcanist which seems > > to list LLDB commits as LLVM-repo commits (at least my commits get > > automatically an LLVM prefix and sometimes get assigned to the LLVM > > repo). > > > > - Raphael > > ___ > > 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 mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Phabricator repository
Sounds like a good idea, though I'm not sure what specifically needs to be done to make that happen. Eric might know more... On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev wrote: > > Could we get LLDB into this repository list here? > https://reviews.llvm.org/diffusion/ > > Beside that it's a bit confusing to the user that lldb is the only > missing project there, it also breaks phabricator/arcanist which seems > to list LLDB commits as LLVM-repo commits (at least my commits get > automatically an LLVM prefix and sometimes get assigned to the LLVM > repo). > > - Raphael > ___ > 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
