Xcode Cross Debugging (xcxdb)

[Rolf]

I uploaded an installer script that installs everything that is
necessary for symbolically cross debugging Cocotron applications that
are running on a remote Windows host from within Xcode at you Mac.

You will find the installer script, platform specifications, and a
Cocotron Project Template in the following .zip-archive:

http://cocotron-dev.googlegroups.com/web/xcxdb-Installation.zip

Please read the ReadMe.txt file first for the installation
instructions.

Best regards

Rolf

[Rolf]

I added a screenshot that shows, how Xcode Cross Debugging might look
like.

http://cocotron-dev.googlegroups.com/web/xcxdb.png

[Johannes Fortmann]

I only get "Interpreter `miX' unrecognized".
There's no difference if I'm running from Xcode or on the commandline
(with "i386-mingw32msvc-gdb --interp=miX").

Cheers,
Johannes

[Rolf]

On 2 Okt., 13:30, Johannes Fortmann <johannes.fortm...@googlemail.com>
wrote:

> I only get "Interpreter `miX' unrecognized".
> There's no difference if I'm running from Xcode or on the commandline
> (with "i386-mingw32msvc-gdb --interp=miX").

This means quite probably that the xcxdb patches were not copied into
the gdb source tree, and only the original gdb and gdbserver were
built. Might it be, that there are access right problems, that I may
have overseen? Can you please try to run the installer again using
sudo?

Possibly, I have to add a check into the script, that makes sure, that
the patches were really applied.

Many thanks for your patience

Rolf

[Rolf]

On 2 Okt., 14:01, Rolf <rolf.anr...@gmail.com> wrote:

> Possibly, I have to add a check into the script, that makes sure, that
> the patches were really applied.

I just uploaded a new installation script, which checks that the gdb
source tree is in place and that the xcxdb patches has been applied,
before continuing with building gdb and gdbserver. The script will
stop, with an error message, if something has gone wrong with un-
archiving the sources and applying the patches.

Best regards

Rolf

[Johannes Fortmann]

I had to change "cp -Rf $tmpsvndir/ /Developer/Cocotron/1.0/Source/gdb-
$gdbversion" to "cp -Rf $tmpsvndir/* /Developer/Cocotron/1.0/Source/
gdb-$gdbversion" to make the copy work. BTW, instead of doing an svn
checkout and deleting the .svn folders, you could do an svn export.

Cheers,
Johannes

[Rolf]

On 2 Okt., 15:12, Johannes Fortmann <johannes.fortm...@googlemail.com>
wrote:

> On 2 Okt., 19:51, Rolf <rolf.anr...@gmail.com> wrote:
>
> > On 2 Okt., 14:01, Rolf <rolf.anr...@gmail.com> wrote:
>
> > > Possibly, I have to add a check into the script, that makes sure, that
> > > the patches were really applied.
>
> > I just uploaded a new installation script, which checks that  the gdb
> > source tree is in place and that the xcxdb patches has been applied,
> > before continuing with building gdb and gdbserver. The script will
> > stop, with an error message, if something has gone wrong with un-
> > archiving the sources and applying the patches.
>
> I had to change "cp -Rf $tmpsvndir/ /Developer/Cocotron/1.0/Source/gdb-
> $gdbversion" to "cp -Rf $tmpsvndir/* /Developer/Cocotron/1.0/Source/
> gdb-$gdbversion" to make the copy work.

Are you really sure?

man cp suggests something different for the option -R, and for me the
copy command works without the wildcard after $tmpsvndir/.

-R If source_file designates a directory, cp copies the directory
and the entire subtree connected at that point. If the
source_file
ends in a /, the contents of the directory are copied rather
than the directory itself...

I am somewhat reluctant in buying this explanation of the failure,
because before publishing the script I tested the especially this cp -
Rf command without the wildcard after the / rigorously. So please may
I ask you to confirm again, that this makes the difference on your
machine, and I will change the script accordingly.

> BTW, instead of doing an svn checkout and deleting the .svn folders,
> you could do an svn export.

OK, many thanks for the hint, I will change the script accordingly.

Best regards

Rolf

[Johannes Fortmann]

On 2 Okt., 20:49, Rolf <rolf.anr...@gmail.com> wrote:
> Are you really sure?
>
> man cp suggests something different for the option -R, and for me the
> copy command works without the wildcard after $tmpsvndir/.
>
> -R    If source_file designates a directory, cp copies the directory
>         and the entire subtree connected at that point.  If the
> source_file
>         ends in a /, the contents of the directory are copied rather
>         than the directory itself...
>
> I am somewhat reluctant in buying this explanation of the failure,
> because before publishing the script I tested the especially this cp -
> Rf command without the wildcard after the / rigorously. So please may
> I ask you to confirm again, that this makes the difference on your
> machine, and I will change the script accordingly.

The problem is because I'm using the gnu fileutils (I love the color
ls, and being able to use the same syntax as in Linux). So changing
the call to cp to calling /bin/cp directly should have the same
effect.

Cheers,
Johannes

[Rolf]

On 2 Okt., 16:01, Johannes Fortmann <johannes.fortm...@googlemail.com>
wrote:

OK, now this is clear.

I changed the script so that it now calls cp as /bin/cp, and I did the
same for the calls to rm and mkdir. I checked, that the script works,
and I replaced already the old version by this new one at the same
location:

http://cocotron-dev.googlegroups.com/web/xcxdb-Installation.zip


Best regards

Rolf

[Johannes Fortmann]

Yay! Now it works. Very nice work! At first it didn't find any debug
information for AppKit and Foundation for me, but then it suddenly did
(don't remember changing anything to make it work...).
What doesn't seem to work is pausing a running program, showing
descriptions of non-primitive types (BOOLs and char*s show up, but ids
don't), and po. Am I still doing something wrong, or is that stuff
just temporarily broken?

Anyway, thanks a lot; graphical debugging should make developing a lot
better.

Cheers,
Johannes

[Rolf]

On 3 Okt., 10:33, Johannes Fortmann <johannes.fortm...@googlemail.com>
wrote:

> Yay! Now it works. Very nice work! At first it didn't find any debug
> information for AppKit and Foundation for me, but then it suddenly did
> (don't remember changing anything to make it work...).

Sometimes I produce a Release Build of my application and for this I
also need to Release-build the frameworks. If I then switch back my
application to the Debug configuration and forget to re-compile the
frameworks in the Debug configuration, then this happens for me too.

As a matter of fact, this situation is anyway something that I wanted
to discuss. Switching between Release and Debug configuration is in
the current setup of the frameworks a pain, because this involves
complete rebuilding.

How about having a separate framework version B for debugging and
keeping framework A for release builds only.

> What doesn't seem to work is pausing a running program

This is a known issue. I had already a look at this. The point is,
that I need to send somehow ctrl-c to gdbserver, and if I do this
manually from Terminal, then it indeed stops the program, without
unloading it, but I was not able to resume it again, I have to look
closer into this once I got some more inspiration.

> showing descriptions of non-primitive types (BOOLs and char*s
> show up, but ids don't), and po. Am I still doing something wrong,
> or is that stuff just temporarily broken?

No, this is also not working for me, and one of the reason is that
Xcode obviously utilizes an external helper GDBMIDebuggingPlugin, and
as a matter of fact this crashes now in the latest Xcode version, once
I enable the Data Formatters. I did not investigate this up to now,
and I cannot tell if there might be way around, because this plugin is
loaded by the debugger itself by the way of the dlopen() command.

> Anyway, thanks a lot; graphical debugging should make developing a lot better.

Many thanks for the response.

Best regards

Rolf

[Alexei Svitkine]

The instruction seems to assume the user will be starting a new
project from the installed template. Could additional info be added on
how to update an existing project (that already targets Cocotron) to
be debuggable in this manner?

-Alexei

> No, this is also not working for me, and one of the reason is thatXcodeobviously utilizes an external helper GDBMIDebuggingPlugin, and
> as a matter of fact this crashes now in the latestXcodeversion, once

> I enable the Data Formatters. I did not investigate this up to now,
> and I cannot tell if there might be way around, because this plugin is
> loaded by the debugger itself by the way of the dlopen() command.
>

> > Anyway, thanks a lot; graphicaldebuggingshould make developing a lot better.

[Rolf]

If you want to update an existing Cocotron project, then you basically
need to go through the following exercise:

1. Upgrade to Xcode 3.1.1
2. add to your existing project a "Debug" configuration
3. adjust the build settings of the "Debug" configuration as in a
project that is derived from the installed template.
Pay special attention when setting the framework and compiler to
be used
4. make the "Debug" configuration of "YourWindowsApp" the active one
5. in the info panel 'Executable "YourWindowsApp" Info - General' set
the working directory to the project directory
6. in the info panel 'Executable "YourWindowsApp" Info - Debugging'
set "Use Pipe" for standard input/output
7. add the files debug.bat and Remote-Target.txt to your project
8. add the Run Script phases to the target of your Cocotron Windows
Application
9. if you want to be able to debug and step into the Cocotron
frameworks then you need to clean (including dependencies) and build
the "Debug" configuration of the Cocotron-AppKit framework
10. clean and build the target of your Cocotron Windows Application

Now you should be set up to the point where you could start your app
by the way of gdbserver.exe and debug it from Xcode. So skip steps 1-8
of the xcxdb-instruction in "ReadMe.txt" and follow the instructions
starting at step 9.

Honestly, I think that it might be less work, to start with a new
project derived from the template and add your files to it. If you do
not need special settings, then this might be as simple as dragging
the complete set of your sources from your old project and drop it
into the new one (derived from the template). Only, select "Copy items
into destination group's folder (if needed)" and make sure that all
desired targets are selected.

[josephm...@gmail.com]

You wouldn't happen to still have the xcxdb-Installation.zip

I have been looking all over for it and for whatever reason, I am unable to locate it