How to set breakpoints in a php script using gdb

I am trying to debug a php scripts via console with GDB but I am not able to set breakpoints. This is what I’ve done. I’ve created a script with this content:

<?php
echo "1";
echo "1";
echo "1";
echo "1";
echo "1";
echo "1";
echo "1";

And this is my temptative to debug it

# gdb php -d CANCELLAMI.php 
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...

warning: /root/CANCELLAMI.php is not a directory.
Reading symbols from /usr/bin/php...(no debugging symbols found)...done.

Now that I am inside gdb, I put a breakpoint in line 2.

(gdb) break CANCELLAMI.php:2
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CANCELLAMI.php:2) pending.

But if I run CANCELLAMI script

(gdb) run CANCELLAMI.php 
Starting program: /usr/bin/php CANCELLAMI.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
11111111[Inferior 1 (process 30216) exited normally]

the whole script is executed.

Answer

Short answer: If you want to debug PHP scripts use xdebug.

---

Currently, gdb can only really debug compiled languages. It has a lot of knowledge baked in about executable file formats, debug info formats, how to unwind stack frames, and low-level stuff like that. What it doesn’t have is a way to associate these things with higher-level constructs in interpreters.

Now, it is possible to debug scripts this way, if you know enough about the interpreter. You can step through the interpreter and understand what it is doing. I’ve done this before — it is doable but not exactly pleasant. It’s hard enough that it’s only really worth doing if you are trying to find a bug in the interpreter triggered by some particular script.

Occasionally the idea arises that gdb could debug scripts. This is a good idea, but it is a reasonably large amount of work. As far as I know, nobody is currently working on it.