Mac Forum / Programming / CodeWarrior / May 2004

Not CW's fault, but debugging XTensions has always been its own special
hell. Which is why I'm half-glad I don't do that any more. :)

dans l'article mwron-13B07D.18580518052004@news.newsguy.com, MW Ron à
mwron@metrowerks.com a écrit le 19/05/04 0:58 :

Well, when I try to debug inline code with CW 8.3, I fall into assembly. Am
I missing something ?

Same as inline. I can't see the template code like I do with Visual C++.

Say you have a base class A with a M() virtual method, and dozens of classes
which inherit from A and provide their own M. Go to Debug->Set/Clear
breakpoint. If you type M, CW complains it cannot find the method. You need
to type A::M. This is rather annoying because when you're debugging, you
often don't remember which particular classes implement M(). Again Visual
C++ provides this functionality.

Eric

You are the debugger vendor, we are the customers. If CW debugger doesn't work
well with Foo plugins, it makes no difference to the customers whether it's your
fault, Foo's fault, Apple's fault, or just the way things are. The only thing
that matters to the end user is how serious MW is about addressing the problems
with the debugger  -- and whether you have to talk to Foo or someone else to do
so doesn't really make a difference to us.

Regardless whose fault it is, it's MW's reputation that suffers for it, so you
should be more proactive about getting it sorted out, IMO.

meeroh

Oh come on Ron, this is a cheap shot. Just above this thread there is
another one regarding since Filemaker is a Mach-O binary some user can
not debug its Mach-O plugins there. And I could for sure not debug
iMovie Plugins some (minor?) releases back. Please no "it must be the
fault of the host" reiterations.
Just for the records: The problems may or may not be fixed with CW v9.2
- as it just started to work for me, I had no time to do regression
tests with the problems that occured not all the time.
The XPress issues have to my knowledge been reported by multiple users
against CW8 and 9. Shall I make a poll on the developer list? As all
XTension developers are under NDA, probably none of them did provide
Metrowerks tech support with details, the only solution is Metrowerks
and Quark communicate directly. Anyway, I am pretty sure the problems
will also surface with other bundle type Plug-Ins.

Sorry, at some points we are talking about conceptual things that went
broken _looooooong_ time ago (and also reported then). Problems to debug
some CFM plugin technologies started with the Pro releases when the
debugger was migrated in the IDE. Some of the issues were never fixed
for any debugger release for CFM. E.g. that the xSym file is not closed,
even when the plugin is unloaded by its host application (that may not
quit). An missing way to detach from debugging without killing the host.
The kill button is not disabled and without visual clue even though it
takes ages to stop debugging. The buggy handling of subsequent
"inbetween" kill klicks... When those things go wrong wrong, usually a
crash is not far away.. (and there is no way to save the debugging state
manually)

And no, that is not rare functionality under esoteric circumstances. And
it were not only XPress hosted shared libraries. It were Photoshop
plugins, Quicktime components, AppleScript OSAX, MacEasyOpen converters,
FBC plugins, Codewarrior Plugins, ...

Debugging Mach-O plugins just started to be possible with the latest
release, how can you be so sure there are no more bugs and blame the
host all the time?

Should I care? I spend my time with the environment with the higher
productivity. If XCode allows me to debug, I use XCode.

Regards,
  Tom_E