[xdebug-general] Re: how breakpoints relate to filenames when remote debugging

On Mon, 14 May 2018, David Bradley wrote:

> Hi Derek,

It's Derick

> *** In looking at the xdebug log file. I am seeing no entries that show
> breakpoints being set or cleared. I would expect those events to be
> logged, correct?

Yes, you should see "breakpoint_set" commands showing up.

> If you confirm that they should have been present I will turn to my
> IDE (Eclipse) to see why it isn't making the calls even though it
> shows all the visual activity of breakpoint setting and clearing.

I'm not an Eclipse user, but it is possible that it decides not to send
breakpoints because it doesn't have a path mapping at all for the
initial file — which you can see in the <init package.

cheers,
Derick

> On Monday, 14 May 2018, Derick Rethans <derick[@]xdebug.org> wrote:
>
> > On Wed, 2 May 2018, David Bradley wrote:
> >
> > > >From the DBgp docs I gleaned that:
> > > 1) (file) breakpoints commands take a filename and a line number
> > > 2) file names have to be absolute paths
> > > 3) probably shouldn't have spaces (whoever thinks spaces in paths are a
> > > good idea is nuts)
> > > 4) may have some case sensitivity issues when crossing Windows -> linux
> > VM
> > > worlds?
> >
> > That's all correct.
> >
> > > 5) some kind of mapping from server, debugger, and IDE views of filenames
> > > is required.
> >
> > This is solely an IDE issue. Xdebug does not know anything about
> > mappings.
> >
> > > Could you give the community an explanation of the steps from a user
> > > asking for a breakpoint to be created in an IDE, through all path
> > > mappings to the debugger - being careful to identify which component
> > > has the responsibility of mapping
> >
> > The IDE needs to map. As Xdebug only runs on the server side, it has no
> > knowledge of the file paths on the machine where your IDE runs. And the
> > IDE (likely) has no idea of the paths on the machine where Xdebug runs.
> > It's therefore unfortunately necessary for users to configure this
> > mapping in their IDE. For most projects, you would only need to set the
> > root.
> >
> > > In the general case for remote debugging the root location of the
> > > files in the IDE and the webserver are different names and
> > > inaccessible to one another (hence the term "remote").
> > >
> > > If you could also identify the canonical perspective and format of the
> > > filenames in the debugger (if there is one)
> >
> > It's what PHP reports to Xdebug - often the absolute path name as
> > returned by the "realpath" system call. A PHP equivalent function of
> > realpath is documented at http://php.net/realpath
> >
> > > Moreover (just in case this matters) URLs passed from the webserver are
> > not
> > > guaranteed to map via a simple root prefix to any file name ( eg "
> > > https://foo/inbox" might map to
> > > <someroot>/<someintermediatepath>/inbox-xxx.php) - this would mean web
> > > URLs are not relevant for breakpoints
> >
> > That's correct. Web URLs have no relation to setting breakpoints.
> >
> > > Hopefully with this information I will be able to figure out what my
> > > IDE is supposed to be doing and configure it correctly according to
> > > some methodology rather than from random posts of desperate developers
> >
> > You can also have a look at the log files that Xdebug makes if you
> > configure xdebug.remote_log
> > (https://xdebug.org/docs/all_settings#remote_log) — it will show you
> > exactly which commands the IDE sets, which should allow you to see
> > whether it does something wrong with file path roots for example.
> >
> > cheers,
> > Derick
> >
> > --
> > Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> > or become my Patron: https://www.patreon.com/derickr
> > Xdebug | https://xdebug.org | xdebug-general@lists.xdebug.org
> > twitter: @derickr and @xdebug
>

-- 
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
Xdebug | https://xdebug.org | xdebug-general@lists.xdebug.org
twitter: @derickr and @xdebug