Re: [lldb-dev] Where "thread until " should set breakpoints?
Thanks Jim for the elaborate reply.
I knew what is happening in below piece of code and also has a patch ready
but now needs a bit of fine tuning based on your below comments. I just
wanted to hear from you folks that my understanding is correct and I am not
missing something.
Also, the code around it needs modification of error messages to refer to
'thread->GetID()' instead of 'm_options.m_thread_idx'. I will create a
review on phabricator with all these changes.
- Ramana
On Thu, Aug 2, 2018 at 10:56 PM, Jim Ingham wrote:
> That's a bug. The code in CommandObjectThreadUntil needs to be a little
> more careful about sliding the line number to the "nearest source line that
> has code." It currently does:
>
> for (uint32_t line_number : line_numbers) {
> uint32_t start_idx_ptr = index_ptr;
> while (start_idx_ptr <= end_ptr) {
> LineEntry line_entry;
> const bool exact = false;
> start_idx_ptr = sc.comp_unit->FindLineEntry(
> start_idx_ptr, line_number, sc.comp_unit, exact,
> &line_entry);
> if (start_idx_ptr == UINT32_MAX)
> break;
>
> addr_t address =
> line_entry.range.GetBaseAddress().GetLoadAddress(target);
> if (address != LLDB_INVALID_ADDRESS) {
> if (fun_addr_range.ContainsLoadAddress(address, target))
> address_list.push_back(address);
> else
> all_in_function = false;
> }
> start_idx_ptr++;
> }
> }
>
> The problem is that in the while loop we set:
>
> const bool exact = false;
>
> Having exact == false through the whole loop means that all the other line
> table entries after the last exact match will match because from the index
> ptr on there are no more entries, so we slide it to the next one.
>
> In general it's not always easy to tell which lines will actually
> contribute code so lldb is lax about line number matching, and slides the
> breakpoint to the nearest subsequent line that has code when there's no
> exact match. That seems a good principle to follow here as well. So I
> don't want to just set exact to "true".
>
> I think the better behavior is to try FindLineEntry the first time with
> exact = false. If that picks up a different line from the one given, reset
> the line we are looking for to the found line. In either case, then go on
> to search for all the other instances of that line with exact = false. It
> might actually be handy to have another function on CompUnit like
> FindAllEntriesForLine that bundles up this behavior as it seems a generally
> useful one.
>
> If you want to give this a try, please do. Otherwise, file a bug and I'll
> get to it when I have a chance.
>
> Jim
>
>
>
> > On Aug 1, 2018, at 10:22 PM, Ramana wrote:
> >
> >
> > 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 (kernel
Re: [lldb-dev] Where "thread until " should set breakpoints?
I have created https://reviews.llvm.org/D50304.
BTW, I almost forgot the fact that the error message changes were already
covered in my other patch https://reviews.llvm.org/D48865.
On Fri, Aug 3, 2018 at 11:41 PM, Jim Ingham wrote:
> Thanks! I look forward to the patch.
>
> Jim
>
>
> > On Aug 2, 2018, at 8:56 PM, Venkata Ramanaiah Nalamothu <
> ramana.venka...@gmail.com> wrote:
> >
> > Thanks Jim for the elaborate reply.
> >
> > I knew what is happening in below piece of code and also has a patch
> ready but now needs a bit of fine tuning based on your below comments. I
> just wanted to hear from you folks that my understanding is correct and I
> am not missing something.
> >
> > Also, the code around it needs modification of error messages to refer
> to 'thread->GetID()' instead of 'm_options.m_thread_idx'. I will create a
> review on phabricator with all these changes.
> >
> > - Ramana
> >
> > On Thu, Aug 2, 2018 at 10:56 PM, Jim Ingham wrote:
> > That's a bug. The code in CommandObjectThreadUntil needs to be a little
> more careful about sliding the line number to the "nearest source line that
> has code." It currently does:
> >
> > for (uint32_t line_number : line_numbers) {
> > uint32_t start_idx_ptr = index_ptr;
> > while (start_idx_ptr <= end_ptr) {
> > LineEntry line_entry;
> > const bool exact = false;
> > start_idx_ptr = sc.comp_unit->FindLineEntry(
> > start_idx_ptr, line_number, sc.comp_unit, exact,
> &line_entry);
> > if (start_idx_ptr == UINT32_MAX)
> > break;
> >
> > addr_t address =
> > line_entry.range.GetBaseAddress().
> GetLoadAddress(target);
> > if (address != LLDB_INVALID_ADDRESS) {
> > if (fun_addr_range.ContainsLoadAddress(address, target))
> > address_list.push_back(address);
> > else
> > all_in_function = false;
> > }
> > start_idx_ptr++;
> > }
> > }
> >
> > The problem is that in the while loop we set:
> >
> > const bool exact = false;
> >
> > Having exact == false through the whole loop means that all the other
> line table entries after the last exact match will match because from the
> index ptr on there are no more entries, so we slide it to the next one.
> >
> > In general it's not always easy to tell which lines will actually
> contribute code so lldb is lax about line number matching, and slides the
> breakpoint to the nearest subsequent line that has code when there's no
> exact match. That seems a good principle to follow here as well. So I
> don't want to just set exact to "true".
> >
> > I think the better behavior is to try FindLineEntry the first time with
> exact = false. If that picks up a different line from the one given, reset
> the line we are looking for to the found line. In either case, then go on
> to search for all the other instances of that line with exact = false. It
> might actually be handy to have another function on CompUnit like
> FindAllEntriesForLine that bundles up this behavior as it seems a generally
> useful one.
> >
> > If you want to give this a try, please do. Otherwise, file a bug and
> I'll get to it when I have a chance.
> >
> > Jim
> >
> >
> >
> > > On Aug 1, 2018, at 10:22 PM, Ramana wrote:
> > >
> > >
> > > 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 t
[lldb-dev] [LLD] How to get rid of debug info of sections deleted by garbage collector
Hi, After compiling an example.cpp file with "-c -ffunction-sections" and linking with "--gc-sections" (used ld.lld), I am still seeing debug info for the sections deleted by garbage collector in the generated executable. Are there any compiler/linker options and/or other tools in LLVM to get rid of the above mentioned unneeded debug info? If such options does not exist, what needs to be changed in the linker (lld)? Thanks, Ramana ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [LLD] How to get rid of debug info of sections deleted by garbage collector
Thank you all for your time in responding to my query. My understanding was also similar to what you all mentioned here but wanted to check if there are any recent developments in solving this problem. Thanks, Ramana On Thu, Sep 20, 2018 at 9:32 PM, Rui Ueyama wrote: > Right. Technically we can get rid of debug info that corresponds to dead > sections, but in order to do that, you have to scan the entire debug info. > Debug info is actually one of only few pieces of information that the > linker has to have a special logic to merge them, and that is already slow. > IIUC, debug info for dead sections doesn't do any harm, so spending time in > the linker to get rid of it isn't probably worth the cost. If we really > need to do, I want a new mechanism as Paul wrote. > > On Thu, Sep 20, 2018 at 8:57 AM via llvm-dev > wrote: > >> >> > -Original Message- >> > From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of >> > Davide Italiano via llvm-dev >> > Sent: Thursday, September 20, 2018 10:55 AM >> > To: ramana.venka...@gmail.com; Cary Coutant >> > Cc: llvm-dev; LLDB >> > Subject: Re: [llvm-dev] [lldb-dev] [LLD] How to get rid of debug info of >> > sections deleted by garbage collector >> > >> > On Wed, Sep 19, 2018 at 8:35 PM Venkata Ramanaiah Nalamothu via >> > lldb-dev wrote: >> > > >> > > Hi, >> > > >> > > After compiling an example.cpp file with "-c -ffunction-sections" and >> > linking with "--gc-sections" (used ld.lld), I am still seeing debug info >> > for the sections deleted by garbage collector in the generated >> executable. >> > > >> > > Are there any compiler/linker options and/or other tools in LLVM to >> get >> > rid of the above mentioned unneeded debug info? >> > > >> > > If such options does not exist, what needs to be changed in the linker >> > (lld)? >> > > >> > >> > It's not easy. It's also format dependent. I assume you're talking >> > about ELF here. In first approximation, the linker does not GC section >> > marked without SHF_ALLOC. At some point we did an analysis and in >> > practice it turns out most of them are debug info. >> > I seem to recall that Cary Coutant had a proposal for ld.gold on how >> > to reclaim them without breaking, but I can't find it easily (cc:ing >> > him directly). >> >> The short answer is: Nothing you can do currently. >> >> I had a chat with some of the Sony linker guys last week about this. >> Currently .debug_info is monolithic; we'd have to break it up in some >> fashion that would correspond with the way .text is broken up with >> -ffunction-sections, in such a way that the linker would automatically >> paste the right pieces back together to form a syntactically correct >> .debug_info section in the final executable. There are some gotchas >> that would need to be designed correctly (e.g. reference from an >> inlined-subprogram to its abstract instance) but it didn't seem like >> the problems were insurmountable. >> >> The ultimate design almost certainly requires agreement about what the >> ELF pieces should look like, and a description in the DWARF spec so >> that consumers (e.g. dumpers) of the .o files would understand about >> the fragmented sections. And then the linkers and dumpers have to >> be modified to implement it all. :-) >> >> Even without gc-sections, there is duplicate info to get rid of: >> everything that ends up in a COMDAT, like template instantiations >> and inline functions. This is actually a much bigger win than >> anything you'd see left behind by GC. >> --paulr >> >> > >> > Thanks, >> > >> > -- >> > Davide >> > ___ >> > LLVM Developers mailing list >> > llvm-...@lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> ___ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
