Debug source lookup question

View: New views
3 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

RE: Debug source lookup question

by Mikhail Khodjaiants-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Daniel,

Not sure I understand how substitute-path is used. Are the rules defined
by substitute-path applied (in reverse) when setting a breakpoint? Are
they used when the "full path" attribute of a stack frame is generated?

Thanks,
Mikhail

-----Original Message-----
From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...]
On Behalf Of Daniel Jacobowitz
Sent: Friday, November 21, 2008 1:55 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Debug source lookup question

On Thu, Nov 20, 2008 at 06:11:05PM -0000, Mikhail Khodjaiants wrote:
> 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.

Source lookup is an environment issue by definition.  For GDB to get it
right, you have to give it adequate and correct information.
What this means in practice, I think, is (A) not dumping a pile of
-environment-directory commands at GDB, and (B) offering an interface to
the source translation mechanism in recent versions of GDB (set
substitute-path).  I haven't thought about it much, but it seems to me
that the ideal interface for this would require a file browser - for
instance, have the user locate one source file manually and then figure
out how many directory levels up to set substitute-path (containing
directory?  grandparent directory?).

--
Daniel Jacobowitz
CodeSourcery
_______________________________________________
cdt-dev mailing list
cdt-dev@...
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.


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

RE: Debug source lookup question

by Mikhail Khodjaiants-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Yes, if the full path issue is solved there is no need to read sources
from GDB.

-----Original Message-----
From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...]
On Behalf Of Vladimir Prus
Sent: Sunday, November 23, 2008 7:56 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Debug source lookup question

On Thursday 20 November 2008 17:07:10 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.

Not necessary. On Linux, GDB uses realpath, so it does not care much how
you specify the file. On Windows, this is not the case now -- I've
posted a patch to fix it, but it's not in GDB CVS.

>
> > 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.

I'm getting confused. What problem is solved by getting the list of
source files from GDB? Assuming the GDB issue with full paths on Windows
is fixed, you can just *always* send full path when setting a
breakpoint.

Using the list of source paths from GDB to filter breakpoints does not
seem necessary, either -- if GDB does not know about a source file, it
won't set a breakpoint -- there's no need to do such filtering on CDT
side. Note also that in presense of shared libraries, including
on-demand loaded ones, the list of source paths becomes undefined
notion.

- Volodya

_______________________________________________
cdt-dev mailing list
cdt-dev@...
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.


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

Re: Debug source lookup question

by Daniel Jacobowitz-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Mon, Nov 24, 2008 at 10:50:22AM -0000, Mikhail Khodjaiants wrote:
> Daniel,
>
> Not sure I understand how substitute-path is used. Are the rules defined
> by substitute-path applied (in reverse) when setting a breakpoint? Are
> they used when the "full path" attribute of a stack frame is generated?

Sorry for the delay over the holidays, I almost missed this message.

Most paths you specify to GDB are where-GDB-found-the-file paths, not
what-was-in-the-debug-info paths.  So if you apply set substitute-path
to convert a missing (or incorrect) /foo/bar.c into /new/bar.c, then
/new/bar.c:100 ought to work.

--
Daniel Jacobowitz
CodeSourcery
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
< Prev | 1 - 2 | Next >