[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Debug source lookup question
> Using source path information in the executable to determine the breakpoint scope sounds like a neat idea, but I don't think it would scale.
 
Yes, the scalability is the only reason why it hasn't been implemented. But I still believe that provided with a better support from GDB it could be done. 
At the same time if GDB could solve the source lookup problems internally we would only need to perform the external source lookup if the debug information was not sufficient.
 
Mikhail
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Thursday, November 20, 2008 5:24 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Debug source lookup question

Hi,

I find this conversation very interesting as sourfilce lookup and breakpoint filtering (or scope) are some of the most persistent usability problems for our customers.  I hope that eventually we can pull together our resources and come up with something that really works.

In the Wind River product, the idea behind source lookup logic is essentially identical to that of CDT.  We have a path substitution source container and if the user maps his sources using this container, we will send a full path to the debugger.  If user configures a search source container (e.g. Project, Folder, etc.), we will send just the filename to the debugger.  Unfortunately, the difference between these two is usually too subtle for users and they get into trouble.  We have a few UI additions to help the user identify when the source lookup is causing breakpoints to be planted on the wrong file, but this also is not enough.  So I'm very curious if there's any new ideas out there on how to deal with this problem.

On breakpoint filtering (or scope as we call it), I've never even considered using project or other information to automatically scope breakpoints to a given debug session.  Instead our breakpoints have an explicit parameter that specifies which launch configurations a given BP applies to.  This requires an explicit user action to specify the scope, but in practice the it is set when the breakpoint is created based on the currently active debug session.  It's a simple solution, but obviously not fool-proof. 

Using source path information in the executable to determine the breakpoint scope sounds like a neat idea, but I don't think it would scale.  Just like parsing through the project structure to generate -environment-directory commands takes a long time, processing all the paths in a 200MB executable image would be very painful.

-Pawel

Mikhail Khodjaiants wrote: 
Sorry James, my example is not correct. The correct paths are
"/project/foo/../main.c" and "/project/main.c". The point is that both
represent the same file, but from the GDB's point of view there are
different.

  
A better solution might be to look in the binary and check whether
    
there are any source file collisions before attempting to set
breakpoints.

That's what I am proposing, but instead of parsing the binary, we let
GDB to do the work and retrieve the list of source files and their paths
from GDB. In this case we can use absolute paths to set breakpoints. If
we need to set a breakpoint at "/project/main.c" the source lookup will
translate the path to "/project/foo/../main.c" and GDB will understand
it.
With absolute paths we won't have file collisions.

Mikhail

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of James Blackburn
Sent: Thursday, November 20, 2008 1:07 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Debug source lookup question

Hi Mikhail,

Not meaning to labour the point, but I think we have two separate issues
here.

  
I can't comment on the latest changes - haven't worked on or used 
seriously a CDT/GDB based debugger for more than a year. If there is a
    

  
problem with AbsolutePathSourceContainer it should be fixed.
    

I don't think there is a problem with it.  If execution stops at some
external absolute file path -- for example the user steps into a library
function (where the library has debug symbols) they should see the
source.  It would be overkill to force the user to add all external
source locations to the launch config "Source" tab.  For this
AbsolutePathSourceContainer does what it says on the tin.

  
But I still think the synchronization with the source lookup is 
required. If executable is compiled with "/foo/../main.c" setting a 
breakpoint at "/foo/main.c" wouldn't work. And the source lookup is 
the place where we can resolve this type of issues.
    

I see there is a problem here, but it's not one the source locator
solves:
  - If both main.c's were in different projects, marker comparison would
spot this.
  - If they are in the same project, and not both built into the same
executable, your default Project Path Container would also fail --
there's a collision here and both exist in the source container.
  - If both main.c's are in the same project and built into the same
executable then you're scuppered if you don't select "Use full file path
to set breakpoints" as the breakpoints aren't disambiguated before being
set (cdt just uses main.c:xx as discussed previously).

A better solution might be to look in the binary and check whether there
are any source file collisions before attempting to set breakpoints.

>From my point of view, if you make the source locators too specific
(so breakpoints are filtered) then when the target stops you risk not
finding the source.  If you make it too general -- allowing it to
resolve all source on a best effort basis -- then all breakpoints are
set on launch.

Even though both features are based on sets of source files: the set of
files with breakpoints that will be set on launch,  is contained within
the set of source file locations we can resolve in the IDE, and not vice
versa.  (Obviously the sets are equivalent if we know exactly what files
are built into an executable, but this isn't what the source locator
provides.)

Cheers,

James
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.