David Rhodus <sdrhodus@gmail.com> wrote:

> > I have been tracking down this problem using gdb, which is not easy
> > since our gdb does not read symbols from Mach-O binaries (MacOS X uses
> > an executable format known as Mach-O. We use ELF). Facing an impossible
> > debugging work, I see three ways of working around the problem 
> Can't you just use the gdb from one of the Apple code drops ?

You mean using Darwin's gdb on NetBSD? Or rebuilding the gdb sources
from Darwin CVS on NetBSD?

Using Darwin's gdb on NetBSD somewhat works. gdb for X.2 worked only
when chrooted in /emul/darwin. gdb for X.3 does not work, I don't know
why exactly, I did not tried to track the problem down.

Rebuilding gdb from Darwin CVS on NetBSD doesn't work: build with no
particular option, it configures itself for NetBSD and lack Mach-O
support. Built with the --enable-targets=powerpc-apple-macosx (and a lot
of tweaks), it gets Mach-O support, but it seems unable to use it on
NetBSD. 
 
> > 2) Build a gdb that understands the Mach-O format, and hope it will make
> > the work in SecurityServer easier. I tried a lot in that direction, but
> > so far I failed. It seems Mach-O support in gdb is quite bound to MacOS
> > X runtime. 
> How so, can you explain more ?

There is support for Mach-O in BFD. I can build a gdb with Mach-O
support enabled in BFD, but when I'll launch gdb against a Darwin
binary, it will complain that mach-o-be is not a valid format. 

The code that registers as being able to read a Mach-O symbol table is
in gdb/macosx, and it also contains all the Mach related stuff that is
really specific to MacOS X. It seems impossible to get the ability of
reading Mach-O without including all the Mach stuff which is unavailable
to a native NetBSD program.   

Briefly, the Mach-O support code does not seem to be written in an
OS-independent way. But I might be wrong. 

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org