WWDC2000 Session 196

Transcript

Kind: captions
Language: en
good morning it's Friday morning how
many people are awake it's great to see
such a good sized crowd here in the last
day of the conference I hope we have
hope you have a good day today we have a
great show this morning I'd like to
bring on Dave Payne - the manager of
developer tool application group and
he's going to talk about the debugging
[Applause]
thanks Kathy
so Joe enjoy our campus last night nice
place isn't it
all right so lots of cover this morning
let's go ahead and get started what
we're going to cover today is an
overview of debugging on Mac OS 10 in
general and there's a variety of ways to
go about it we have two integrated
development environments at this point
project builder and code warrior so
we'll be taking a look at debugging with
both of those first off we'll dive into
project builder take a look at some more
detailed stuff than I did in my sessions
on Wednesday then we'll take a look at
some advanced debugging techniques that
really getting down and dirty with gdb
the command-line debugger then bring
metro works on stage to take a look at
debugging in code warrior pro six so
really which of these that you use
depends on what you're building on Mac
OS 10 there's there's a lot of different
pieces of software that you can build
and how you debug it depends on how you
built it you can't build the same things
with the various sets of tools at the
moment so there are different debugging
techniques depending on what you're
doing so let's first talk about the
overall debugging architecture both
apple and metro works have worked
together to come up with mechanisms that
will work with the system both project
builder and code warrior do take
advantage of gdb as they calm
debugging services substrate gdb handles
all the interaction with the core OS and
the interaction with your target
application in the case of project
builder we talked pretty directly to it
on Mac OS 10 itself in the case of code
warrior Apple and Metro works worked
together to design a mechanism to allow
the code warrior IDE to work with
debugging just as it always has
specifically it's taking advantage of
the Metalworks debugging protocol to go
through and talk to a debug knob that we
worked on together the debug knob
handles communication to gdb so the
debug knob runs on the Mac OS 10 machine
with gdb and with your target
application because it's going through
the Metro works it's actually the remote
debugging protocol code warrior can work
on Mac OS 9 or Mac OS 10 and do
debugging of applications there but
again which one you use depends on what
you're building
so with carbon applications you can
build them as either Mac o or with path
for all allows from the system Mach o is
the primary binary format for the system
it's the native floormats
it's what we use for everything so we've
built the EOS with that since
essentially the dawn of time from the
base that we developed it from that
could next so all of our tools are
optimized for that from the development
tools on through the performance tools
so you can get access to the entire
system by making Macchio applications so
all the bsd api's are accessible all of
your frameworks so cocoa all of the
carbon frameworks are actually
implemented as maca frameworks on the
system you can do so you can write all
different types of applications as Marco
if you're writing say an i/o kit module
so a device driver or kernel
tenshun you would do that in Moscow as
well you can use mock o in a test
application by doing a mock au plug in C
F plug-in that loads transparently you
don't have to know that it's mock oh
really
so the new project builder IDE fully
supports development with mock o gdb
supports debugging of that metro works
will be working to provide a full mock o
development suite as well so you'll have
that option as well in a future release
of metro works your other option for
carbon binaries is to develop a path
binary that's the native format on Mac
OS 9 we've provided a code fragment
manager
it's load paths containers on Mac OS 10
to provide transitional support for
carbon applications coming in you can
have one of these path binders can
actually run on both Mac OS 9 or Mac OS
our preference actually is that you use
the new bundle packaging scheme to come
up with an app package that you could
take advantage of localization and
everything else from the app package you
can have a mock Oh binary for Mac OS 10
and app F binary for Mac OS 9 and be
double clickable on each but path alone
is an acceptable option to do that today
you would use code warrior to do that so
Metro Works has provided full debugging
support for code warrior binaries
running on carbon test binaries running
on Mac OS 10
so again Metro Works is also working to
provide ma Co functionality and in my
project builder session on Wednesday we
also demonstrated kind of a bleeding
edge functionality of generating a
binary from the project builder IDE as
well so we're trying to move in that
direction the goal is that both
environments provide all options and
give you as much choice as possible so
with that introduction I'd like to bring
on
rat Hagee debugging engineer for project
builder and he'll take you through some
of the project builder debugging details
thank you good morning everyone
I'll be talking about project builder
and debugging on Mac OS 10 and some of
the larger issues that you might run
into specific to Mac OS 10 project
builder has a number of features for
debugging the most obvious of which is a
graphical user interface for displaying
threads and stacks and such in addition
we have features for supporting the
so-called Mac OS 10 platform initiatives
mainly carbon and its use of opaque data
types and the semantics of the Mac OS 10
dynamic shared library mechanism because
we encourage the use of frameworks and
shared libraries project builder
supports cross project debugging where
one project can have can build the
framework for another project can use it
and then finally you know we have a full
breakpoint support so we'll be talking
about each of these in turn and first
let's start off with opaque data types
now if you if you looked at carbon or
core foundation you know that many of
the data types all you get is a
reference you don't know what the actual
structure of the data type is and it as
a developer you can appreciate the
advantages to hiding your implementation
so you can change it later on but it's
also difficult to debug without paying
data types or abstract data types
because you can't you can't look into
them so how how can we debug these in
the Mac os10 environment well we have to
change our approach a little bit
typically a debugger reaches in and
looks at the state of data structures
but it can't
that with opaque data types so what we
can do is we can take advantage of the
debugging system on Mac os10 and run
functions during the debugging session
inside the debug process and these
functions can inspect and provide
information about the state of these
data types principle one in core
foundation is CF show which gives a text
textual representation of the CF data
types dictionaries and strings and so
forth in Carvin there are a number of
functions specifically there for
debugging many of them take as a
parameter a data type such as a dialog a
menu or a window and print out
information some just print out
information about the application as a
whole like print resource chain prints
all the information about the resources
active at the moment and then they're
selling the quick-draw framework that
instead of providing the textual
information provides a graphical
information such as flashing a clip
region or visible region which actually
is a lot easier than looking at the
numbers representing pixel positions
so now let's talk a bit about shared
libraries and and we use the term
dynamic shared libraries or Die libs on
Mac OS 10 to emphasize the specific
semantics of shared libraries on Mac OS
10 they come in well we say two types
but it's more of two ways of
representing on the filesystem a
standalone shared library or a shared
library packaged inside a framework and
if you work with shared libraries you
know that if you have multiple versions
of them on your system and you start
running your application and debugging
with the wrong version you can waste a
lot of time till you come to that
realization so how do we how do we avoid
this problem the general question we
want to explore than our Mac os10
shared libraries and frameworks are
designed to be installed at a specific
location and and how do you do
development when you when you don't want
to install them so let's look at the
details of how this process works at at
Build time when you build your shared
library part of your configuration
information you give to the build system
and project builder is the path where
you're going to install the framework
with a shared library and that path is
independent of where you actually build
it at Build time of the executable the
static link editor LD takes this install
path from the shared library and records
it in the executable so that at runtime
for the executable the dynamic editor
then has a very easy way to find the
shared library it's been told here's the
path where to look for it so that's very
efficient but during development there
are a couple reasons why you wouldn't
want to install your shared library or
framework
the first is as a as a developer you're
probably running as your own user user
ID with permissions that don't allow you
to actually install or modify files
inside the file system usually that's
done as route or administrator the
second reason you may not be able to
install a shared library is well you've
already got one there you've got a
stable version of your system and you as
a developer want to develop move forward
on your own set of code and therefore
you want to develop and run and compile
with your own copy of the shared library
so at the lowest level here's how we can
address this there what various
environment variables that control the
how the dynamic link editor D yld
accesses and find shared libraries and
if you do end up using these I you
should consult the manual page mandy yld
and find out all you can do with the
dynamic link editor if you're also going
to Mac hack it's a might provide some
interesting tips if you do do this be
sure to be aware of the gdb command info
shared libraries which prints out all
the shared libraries used by the debug
process once again we're just trying to
save you time from debugging the wrong
theme if you use project builder we take
care of all this for you so that you can
just build your project and click the
Run button or the debug button and we
run with the right versions and we'll go
into detail about how to set up project
builder to do that as a heads up coming
down the road you know we're really
encouraging using the app packaging
model and one of the things we plan to
put into the package our private
frameworks used by the application we're
not quite there yet but the
tenses you can the application will be
completely self-contained now that if
you put your shared library inside a
framework inside the packaging's it not
only do you get the advantages of the
framework being able to put your header
files there and so forth but we also
have the ability to put more than one
copy of a shared library inside the
framework typically this is these are
binary files or the shared libraries are
the implement the same set of api
they're the same version but they're
just compiled differently with different
options tailored towards specific
operations you might want to do so the
standard version of a shared library is
optimized code minimal symbols that's
what's used at runtime and for
deployment the debug version is tailored
towards the development process and
doing this runtime error checking its
core foundation and carbon do extra
checking of parameters they can do
internal state checking to ensure
consistency that the api's are used
correctly and finally there's a profiled
version which is used with the G proof
profiling system again the low-level
environment variable that controls this
is vylv image suffix but project builder
allows you to access these directly all
right so now we'll talk a bit more in
detail about project builder itself go
over how to configure things great
points and then we'll have a demo as
we've said project builder enables cross
project debugging and to do that you
need to build your projects and it's
specifically the products of your
project and have them put in a common
location so that we can find them at
all time and at runtime and we'll go
over and the demo how to do that we use
the term executable for the thing that
you're going to debug it can be right
now it's a binary it can eventually be
Java or it could be some other kind of
program and you can set various settings
on the executable such as the arguments
essentially the command-line arguments
are being our key passed to the program
at launch you can also control choosing
the debugger and such just to go over a
few things about breakpoints project
builder has course standard breakpoints
and files at specific locations there
are also ways to set breakpoints on
functions just via the name of the
function symbolically and that's useful
if you want to break inside a library
function such as carbon and see why this
functions being called and what the
stack back-trace is we have a summary of
all the breakpoints in your project and
the keyword is here they're your
breakpoints and each member of the
development team has his his or her own
set of breakpoints that are stored
independently but persistently so now
I'd like to bring up debuting who's
going to help me with the there is the
demo they've worked on our Java debugger
[Applause]
all right if we could have all right
demo 3 I first let's look at the
preferences the bill preferences in
project builder and the key here is just
one to show you that there are two
settings which are filesystem paths
which are where you build and this is
very important to set for cross project
debugging and runtime runtime settings
so we can find your frameworks okay
now let's look at the target tab target
has many settings and a target logically
has an executable or a set of
executables and you can add your own if
your if your project builds a build a
library or if you're working with a
legacy project so-called that uses the
make system it's the open source project
you can you can point project builder to
the executable you want to run down at
the bottom you can see three tabs that
control the settings for the executable
arguments let's go to debugger just
quickly we know most cases what debugger
to use their various corner cases if
you're debugging Java and you've got
native code and you want to use the GDB
GDB debugger that's what you you come
here and select that and then there's a
runtime tab I should mention that this
version project builders host VP for the
runtime tab isn't on there but gives you
an idea we can now select which variants
of the system frame system framework to
use standard debugger profile and all
right so let's go back to the arguments
tab great and we've added some arguments
there and let's select the trace and
crash option or and we'll run with it
this is a parent sample it's a standard
example we've just added a few features
to look at these arguments if you see we
go to the slider and just move the
slider a little bit we're printing out
the value of the slider the trace option
controls that and if we move the slider
all the way to the left we up it's too
big and we've crashed just to note how
to read the output here it says there
your program is exited with a signal
that's the unix way of saying there was
an
in an error in this case a bus error
which means we've referenced some memory
that we shouldn't have all right
let's quickly look at the breakpoints
tab just so you know list the
breakpoints in a file if you double
click on it it'll take you to the file
and show you the breakpoint good way to
navigate breakpoints in project builder
can be enabled or disabled a disabled
breakpoint remains in your persistence
set of breakpoints but it's not used by
the debugger it's a good way to keep
breakpoints around but not trip over
them every time all right now let's fire
up the debugger make it a little bigger
and we move the slider this time should
trap on the breakpoint
get a list of threads and the stack
we're in and variables alright let's
step just a little bit to show you up oh
oh can you close up the console Dave so
we can you can see the local item value
changed now this is C++ program there's
the implicit this pointer passed to each
each method the way data is displayed
for C++ objects is each superclass or of
your it's member funk and member data is
represented as kind of a pseudo
structure that you can disclose now we
see there's a dialog pointer and if we
want to look at that we say oops we
don't have the type information for that
that's an opaque type so how would we go
about seeing what the information about
this particular dialogue so right now we
bring down the console
and we can talk to gdb directly and
Dave's going to enter the magic command
we tell gdb to call a function in the
inferior so this function is actually
going to be executed by the debug
process in its address space and gdb is
going to evaluate symbolic arguments
like f dialogue and pass essentially set
up a calling call site to call this
function and you can see now we've got
some information about the dialogue and
that's just lets do print resource
change just to show kind of some global
information that you can get from carbon
that will check you okay
all right and okay what we're running a
little short so let's just demo the
symbolic breakpoint just to show you how
that works quickly so you click new and
you get a text field to enter the name
of a function that you'd like to break
at and you can just select some text in
your code paste it in there and now if
we continue we see that we hit that and
can crawl up the stack too to find what
we want okay I think we're running a
little short on time so thanks Dave so
you can go go back to the slides please
all right just a notes about what we're
planning in the future you know project
builders are work in progress we know we
there's lots we have a large
constituency and each each group has
different needs some want low-level
someone more high level and we're we've
planning to do all that in the coming
months Dave's working on Java debugging
which coming along so later on we'll be
giving you the email lists and for
feedback and we'd really appreciate any
feedback on the debugging system and
specifically what features you like to
see in a priority order so we can get
them to you when you need them all right
now I'd like to bring up CLE Dennis
these our gdb expert
all right hi I'm cleanest and as I
mentioned I'm one of the gdb engineers
at Apple I'm here to talk a little bit
more about the role of gdb in our system
some situations where you might find it
useful to use it and sort of our plans
for its future role in system basically
the role of gdb in our system is very
simple gdb is the max bug for Mac OS 10
really fills the same roles in the
system the max bug fulfilled on Mac OS 9
our intent is it be something that's
available as a foundation for other
debugging environments and also that it
be available is something that you may
choose to use for low-level debugging
but it's our intent that it never be
something that you have to use at a top
level
so both apple and metro works are
working very hard to make good
high-level visual debugging interfaces
on top of gdb and we're certainly
working to make gdb features available
at higher levels but it's our intent
that you never have to use gdb at a
command-line level unless you choose to
do so I'm so first off I'd like to go a
little bit into why we chose gdb as the
foundation for our debugging system
first off
gdb is a very good low-level Unix
debugger in the UNIX world it's
basically the standard low-level
debugger it's been around for over a
decade it's very stable
it's very mature and it's got a huge
developer base so I'm not just with an
apple but throughout the entire UNIX
community it's also a very extensible
debugger it's got a very configurable
command language it's got the ability to
support plugins and since it's open
source it's got the ability to add new
command to features whenever you might
need them and finally it's got a good
foundation to support building
higher-level debuggers on top of it so
it's got a good programmatic API and
it's got a good way to enable other
programs to talk to gdb in a way that
can be managed from other programs
without having to make you to be visible
at the top level that said what I'm
going to be talking about a little bit
is some
seasons you might choose to use GDB from
the command line today and as I said it
before it's our intent to make every one
of these features available from a
graphical basis such that you don't need
to use it from the command line but
recognize that there's some of you who
will need to get some of these features
used today and so I want to show you
just very briefly some of the things
that you can do with gdb at a command
level I'm in the short term
some of the features we're going to be
showing you are the expression evaluator
which basically gives you AC interpreter
or C++ interpreter or an objective-c
interpreter at the command line script
ability which lets you extend gdb to
provide various new features some more
traditional features like conditional
breakpoints adding commands to
breakpoints and finally I should mention
that gdb is what you will be using if
you're doing kernel level bugging
because it supports our remote debugging
interface and I'm sure we'll be doing
graphical interfaces to that as well so
I'm going to go straight into a demo of
this I'm going to be moving kind of fast
I don't expect that you will want to
keep track of every last command that's
being typed this is more to give you a
taste of the sort of things you can do
we've got full documentation on the
system and the standard locations I'd
recommend that in particular I'd
recommend there's a one-page PDF
reference card that I think can be very
helpful so with that I will switch to
Dave the first thing I'm going to be
showing and I hope you'll excuse my
notes I want to make sure I stay in sync
is the use of gdb as a max bug
equivalent everybody see that the other
texts per typically the people in the
back just wave if you can all right
so we're going is we're going to fire up
gdb and we're going to attach it to the
finder basically the same way you might
drop into Mac's bug to look at the
finder I don't know why it's called
desktop but there you have it
and once it's connected we're going to
go ahead and set a breakpoint in open
which is a UNIX system call for opening
a file and we're going to go ahead and
continue to finder
and David's going to do something to
cause it open a file and you'll see over
in the command window the Finder has
stopped and open we're going to take a
look around sort of snoop of it to see
where we are maybe get a back-trace so
you can see we've gone through some
chain and via C++ calls so I wouldn't
even dream of understanding we're going
to take a look at our registers take a
look at our list of threads basically
any information you might want about the
process is there I'm not going to go
through the whole list of commands but
there's a ton of them you can more
interestingly give it some expressions
to look at so you might want to oh I
guess first we'll be looking at the what
nasal finish you can give it commands to
apply to all commands so in this case
we've gotten a back-trace of all of the
threads or you might want to just give
it expression so you might want to just
tell it to print the contents of
register 3 don't give it to use an
integer which isn't very useful so you
might tell it's printed in hex which
really still isn't all that useful what
you really want to do is cast it to a
car star and take a look at it that way
and I'm not going to go too far into the
expression or basically anything that's
illegal see expression is also an
expression that you can type here
including function calls commas anything
you feel like as long as it's not a
statement you're good to go
what I'm going to do a little bit more
interesting let's say I want to see all
files that have been opened by this
program so I'm going to set a command on
this break point and what I'm gonna do
is I'm gonna tell it first to not print
the break point line every time then I'm
going to tell it to print the first
argument I just happen to know is our
three still and then I'm going to tell
it to just go ahead and continue without
stopping for me and now when I continue
I can see all the files and all their
gory details it's being opened this is
interesting also just because it's
highly scriptable so if you need to get
output logs or in some other capacity
you can do that you'll notice a lot of
those files are not all that meaningful
they're basically in an artifact of our
HFS implementation in this case what I'd
like to do is just focus on the P list
on our property list files so let's add
a condition to the breakpoint that lets
us filter out everything that does not
end in dot P list so if we're just
interested to see which files that n NP
lists are getting opened we can actually
attach a condition in this case we're
just going to take our 3 and we're going
to string compare it with that P list
and if that expression doesn't evaluate
true in this case if it doesn't end in P
list it's going to just skip that great
point entirely and so now when we
continue
now we just see the plist that are being
loaded by the system so thank you and
certainly you can come up with more more
elaborate examples I'm sure everybody
will have their own things that they
might want to do with that and really
what this leads into is how to extend
gdb and so as I mentioned before gdb has
a configuration language it's used by
our system to configure gdb with
specific user interface things but it's
also something that you can use on your
own to extend gdb so what I'm going to
be showing is basically a small
profiling library that we basically I
had to add to gdb one night about three
in the morning I was desperate to figure
out a program a profiling problem
desperate to get something to speed up
and I just really needed to know how
long individual source lines in my
program were taking to execute so I
gende up a little tiny program you know
as most of that's documentation that
defines two commands one is mark which
sets a stopwatch for CPU time and the
other is curve which tells you how much
CPU time you've used since the last time
you typed mark basically it just calls
the guitar usage function in the system
to tell you how much CPU time has been
used and so we're going to take a look
at a small program that I rigged up it's
just basically allocate 64 Mag of memory
and zeros at two different ways one way
is the slow way the other way is the
fast way it's not very interesting
program but when we take a look at it
he's just going to load the I profiling
library so we take a look at name one
more you'll see it makes a little makes
a big buffer zeroes it the fast way if
you can list that
and then lists zeros at this low egg and
when we will find is that when we run
this I'm sorry I might love a breakpoint
thank you
it'd be very good we run this we're
going to step forward to where we want
to end up in step two right before the
fast zero we're going to set a mark
we're going to step over fast zero
step over fat zero we're going to
allocate sixty-four Meg and then we're
going to type curve to see how long that
took it should take about half a second
now we're going to reset the mark we're
going to step over the next line and
this one I'm guessing will take about
two seconds so you know you can just
step right through your program see how
long each individual function is taking
real visual way of finding the
bottlenecks and what's interesting about
this isn't so much it uses a profiling
tool though really saved my butt one
Sunday night it's that it's something
that you're able to rig up with very
little effort just by adding a few
commands to gdb and I'm sure many of you
will find interesting ways to expand gdb
in ways appropriate to what you're
working on you know one thing that
surprised me just before we were putting
vp4 out was one of our support engineers
send us email saying hey I really missed
all those Mac's bugs commands so I
rigged up a quick Mac's bug
compatibility library
and so you know I gave it a try and I
even I tried actually many of the Mex
books and most of Mac's voice commands
that I knew and discover actually a good
number of them work and again you know
it's not so much the commands as the
fact that you can add these things
pretty much however you might like so
with that I will turn the stage back
over to Dave and thank you very much all
right thanks Klee thanks Dave
thanks Rob so we hope what you've seen
here is that underlying the system here
we've got a very powerful command-line
debugger we weren't trying to scare you
with a lot of the low-level you know
skank eNOS we were typing in here but
more intending to show that the power is
there this is an open-source debugger so
if I believe that the sources aren't
already in Darwin they're going to be
and available through other means as
well but we have intent to provide a lot
of this functionality through the new
project builder interface for those of
you who haven't previously heard about
this and with previous developer preview
releases we had a project builder on the
system that wasn't really sufficient to
meet our needs so we've completely
rewritten it from scratch for DP for
what you're seeing here in DP 4 is the
first release that we've done of this I
think that given that that's the first
release we've shown quite incredible
progress over the past year and a half
that we've been developing that and I
have strong confidence and team that
we'll be able to get a lot more features
in very quickly at the GUI levels to
bring a lot of this underlying power out
so again as I said in my earlier
sessions we'd really like to deliver on
our commitment to great development
tools and I think we're well on the way
to doing so there's reams of features
that we could bring out in the debugger
and we'd like to know what's top
priority for you I expect to glit get
some conflicting demands and so I
really want to hear and sort of what
what's the biggest things for the most
people so various ways that you can give
us feedback on this we've put in place
the public email list for project
builder I checked this out last night it
is online at this point so in the way in
the area that lists addresses are set up
for Apple project builder - users at
public that list Apple comm that for the
community to discuss project builders
usage feedback that gets directly back
to us this is the great place to send me
and the team requests is the Mac os10 -
tools - feedback at group apple.com
address for support with project builder
there's also the DTS site and email is
there and as we talked about project
builder will be available through the
quarterly tool CDs - Apple Developer
connection program members updates will
also be available on the web we haven't
done one of these yet so I'm sure there
will be a few logistics to work out for
that and with that I'd like to now turn
the stage over to our colleagues from
metro works specifically can rile the
lead engineer on debugging at metro
works okay
well if you're here at our session last
year we talked about debugging on Mac OS
10 and at that point Apple it helped us
put together debug note lettuce debug
remotely from a Mac OS 9 machine to Mac
OS 10 and we've been busy since then
working bringing code warrior to the Mac
OS 10 and so today I'd like to talk a
little bit about what we've got now this
is all on a beta CD of the pro six tools
we've been handing out here at the show
the actual tools we'll ship later this
year but the CD has tools that you can
start now building and debugging
applications on Mac OS 10
so what's what's really new in these
tools is that the IDE is fully
carbonized it runs natively on Mac OS 10
you can do single machine debugging so
you can take all of the the carbon caps
even running on nine carbonize them and
use the same same debug around 10
debugging on 9 we've also done a lot
more work into machine debugging for
this release we've before we did nine to
nine debugging and we also did debugging
from 9 to 10 but we flushed that out now
so you can really do four-way debugging
for Mac OS 9 to Mac OS 9 from 9 to 10
from 10 to 9 and also from 10 to 10 so
you'll have a lot of options based on
what your host and target platforms are
and as they've talked about the metrics
tools right now build carving tap
legations for Mac OS 10 our ma Co tools
are in development and you'll see those
in later releases right now these are
designed to transition your carbon pet
fats that you've been building online
and bring them to 10 and let you let you
debug them the same way so with that
I'll go through a demo and show you what
you can do with the tools that are on
the pro pro 6 CD first thing I'm going
to do is start a debug nub debug nub is
the piece of debugging technology that
Dave and clay and his team collaborated
on with Metro works to provide a link
between the code warrior
protocols of gdb it with the tools on
the CD you have to start debugging uh
manually but if you'll be sure and sign
up the beta program in future releases
will do this for you automatically so
you'll have the same seamless debugging
experience you have on 9 so now I'll
start the IDE and open up a power plant
sample now if any of you have tried to
use the 2 machine debugger that we
shipped with a 5.3 tools I'll show you
you a couple differences doing remote
debugging the user interface for setting
up remote debugging could be kind of
complicated with those tools and wasn't
very straightforward so we've done a lot
of work on that now you can create a
whole set of address book style remote
connection preferences where you can
name specific remote connections pick
the debugger you're going to use and
then enter the specific IP address for
them so after you create a connection
type in the remote connections panel you
can go to your projects target settings
and tell it specifically you can enable
remote debugging until it's specifically
which connection type you're going to
work with also specify the remote
download path which if you're debugging
on Mac OS 10 needs to be a UNIX tile
path and also tell the debugger to
launcher in the post application if your
remote debugging the shared library but
for this demo I'm going to show single
machine debugging so I'll leave that
turned off
and go to the go to the power plant
sample let's get the debugging
so it's doing now is launching your
carbon pepper app and stopping at the
first breakpoint so at this point you're
in the same code warrior debugger that
you've been using o.9 you can do all the
normal things step set breakpoints look
at the variables look at it registers
processes all the same user interfaces
here available TV and breakpoints run
for those and then continue running we
have our power plant appearance
application
and I'll find the source that creates a
new window set a breakpoint here and
then we stopped at that breakpoint
so as you can see here they're not I'm
going to not going to try and demo all
the debugger features in code warrior
because you're probably familiar with
them early hour news here is just that
all those same features are available
natively on Mac OS 10 for single machine
debugging
so that's really that's really the
demonstration that all the same things
you've been used to doing on 9 to now
work on 10 and code Warrior we're also
in the teacher working with Apple to
provide an interface to some of the
advanced gdb features that came out and
talked about so we'll be extending the
code we're debugging support on 10 let
you do some of the things that GTV makes
possible in 10 that weren't really we're
really very easy to do on 9 so we'll be
will be extending the user interface let
you do those things from inside code
warrior as well well that's it for the
code warrior demo again all of the tools
I showed you here available on the pro 6
beta CD and that's that's been available
to people we've been at our sessions
we've been handing those out at the show
and again please get in the beta program
because we'll have new releases over the
summer that add additional debugging
support for Mac OS 10 and just sort of
polish up the the pro six tools and be
sure and also send your feedback to to
the web or web site and instant that to
us through the beta program and now
here's Godfrey again Thursday guys 410
thank you very much Ken ok so this is a
this is just a slot giving you some
contact I repeat the developer tools
group email address so you can contact
us with feedback and your and your ideas
you can always contact me as the
technology manager for development tools
at Apple and Ken rile the core
engineering core debugger engineering
lead at the Metro works and with that we
have one more session in the tools track
right immediately after this one in
Hulsey we have a feedback form for the
apple developer tools hope to see a good
number of you there ok with that we can
bring the house lights up and start QA
can I ask our presenters to come up on
stage