But since you're asking this on cll, last year I started to implement
a virtual-fs in lisp, storing the data _inside_ the lisp image
(providing a CL-like file and stream API).  If you're interested I may
share this GPL code...

http://www.xach.com/lisp/lispvan-2008-02-28.pdf

What do you think about hybrid approach to your task: you might parse
debugging info directly from binary but interface gdb instead of
writing your own lispy debugger? It should save lots of effort. I came
from Windows world and never used gdb but I've heard it supports
runtime evaluation. All you need to add is a support for lisp
callbacks to gdb itself, not to program you debug. Interfacing can be
done safely with sockets/pipes.

I've seen reports that linking into lisp is generally a bad practice:
C code being debugged is often unreliable and lisp is relatively heavy-
weight. If you debug small C library linked into huge lisp image and
it crashes, you need to restart entire lisp image and lose all lisp
session context. Much worse is the situation where lisp gets hurt, but
_dont_ crash. Interfacing gdb should solve this issue.

What is VFS and could it help in my task. It is easier than fuse? Can
I work with is safely?

Pascal, thanks. I use sbcl with threads enabled and run fuse_main in
separate thread. Problem was with daemonizing. Fuse daemonizes itself
unless -f switch is passed and swank refuses to work (I don't know
why). Now I've passed -f switch and all works fine: I start sbcl from
Emacs as usual and filesystem is mounted by just

(bordeaux-threads:make-thread (lambda () (my_main (callback
readstringfromlisp))))

Then I continue working from slime as usual, trace calls to my code
from fuse, etc. For the first 5 minutes it seem to work fine :) I can
even unmount filesystem, rebuild and reload my fuse example hello.so
and all still works.

Few words about what I'm doing. In years, I've tried to use several
approaches to MP in other languages. I've used m4, custom
preprocessors written in lisp, codegenerators written in lisp. But I
was never satisfied completely and I could never approach the ease of
use I had in lisp. Now I try to make reversible macroexpander. It
would consist of:
- lexical analyser for a target language which converts file to a list
of lexems (I've got one for Delphi now, other languages can be added
easily)
- lispy toolbox for operating lexems in memory, e.g. for search and
replace, parsing of some constructs. Maybe a complete parser. I have
some bits of it.
- printer which writes converted lexems back to a text file. This is
very easy

When you macroexpand, it's rather trivial to mark the extended code (be
it syntactic tree like in lisp, or text like in other macro systems), to
be able to distinguish the "template" parts from the "hook" parts (the
parts provided by the user.  Then the editor could present the expanded
template parts in some read-only face, while the hook parts would still
be editable.  When imploding the macro, you could also easily use this
marking to recover the macro and its arguments (the "hook" parts).

Also, notice that it's hardly possible in general with lisp macros,
since they're turing complete.  For example:

(defmacro m (a)
   (if (and (listp a) (member (first a) '(+ - * /)))
      `(print ,a)
      (let ((r (gensym)))
         `(let ((,r (multiple-value-list ,a)))
             (mapcar 'print ,r)
             (values-list ,r)))))

would expand to different forms depending on the expression a.
If you change the expression a in the expanded form, then you would have
to go back to the imploded form, and reexpand it.

Also the expansion could duplicate the arguments or parts of them:

(defmacro m (a)
   `(progn (print ',a)
           ,a))

Expanding (m (+ 3 4))  you'd get:

   (progn (print '(+ 3 4))
          (+ 3 4))

if you edit it to have:

   (progn (print '(+ 31 42))
          (+ 3 4))

then how can you implode it back, since the two occurences of the
argument are now different?

And no part of the argument may even be present in the expanded form:

(defmacro m (a)
   (if (consp a)
     '42
     '(do-something-else)))

Expanded you'd have either:

    42

or:

    (do-something-else)

both being marked as "template" and non editable.

So your what you're trying to do may be possible with lesser macro
systems, but if they're as powerfull as Lisp then it won't be possible
to do it systematically.  You may implement some heuristics working
sometimes, in some circumstances, but nothing general.

#wme 42 (m (foo bar))

where first form is result and second is an original form (which
should be skipped by reader). In Delphi it would be something like

42(*me m(foo(bar))*)

You could have other trees for symbol values, symbol plists, and symbol
functions. Entries for symbol functions would be executable, and you
could call lisp functions from the shell:

   ~/fuse-2.5.3/functions/COMMON-LISP/DIRECTORY "/tmp/*.lisp" RET

would run (CL:DIRECTORY "/tmp/*.lisp")

   ~/fuse-2.5.3/functions/COMMON-LISP/+ 1 2 3 4 RET

 would print 10.

Feel free to mine this one for ideas:

    http://rpw3.org/hacks/lisp/cgi_sock.c

It was originally written to provide a rough equivalent to the
"mod_lisp" Apache module but as a separate external CGI program.
However, I've also hacked up versions on occasion to pass command
line argument to the persistent CL application server "as if"
they'd come from the Web.

The biggest problem with the "C client/Lisp server" model is
securing the connection without compromising the lightweight
nature of the protocol. [That is, you don't want to run a whole
OpenSSL suite, which would be more expensive than fork/exec'ing
a new Lisp image!]  On Linux/Unix systems, that can be easily
accomplished by (1) using only local domain sockets (AF_UNIX,
AF_LOCAL, or AF_POSIX, depending on your operating system's stack),
*not* TCP, and (2) securing access to the directory *above* the
socket, since some operating systems ignore the file permissions
on the socket file itself.

-Rob

p.s. There's also a matching stub server in C that might be helpful
while debugging your Lisp server:

    http://rpw3.org/hacks/lisp/cgi_sockd.c

int main(int args, char**argv) {
  struct stat test;
  return 0;

Thus we can get full type information of structure.
If we grab it, it seems we can do FFI easily and reliably.

2. Highly viable, especially for C.  The only pitfalls are getting the
right compiler and compilation flags (true of any grovelling method).

3. CL is one of the few systems to allow direct FFI binding at runtime
(as opposed to compiling C stubs for the API translation).  As such,
most systems take a SWIG-style approach instead of using the debug info.

Since you probably only need a few fields out of struct stat, and you
already know their names, Autoconf provides a more portable (not
gcc/gdb-specific) way to grovel information about the structure.

# cat <<_EOF > configure.ac
AC_INIT
AC_PROG_CC

AC_COMPUTE_INT(SIZEOF_stat, [sizeof(struct stat)],
   [#include <sys/stat.h>])
AC_COMPUTE_INT(SIZEOF_ctime, [sizeof(((struct stat *)0)->st_ctime)],
   [#include <sys/stat.h>])
AC_COMPUTE_INT(ADDROF_ctime, [&(((struct stat *)0)->st_ctime)],
   [#include <sys/stat.h>])

echo sizeof stat $SIZEOF_stat
echo sizeof st_ctime $SIZEOF_ctime
echo addrof st_ctime $ADDROF_ctime
_EOF

# autoconf
# ./configure
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
sizeof stat 144
sizeof st_ctime 8
addrof st_ctime 104

So here we see that "struct stat" has a total size of 144 chars, and
that chars 104 to 104+8=112 form the st_ctime field...

Autoconf compiles at least one program per value found; but this
generally isn't noticeable for a small number of values.  When
Autoconf detects a cross-compile, it uses a slower bit-banging
approach to finding the values.

If you don't care about the cross-compile capability, it is easier to
ask C to report the values directly.

# cat <<_EOF > test.c
#include <sys/stat.h>
#include <stdio.h>

int main(int argc, char **argv)
{
   struct stat *dummy=0;
   printf("sizeof stat %d\n", sizeof(*dummy));
   printf("sizeof st_ctime %d\n", sizeof(dummy->st_ctime));
   printf("addrof st_ctime %d\n", &(dummy->st_ctime));
   return 0;

# gcc -o test test.c
# ./test
sizeof stat 144
sizeof st_ctime 8
addrof st_ctime 104

Once you know the sizes and addresses of each field of interest, a
CFFI binding (with filler for unused values) should be easy to write.

For example, on my system, struct stat could be imitated as
struct pseudo_stat
{
   char filler0[104];
   uint64_t st_ctime;
   char filler1[32];

Autoconf is very like cffi-grovel, and I think cffi-grovel is more
natural to use with lisp:
it produces ready cffi bindings. But cffi-grovel need names of
structure slot types too.

The most problematic case is

#ifndef __USE_FILE_OFFSET64
__blkcnt_t st_blocks; /* Number 512-byte blocks allocated. */
#else
__blkcnt64_t st_blocks; /* Number 512-byte blocks allocated. */
#endif

I do not know name of the type, so I can't give it to cffi-grovel.

But I think I found the solution for that just now :) Solution is to
have my own

typedef
#ifndef __USE_FILE_OFFSET64
__blkcnt_t
#else
__blkcnt64_t
#endif
my_st_blocks_type;

in a file which I'll #include to cffi-grovel's test program.

And then I'll say cffi-grovel that st_blocks is of type
my_st_blocks_type.
Case of