WWDC2001 Session 706

Transcript

Kind: captions
Language: en
good morning it's Friday morning have a
good time
last night great okay we have a rather
full schedule for you today so I'm not
going to take any time one thing I will
remind you is that we have a feedback
forum this afternoon I also tell you
that at the end of the session so we'd
like as many of you as possible to show
up for that and without further ado let
me introduce Dave Payne the manager of
our developer applications team good
morning I had a good time at the party
last night so what we're going to take a
look at today is mostly concentrating on
debugging with project builder for both
C based languages and for Java we'll
also be getting into some advanced
debugging situations with gdb but before
we really dive down into that we'll also
take a look at how to look at
applications to just crash on your
system or if they're hung what can you
do about that so let's just dive right
in with that
so on Mac OS seven eight-nine previously
you're familiar with an application
crashes you can have Mac's bug installed
on your screen on your system and you'll
crash and catch the crashes in Mac's bug
we do now have a facility in Mac OS 10
to catch crashes and give you stacked
packed races and things like that in
order to enable this you have to go in
as an admin user and add a configuration
line to the etcetra host config file so
the facility is called crash reporter
and if you go in and set crash reporter
equals - yes - which is the format that
all those lines are in then you'll
automatically get this facility turned
on so what happens then if you were
running the console application it'll
ask you hey an application just crashed
do you want to see the stack back trace
at this point or the crash log yes or no
a little dialogue that pops up there and
say yes then it brings console to the
foreground
you've got the console window but now
you've also got a crash log window as
well that shows you the stack back trace
for all the threads in your application
and it shows you the register state if
you want to look at this sometime you
know from terminal outside of the
console application the file is actually
kept in the slash var slash VM crash log
so one thing to be aware of those it
just appends the crash information to
the bottom of this file and it retains
that across reboots so you can have a
week's worth of crashes stored in your
file there and you fire it up and huh
this I thought we fixed that one
well that's cuz you're looking at the
start of the file so you may need to
clean it out on occasion but that can be
a really useful facility you can then
have people you know if you've got beta
testers or whatever they can enable this
on their systems and send the back
traces back to you actually if I could
have a quick poll of the audience I'm
considering just automatically enabling
this when we install the developer tools
CDs what do you think of that ok we'll
try and do that the next time around
then yeah that's not happening this time
on your CD but you can do this yourself
so another one is G my app is just
hanging what's up with that how can I
take a look at that I've been running it
is there anything I can see well in some
of the sessions you've seen the sampler
graphical application for doing CPU
monitoring profiling what's going on
there's also a command line version of
that called sample from the command line
you would X in a terminal you could
execute sample and then the process ID
and it also understands just the name of
your binary as well if there's only one
copy of it running and then just the
number of seconds that you want to
sample so I typically say sample
might an app for 10 seconds it tells you
where it puts the file into slash temp
and then you can go off and take a look
at again the stack back traces to see
where your app is spending its time
again that can be a very useful thing
that you could have people send the
samples back to you if you do perchance
ever happen to find any bugs in any of
our stuff it's helpful to attach these
crash logs or these sample outputs into
any bug reports or emails that you would
send in to us to tell us what you might
have found with our code as well there's
also a facility with gdb where you can
attach to a process and if you've got
source code for it then even though you
didn't start it up under the debugger
you can attach to it later we don't have
that wired in through project builder at
this point but you can do this you'll
see usages of gdb attached later in the
session so many of you are familiar with
some of the debugging facilities of
project builder it's full graphical
debugging for sea-based languages so C
Objective C C++ and Sam inspires me to
say objective C++ that will be supported
there too and also Java we support all
the different types of Maca binaries
that you've got on your system and we'll
see how to do that through the course of
the session for the C based languages
we'd use gdb as the low-level debugger
or to communicate with the OS
architectural II this is what it looks
like here as project builder
communicates with GDB GDB handles all
the complexity of working with the
operating system so the unix p trace and
mock exceptions and your target
application it's a fairly complex
interaction so that takes care of all
that for us because that is fairly
complex we also work with the Metro
Works folks to get the code warrior
debugging working well as well by hand
handling same level of interaction and
then using a debugging protocol
as if you're using code warrior at all
you may have heard that they no longer
require the use of the debug knob it's
that aspect of it is built directly in
the code warrior now but at the lower
levels we share the same facilities so
without further ado I'd like to bring
out Rab Hagee senior engineer on the
project builder team to actually show
you project builder debugging in Ursus
alright thanks Rob thanks Dave all right
good morning everyone in this section of
a our presentation today I'll be giving
you a bit of a status on where we stand
with the bugging with project builder
talk about the how to configure your
project for debugging the how where in
what of setting up your project talk a
bit about breakpoints and then my
colleague Dave Ewing will come up and
talk about debugging Java all right if
you're new to Mac OS 10 and the project
builder welcome I hope you've seen
through the other sessions at the
conference that we have a full-featured
IDE and with respect to debugging we
have a nice GUI for showing the threads
stacks and variables in in stack frames
and are we have a full-featured
breakpoint model and a support for
debugging multiple projects if you've
been with us for a while the changes
from last year last year's conference
you won't see too many changes at the
user interface level we've been
concentrating on improving the
infrastructure so we have much better
C++ support we've been tracking changes
to Mac OS 10 and we've improved the way
project builder communicates with the
underlying debugger and of course last
year we showed just a demo or technology
demonstration where Java debugging and
now that's a fully part of the ID
as I said we've been concentrating on
infrastructure so we still have a lot
more to do in terms of features and
making common operations a little more
easy and efficient for you to get to and
we've gotten lots of good feedback from
the project builders users email list so
thanks for that yeah alright let's talk
about the how of building for debugging
with this release of project builder
we've introduced build styles which were
covered in detail in the project builder
in-depth session bill styles allow you
to configure a single target from
multiple uses and by out of
out-of-the-box you get to build styles
one called development and one for
deployment and we encourage you to set
up your development build style for
tailored towards the bugging and your
day-to-day development and use the
deployment build style for when you were
getting ready to actually build your
product for shipping now the the two key
aspects of the build style in building
four related to debugging are the
compiler settings for optimization and
generation of debugging symbols so
naturally to do full source level
debugging you need to to ensure that you
in fact have are telling the compiler to
generate symbols and you can also cherry
the optimization level now just because
you can mix generation of symbols and
optimization you need to be aware that
at the higher levels of optimization the
mapping that the the symbol information
provides a mapping from the Machine
state to the logical state in your
source code in that mapping begins to
break down at higher levels of
optimisations so we recommend for
debugging either no optimization or
optimization level one and I'll give you
a in our demo I'll cover that a bit more
all right here's a quick look at the
user interface for the target build
settings just so you can get oriented
I've highlighted the pop up for the
development optimization level and down
below the checkbox for including
debugger symbols all right now let's
talk about the wear of building your
project out of the box by default
project builder builds each project in
its own build folder which contains the
intermediate results of the build and
the final product of the build so here
we have a project that builds in its own
build folder and a framework project
that builds in its own build folder now
most projects that you'll be working
with are larger ones and you'll probably
have multiple project builder projects
and this in that case when you have a
set of related projects that you want to
build and debug together the the default
is not suitable so what we recommend is
that you create a what we call a common
build folder on your on your system and
then you need to configure each project
to build in that folder and this is a
per user setting so each user on the
development team needs to configure his
or her instance of the project to point
to a common build folder it's a little
tricky to find where the setting is you
select the top-level item in the groups
and file view which represents the
project and then use the project show
info menu all right so now we talked
about how to build where to build let's
talk about what gets built
project builder has an abstraction
called an executable which is the
program which is run or debugged and
it's related to a target so as you
change the target different targets the
executable that run that would be run
follows that target implicitly or I
should say certain target types ones
that create binaries that can be run by
the system implicitly create and
executable in project builder so most
cases for your application and tools you
don't have to do anything but we've had
lots of requests there in questions
about well how do i do bug a plugin or a
shared library and to do that you can
add an external program that's outside
of the realm of your project builder
project you can add make an executable
that points to that program and then you
can run the debugger on that program and
that program will load your plugin and
I'll give you a demo of that in a bit
executables hold the persistent state
that you set of the program kind of the
environment of the program that because
commonly when you're debugging you want
to run it multiple times and it's
convenient to set up command-line
arguments and environment variables that
can control how your programs run
another aspect of executables is you can
set at runtime which variant of the
Apple standard system libraries are
system frameworks which variant is used
the standard variant which all apps that
are launched from finder use is has
minimal symbol information a high level
of optimization the debug variant can do
additional error checking it can do
consistency checking within the library
to try
tell you of problems before they arise
and for example
corefoundation provides a lot of verbose
output and error checking that might be
useful and finally there's a profile
variant for using for use with the G Pro
profiling system here's a screen shot
just to get you oriented on the
executable setting you can see on the
Left we've selected a target and then
gone to the executables tab there's the
add button for adding an external
executable and I've highlighted the
runtime runtime tab to show you how to
change the library variant okay now just
a quick note about breakpoints we have
two kinds of breakpoints in project
builder file into breakpoints that you
set when you're editing or looking at
source code you can click to the left of
the source code and instead of
breakpoint in a particular line in the
file and symbolic breakpoints where you
enter the name of a function that you
want the debugger to stop at when that
when that function is first executed and
this is a good way of working
stopping in functions for which you
don't have the source code all right now
I'm going to give you a quick demo of
debugging
I'm going to demonstrate a debugging a
plugin this is a palette that goes into
interface builder
that's what interface builder calls its
plugins and this palette is on as an
example in developer examples interface
builder progress view palette and it
just it's a UI control for representing
a progress view just a little
demonstration of how to write a palette
for IB
let's do quick a quick tour of project
builder as what's related to debugging
up here we have the debug tab contains
the output of the previous runs so you
can refer to it later this is a pop-up
for the list of threads we know we're
not running anything stack frames and
variables here the control buttons that
get enabled when we're actually running
and we have a breakpoint summary tab to
show you all the breakpoints in your
project and let's add a new symbolic
breakpoint so you click there and you
need to enter the name of the function
for Objective C programmers it's
sometimes handy to break on Innes
exception raised so you know if an
exception gets raised inside your
program and go back alright one let me
show you one thing we have done a few
changes in the user interface we've
added a second little tab up here for
the output of the running programs
standard input and output and that
appears up here if you need if you're
working at the tool can
to level and you want to type something
at your program while you're running you
would bring this down and type in there
and we've added a few preferences to let
you set the fonts and font color for
everything and due to popular demand you
can set the color of the highlighting of
the current line so I'll change that to
a nice shade of blue or something
ah and before we start running this
program let's look at its target which
builds this is a plug-in and one of the
problems you'll have working with
plugins is you build them in project
builder and now you're the program you
want to to run looks for plugins in
specific locations so how do you get
your plug-in into that location well
they're there two approaches a UNIX
low-level kind of hacky approach that
works very well as you go to the
directory or the folder where the
plug-in or where the containing
application is expects to find your
plug-in and you use a symbolic link to
point back to your build directory and
your built plug-in another approach is
to use I've just taken a standard set of
build phases and that builds our plug-in
and added a shell script build phase
that copies are built plug-in into the
directory where in this case interface
builder we'll be looking for it on the
build settings for the compiler we've
set optimization level 1 we'll see what
that does
and right now you'll notice that the run
and debug icons are not highlighted
that's because we don't have an
executable so I'm going to add in crawl
around and
in developer applications interface
builder and now our icons are
highlighted I'm going to add an
environment variable it's called you
long and this is a good way to take your
code when you're doing development you
want it to be a little more of a robust
tell you what's going on so I've put in
an environment variable that will cause
this example to do a little logging
generate some status information so
let's see we've got a breakpoint so
let's start up the debugger and give
interface builder a minute to start up
it's got to find all its plugins on the
system it comes up we'll create just an
empty window drag in our little progress
view control and now when I click on
this inner region where where the actual
progress indicator will be drawn see
over here this inspector has come up
tailored towards that this means that
this is our plug-in running now putting
up its own custom inspector so if I type
in some code to change the increment we
hit a breakpoint now we're in our code
executing in the context of this plug-in
or in the context of another application
when it's as we step along you can see
that in this case we assigned value to F
and as variables change their values you
can they show up in red will step over
this you can see we were asking the
environment do we have this environment
variable yes we do because we're doing
development we'll step along that and we
can see that msg our message we're going
to print out as
assigned the folks it Oh Riley's say
they've sold out of all of the cocoa
learning cocoa books so if you're new to
cocoa with respect to debugging you need
to know that many cocoa objects are
opaque they if you inspect them in the
view here you use may be see just that
the fact that it has an is a pointer
that's a pointer to a class but that's
all you can see so how do you determine
what your cocoa object is well we can
use the power of gdb to send a message
to this object ask it to generate a
string description of what it is and
then convert that description to
something that can be displayed in gdb
so we use the print object command or
Pio the name of the object and that's
actually invoking code in the inferior
running that code and returning that
into genie into our console here and
fortunately we have the string we've
just set up here current increment is 5
all right so step along we call NS log
the output of the log which is going to
the do the in this case interface
builder standard out or standard error
shows up in our log we've set it up to
have a different font or a different
color that can be useful let's step
along and now I just want to show you a
few things about debugging optimized
code that's steps here you can see that
we've just assigned a value to an inter
inner variable called F and in inter
scoped a nested scope level we have we
can show variables with the same name at
different scope levels and you can also
notice that this table to this function
changed to well that's because the
optimizer was me using that register
if you look carefully at the code you
can see we declare a both an F in an eye
at the outermost scope but when we look
in the variable view we see there's only
one eye and that would correspond to
this if block and that's because the
outermost scope the eye at the outermost
cope has been optimized out so let's see
I think yeah we've got a full day so I'm
gonna stop here I hope you've got a
quick introduction to project builder
and debugging with it working with
optimized code and plugins and now let's
see if I point write like to bring up
day viewing to talk about Java debugging
all right okay well you actually just
saw most of the debugging features in
the Java debugger in project builder 2
because they are the same that you user
interface is the same it's shared
between the two so I'm gonna go through
just some differences some things you
have to do differently when you're
debugging in Java so the first thing
well the three things I'm going to show
in my slides before I do a little demo
we're setting up a project to debug in
Java and what you need to do that's
special about that what you need to do
to set up the application and it's
command-line arguments and a little bit
about Java exceptions Java has a very
nice exception model where there's a
class java.lang throwable and every
exception that you can throw has to be a
subclass of that so it actually is a
very nice very nice way to program so
setting up your project for debugging
the one thing you really don't you
really want to do for Java debugging is
turn on the indexer in future versions
will have that turned on by default but
besides giving browser information we
have a class browser coming in the next
version right now you can double click
command double click to go between
symbols and you get function pop-ups and
things like
so besides getting that when you turn on
index and you actually get build
dependency support for Java builds and
you also get a few enhancements to the
debugger support so one thing you may
not know about class files and what's
produced when you compile a Java source
file is that there's a source file name
in there and the debugger tables that
you need to for the debugger but there's
not a full path you don't know exactly
what source file that might be on the
disk and project builder can try real
hard to figure out which source file you
mean but if you have two files with the
same base file name it can't be sure if
you have indexing on we can be sure and
the other thing you get if indexing is
on and you have breakpoints set is your
debugging speed will be vastly improved
it's about 20 to 30 percent faster on a
small project in it and it only gets
better
for larger projects so okay Java
executables you can create you know a
standard Mac OS 10 application if you do
that one of the files in your project is
an EM RJ app properties file and inside
that file there's a main class setting
and that is the it's really the the name
of the class that gets run so you you
know when you create a new project
there's a default name there but you
actually may be adding sources and want
to change what that is there's also the
class path which jar files get loaded
command-line arguments actually go into
that file as well for Java tools tools
that are meant to be run from the
command line you basically give it
standard command line arguments that you
would give to the Java executable in
Java being used or been Java if you
actually have a manifest file in your
project which contains a main class
entry then you would give minus jar and
then the name of the jar file on
command-line and if you don't have a
manifest file and you would just give
the classpath for your your jar file in
the name of the main class on the
command line okay so that our debugger
does a few things to handle Java
exceptions nicely it's not all the way
there we have some UI that we want to
wrap around some of this but by default
we stop when there's an accept exception
thrown that is not caught in your code
somewhere now that's really cool but it
turns out that sometimes there's code
out there that catches these exceptions
that the debugger can't detect if
there's Java native code meaning like
code written in C they can actually
catch exceptions and the debugger has no
way to determine that ahead of time so
you actually might stop in a few places
that are a bit of a surprise so this
last point here there's some there's a
council just like a gdb console in our
debugger inside project builder and
there's a few commands that help you
take care of exceptions when you're
debugging and with that let's show a few
features that are specific to Java
well what a nice screensaver we have
okay so when I was trying to come up
with a demo here I actually had this
really teeny little demo and I think
that's kind of boring I need to do
something flashy so I went out and was
looking for a quick time for Java demo
and I couldn't really find anything all
of them have little teeny pictures and
kind of boring so instead of doing
something flashy I'm gonna do something
geeky so I have here I have a little
project that uses the antler parser
generator to parse Java source files and
I don't really want to get too much into
how a parser works I mean this is a
debugging session not a parser session
but it's a cool little program we have a
main a main class here that basically
just takes some command-line arguments
at the bottom there's a routine called
somewhere near the bottom called parse
file that creates a lexer which tokenize
is the source file and creates a parser
which then actually does the parsing and
then we have this other routine do tree
action which actually creates a swing
tree view to look at what the parser
parsed so let's take a quick look at the
target for this project you can see it
compiles a bunch of Java source files a
no big deal in the executable setting it
runs the Java command line tool and the
arguments it passes the class path
pointing to the jar file that's built by
this project and - show tree is what
causes this particular program to build
the swing tree and then I actually have
two more arguments over there that our
source files to parse it's actually
parsing the the main class file for this
for this demo so let's just run that so
you can see what it's doing
it comes up reasonably quickly at the
top level this is basically the root of
the file there's nine import statements
here there's a class declaration Java
parser demo inside that there's a
variable and for methods Mui right
okay now I've set a breakpoint
let's just go ahead and debug and we hit
the breakpoint here now it turns out one
of the cool things about this parser and
the parser is that when it's looking
ahead and it sees something that's
confused it actually throws exceptions
back to a and those exceptions are
caught in a method which can handle the
errors so in order to see where it might
be throwing exceptions we want to turn
on the catching of exceptions so catch
all and we'll continue we stop pretty
quickly we actually stopped in system
class loader code in this case it's this
is a case where it's actually catching
the exceptions in Java code and we can
continue on and see it's just going to
keep catching exceptions catching
exceptions so let's turn that off for a
moment Oh catch not much of a typer I'm
afraid and let's go on we should get to
the breakpoint here in a second so the
one of the things that's doing right now
is it's it's debugging very slowly and
that's something that's actually fixed
in the Java patch that should be live
today using it uses the 131 VM while
you're debugging so that speeds things
up a lot I actually wanted to get that
on here but we were having other
problems configuring these systems so so
I didn't bother to to get it there okay
so we hit the breakpoint and let's turn
on the catching of exceptions now so
I've run through this twice the first
time it went in parse this file there
were all those class load exceptions and
we didn't want to see that so the second
time I hit this breakpoint
all those classes are loaded so we're
not going to hit exceptions for that
anymore so I can turn on just use the
up-arrow turn on exceptions again and in
just a moment here okay we we caught an
exception in the routine antlered up
parser got match if we look up the stack
we can see we were actually trying to
match an identifier on the input the one
thing you'll notice about this is that
there's no source code down below the
the the PC is not showing up there and
that's sort of irritating well it turns
out I have another project file that has
the antler source code in it so let me
open that up just need to open it up
don't have to do anything with it now if
I click on that line it goes to the code
and the other project this is not a
feature that's specific to the Java
debugger I just wanted to sneak that in
because it's actually one of the cooler
things about our debugging system and
you know what that's actually about all
I have here all the other standard stuff
in the debugger is pretty much the same
you can actually set variables in this
version of the debugger for Java that's
coming in the next version for the gdb
debugger but that's it and with that we
can switch back over to the slides I
actually have the clicker here I want to
bring up Jim Ingham and clean eNOS and
they're going to talk about the gory
details of debugging with gdb
let's fast fingers Clio ver there I'm
Jim so we're going to tell you something
about gdb which is the underlying
debugger that both metro works and
project builder use to run and control
applications under debugging in Mac OS
10 first of all a couple of words that
they said something about this in the
Metro work session - and it got some
applause so our goals for project
builder are that if you are a gooey type
debugger person you you're used to metro
works they see stuff like that we're not
gonna make anything that you need to do
as a user of debugging require the gdb
command-line you'll always be able to
get useful feet thank you useful
features from the project builder just
straightforwardly
but the other thing is that GB is
actually a pretty powerful environment
and there are some things which using
gdb you can actually get a lot of
leverage of its capabilities so we also
want to make it possible if you're a gdb
user that you can live in the project
builder environment get advantages of
you know locating sources and stuff like
that and still be able to use the nice
features in gdb that that if you've come
accustomed to them you know you love
them or you know you might learn to love
them at some point we're not all the way
there yet there's some things in the
console GP console window that don't
work or the way they do in the terminal
which is why in our demo we're actually
going to be using terminal but but we'll
get there so why would you want to use
gdb as opposed to project builder or in
the context of project builder and it's
actually a very good low-level debugger
it knows everything about your your
application it's been hacked on by
people for years and years both in the
embedded environment and in the UNIX
environment so there are a lot of
features for learning about your program
poking
and various things like that it's the
low-level debugger that everybody uses
so the features that are going to be in
project builder will already be in gdb
most likely so if there's something we
haven't gotten around to yet in project
builder it'll probably be available in
gdb so you know just if you are need
something that we haven't gotten around
to yet it's also scriptable so if there
are sort of actions that you want to
attach to things that happen in the
debugging in the course of your
debugging you can do that within the gdb
command language which is a really nice
feature and and finally it's extensible
so if you have some special purpose
things that you want to do and we'll
show an example of that a little later
on it's possible to extend the gdb
debugger to do those things for you you
know just it's an open-source debugger
so the extensions you know you just get
the source we have a plug-in
architecture and you can make commands
but also the source is available to you
you can look at it see everything that's
going on and so on
so the first thing is sort of what kind
of things at this stage are there which
we haven't yet gotten into PV which you
might want to use gdb for will give you
three examples of that one is remote
debugging which we certainly intend to
get P be able to do but it doesn't do
yet
the other is debugging F binaries which
in all likelihood won't make it into P
b-but and we'll see and then the third
is kernel debugging another thing that
we'd like to do in in project builder
but that's going to take more work as
just the setup for kernel debugging is a
little bit grody
so first of all remote debugging so this
is where you have the you're running the
controlling the debugger on one machine
you're actually running the debugger and
the application on another machine we
don't have the situation like Metro
works where they have a little nub
but in any case the point is that you
you are not typing you're not switching
the debugger into the foreground or
anything like that
while you're running the application
that you're debugging so this is good
for you know full screen applications
like games or situations where you're
trying to debug you know kind of Mouse
tracking and stuff like that we're
having the debugger come to the
foreground is obvious
not gonna help you figure out what's
going on so the way that you do this is
that you would start the application on
the remote machine and you have to do
that you can't actually start an
application remotely if it connects to
the Windows server because the Windows
server doesn't allow you to do that from
a telnet or SSH session so you have to
go to the machine that's going to run
the application start it up and then you
go to the machine you're going to be
debugging from and you telnet into the
machine running the application using
telnet SSH whatever your favorite thing
is and then you use gdb attach command
so the way that that works is you say
attach and then you can give the pid'
the process ID of your application which
you can find through top or whatever but
actually we've made it a little more
convenient than that if you type the
application name of your application and
then hit tab it'll actually go and look
at the process list find your process
for you and fill it in if there's more
than one process of the same name it
will offer you the choice of and you can
you can figure out which process it is
again processes are listed sequentially
so if it was launched the latest launch
one is going to have the highest bid so
you can kind of figure it out that way
and as I say we we have a few more
infrastructure things that we have to do
in gdb to make this available in project
builder but it'll be available in
project builder in the future the second
thing is using gdb with Carbon path so
you know ma co is the preferred format
for Mac OS 10 that's the one that our
tools will support fully and
enthusiastically but but there are some
cases where you know if you're debugging
a carbon peph application you might want
to get some features which aren't
available in code warrior for instance
up until code warrior 7 it didn't know
about mock Oh binary so if you wanted to
set a breakpoint in a function in ma Co
binary that was called on your behalf
which wasn't you know exported to path
through one of these vector libs then
the only way to do that was to was to
run your application under gdb instead
and set the breakpoint there so that's
kind of the main use for it I haven't
actually played with the new code war
yet so I don't know how easy that is to
do in code where that may be you can do
that fine and this is irrelevant but
also it's nice because you know you can
you can connect remotely if that's
important to you and other such things
so the way that you do that is first as
Robert said if you want to use really
any of the Apple tools with with carbon
path binaries then you should build with
inline traceback tables in code word
because that records information about
the functions such that the debuggers
and all the other performance tools can
find the names of your functions so and
then the next thing is that the loader
itself is not the thing the application
loader on Mac OS and doesn't actually
load Carbon peph binaries is actually an
application Amoco application which is
responsible for loading the the carbon
pet finder so that's this thing called
launch CFM app that's the thing that you
have to run GDB on and at the sate long
path because if I actually typed it out
on the screen it would actually fill
this whole slide so but if you look at
the little URL it's in the URL to just
cut it and paste it and then when you
run the way that the launch CFM
application works is that it takes as
its first argument the name of the
carbon F application that you are
actually attempting to run so in gdb you
say run and then you give it the name of
the application that you want to run and
as I say there's much more details about
this in this in this tips and tricks URL
so then the other place where you need
to use gdb and and and project builder
doesn't support this yet is is kernel
extension debugging this is a two
machine debugging situation in this case
gdb runs on the machine that you're
sitting on because of course you're
debugging the kernel and gdb is a user
space program so it's really not going
to be able to run on the machine the it
the two machines talk to one another
through a protocol called the KDP
protocol you don't need to worry too
much about that the only thing is kind
of conceptually what's going on is that
the kernel has a little agent that lives
in the kernel and gdb connects to that
agent and talks to it with some protocol
and and then that's how the gdb sitting
on your desktop machine is able to
control the kernel that you're
connecting to the only restriction is
that the two machines have to be on this
subnet to connect when you're running
the kernel under gdb it's just like
you're running any other program there's
nothing particularly special going on
you know you can do back traces you can
control execution everything works just
like GB running on a normal application
and it's kind of hidden to you that
you're talking across this protocol the
only thing to keep in mind though is
that you are talking to a little agent
that's living in the kernel so if you do
something really heinous to the kernel
in the course of your you know running
your kernel extension or whatever and
that causes the kernel to lock up then
you could very likely kill the little
agent and then gdb is just dead because
it has nothing to talk to anymore what
you'll see is it will start reporting
timeouts talking to the kernel agent and
that means that you've completely hosed
the machine and you don't have to reset
sorry and then there's much more
information about this in the tutorial
okay so now we're going to just show you
a few of the neato reasons why you might
want to use gdb even if you have a nice
fancy IDE to to control sort of the more
common aspects of debugging like
inspecting variables and stuff so there
are a few features that we'll talk about
one is the expression evaluator we'll
talk about how you can have commands
which fire when breakpoints are hit
we'll talk about how to set up
conditional breakpoints so that you can
have breakpoints only hit when certain
things happen you can take a bunch of
actions and can them up into your own
user-defined commands to extend the gdb
language and finally if you're really
ambitious you can write your own
extensions to gdb and see and load them
in for all of this the gdb manuals in
the developer package it's in developer
documentation developer tools and it's a
pretty nice manual it gives you a you
know tells you about all the gdb
commands has some nice examples things
you might like to do so if you get
interested in this that's a good place
to go for information
so now Klee is gonna this is Klee Venus
he's he's my cohort in gdb things he's
going to show you some some cool gdb
stuff
okay so the first thing is the
expression evaluator basically you can
call any function that's in your target
from gdb and you just use the syntax of
the language that's involved so we'll
use the appearance sample or our
favorite little demo and in this case
what we're going to do is call the print
functions that are in carbon which help
you get access to all of the opaque
stuff that you're not supposed to look
at anymore so first of all I mean you
know they're a bunch of print functions
I can never remember the names of things
and and I refuse to remember the names
of things if I can remember how to find
them so there's a it's actually info
function yeah so there's a gdb command
info function you give it a regular
expression don't worry about that and
just copy this down and I'll tell you
everything that's there so there's all
the lovely debug print functions you can
poke around and use any of them let's
print the window let's see what's there
oh nothing yet so if we step one step
and our next okay now we've created a
window so if we look at the window list
this time hey there's a window and so
then we can look up and hey there's a
debug print window so let's see about
that one so we're gonna call debug print
window the first entry is the actual
window token and since it's hex we have
to tell gdb it's hex so there's all your
information about the window a couple of
other things to remember is that the
functions that you call do change target
state none of these debug functions do
obviously and unless the guys in the
Carbon are pulling some kind of joke on
you but in general they the function
will run in your program which may be
good you may actually want to change
target State but if you call a function
that crashes you know you'll crash your
program so also you can call these
functions anywhere you use a gdb
expression so you can set variables to
the value of a function called and so on
and so forth so the next thing which is
really useful is breakpoint commands
we're gonna give a silly little example
here where you might want to use it
although for this there are other tools
like object Alec that probably do a
better job of it but so you know you've
got a problem with retains and releases
with CF with core foundations you know
somebody is over releasing something and
if your program is crashing what you'd
really like to do is know all the times
that an object gets retained and all the
times that it gets released some of
these are not under your control
because they're called on your behalf by
various other CF functions so you need
some other way to to get when that
actually occurs so what we're going to
do is we're gonna run we built this
little string example if you notice
there's a bug that we release the stir
one twice that's down at the bottom
that's the bug so what we want to do is
we want to set up we want to break on
the CF retain break on CF release every
time it occurs and then when that occurs
we'd like to you know print out a little
information for ourselves so that we
don't have to go grub around every time
to do that you set a command so you say
commands and then if you don't give an
argument it's the last breakpoint you
said is the one that the commands
register for you can also give a
breakpoint number so in this case what
we're doing is we're again calling
inferior functions on our behalf we're
getting the retain count the little
trick is that the arguments that are
passed to a function in the PowerPC ABI
are stored sequentially starting in
register 3 register 4 or 5 and so on so
since we know that the CF retain takes
one argument which is the thing that
you're retaining that's got to be in r3
so that's it we say CF get retain count
of dollar r3 that's just the argument
that's passed to CF retain and then
we're gonna print some information about
what's going on there and we're gonna
print the back trace so CLE is also
because he doesn't want to have to pipe
all this stuff in he's using the source
command in gdb he put this stuff in a
file and is just using the source
command to bring that file of gdb
commands in so I made a couple
breakpoints so this is cool now every
time he continues there we hit a CF
retain CF release call we print a little
information and we can step through our
code this way sort of automatically
printing out the stuff that's
interesting to us but if you were in a
big program and this was gonna happen
hundreds of times you probably wouldn't
want to step through each time because
that would get really old very quickly
what you might want to do is sort of do
a on-the-fly logging facility instead to
log all the calls to retain and release
so you can do that also you can just put
a continue command
in your breakpoint command and that says
hit this breakpoint do a little bit of
logging print out some stuff and then
keep running so now I have a little log
of all our CF pertains and releases this
also is a little bit overkill because I
mean you know there might be hundreds of
these this is going to just totally
swamp the screen it'd be nice if you
could be a little more discriminating
about what you are watching so that's
the point of conditional breakpoints you
can tell gdb to stop only when certain
conditions are true the conditions can
be basically any expression which is
valid in the language that you stop at
when you hit that breakpoint and the
condition gets reevaluated every time
you hit the breakpoint so you basically
write some C code whatever you want and
and gdb will evaluate that C code and
and then either stop or not based on
whether it's true or false
so in this case what we're going to do
is again we're going to we want to watch
the one that we have a suspicion that
it's ster one that's the bad guy so we
want to only watch retains and releases
of stir one remember since the
conditions getting evaluated every time
the breakpoints hit stir one is no
longer in scope so we have to actually
store away store one and so we can use
it later on and gdb allows you to use
convenience variables any variable that
begins with a dollar sign is actually a
variable that gdb stashes away on your
behalf so we're storing stir one when we
first create it in this watch variable
and then and then we do the regular
stuff we make our break and we actually
are also including the command in the
little file he's gonna source it and
then finally we set a condition on this
breakpoint dollar BP num is another of
these magical convenience variables it's
just the number of the last breakpoint
that was that was set so if you want to
store away a breakpoint number for later
use in your commands you use the BP num
variable and we're going to break when
dollar r3 again the argument to the CF
retain is equal to this watch variable
that we stored away so
that's cool nothing printed yeah
okay so now we only see the ones for the
token that we were interested in
and finally this would get really old to
type after a while and and also you know
notice that he was able to to call a
start watch stopwatch to actually watch
just one particular thing if you were
going to do this over and over again it
would be nice to can the set of
operations that did the watching and
then just reuse them over and over again
for that you can use what are called
user-defined commands in gdb the syntax
that this is not a particularly useful
example just just to show the syntax is
you say define and then you give any
name of the command that you want if you
name it the same as the gdb command
you'll override the GEB command which
may or may not be what you want probably
not and then you give any valid gtv
commands and finally the end statement
so the more complicated the one that
we're using is actually over on the
screen there the start watching command
the other thing about the gdb define
commands you can actually pass arguments
to them and they are stored in
convenience variables dollar arg0 dollar
r1 and so on and so forth so we want to
say start watching and the string we're
interested in watching and that gets
stored into this this watch variable and
then we've set the breakpoints up in
advance so they're just sitting around
for us our start watching command just
enables those breakpoints so you can
enable and disable breakpoints in gdb
just like you can in project builder and
finally we set the conditions on those
breakpoints and then we for convenience
to find a stop watching command so you
can say ok I'm not interested in
watching those things anymore you just
type stop watching and you're done so
that's convenient yeah that's that's
this so we defined these two commands
start watching and stop watching and
finally you can put all this in a file
and then there's a gdb source command
you can just say source and give a file
name and all these commands will be
sourced into gdb they'll be available to
you so if you have you know a bunch of
special-purpose tasks that you do in gdb
you can make a whole directory full of
useful little files and source them in
as you need them and you don't actually
have to type stuff so the last feature
is this allows you to do things in the
gdb command language the one thing to be
a little bit aware of is that
TV's command language is not designed to
be a high-performance interpreter by any
means so if you're doing something
really really complicated it's probably
going to get slow on you and at that
point you might think about whether you
wanted to write an extension to gdb and
C C++ objective-c I mean the nice thing
is you get access to all of GD B's
internal functionality on the other hand
gdb has a lot of internal functionality
not all of which is terribly well
documented so there's a fairly high
learning curve but if you have a job to
do you got a job to do you know this
might help you the other thing to keep
in mind is that gdb is under the GPL
it's an open source piece of software so
if you're thinking about writing gdb
plugins which you want to make
commercial things then realize that
they're going to have to be distributed
under the GPL license as well if you
want to just use it for in-house it
doesn't matter the GPL allows you to do
whatever you want for in-house use and
it only restricts what you do if you're
trying to sell or distribute
commercially or whatever your software
um they're faster and they have much
more capability much more flexible than
GB so here's our example you know that
the guys at various people at Apple have
max bugs wired into their mental
processes and their fingers just type
max bugs commands and and and so the
people who are using gdb a bunch of the
guys in the in our group just couldn't
couldn't type the gdb commands they
needed the max bug commands and he did
max bug they needed it so one of them
actually went to the trouble of making
max bug so it's got the complete max bug
command sets it updates properly it has
all the instruction listing and
everything that you've come to love it's
got a nice little help so you can figure
out what they all are so actually been a
lifesaver for some of the people here
the one thing about it is that it's a
it's in this user live exact gdb plugins
max bug and you just source that file in
in the version that's on both GM and and
the CDs there was a bug in the file that
you source in a path was set to be wrong
so you just need to go change that if
you want to use
and there's a tech note on the developer
website please typing in the address now
that tells you what you need to do but
actually if you fire it up once it'll
say can't find this file and you'll look
and there's tourney bogus stuff in the
file obviously so it's pretty easy to
fix okay
and with that I'll bring Dave back up to
tell us the last little bits about
debugging on Mac OS 10 okay so we've
seen quite a lot of different powerful
features here today if you've been to
WWE sees the past couple of years you've
seen me standing up here saying we're
committed to delivering great developer
tools it's fun this year to actually be
up here saying well you've got him now
and you've seen a lot of power here
under the covers that there's a lot more
we can do in terms of extending what
we've gotten in project builder now with
what we've got there today is very
powerful for sea-based language
debugging for Java debugging but a lot
of this capability of gdb we just need
to provide more user interface to it we
can bring some of this more out in the
the project builder UI as well so
there's a lot of additional improvements
that we plan to make in the product for
debugging and across project Boulder as
a whole I'm a lot of what we do is
guided by the feedback that we get all
of my team monitors what's going on and
the project builder - the users email
list that's the best way to broadly
communicate with us and the entire rest
of the community if there's just
feedback you want to send directly to us
initially I should move on to the lists
here there's ways to do that as well so
let me actually bring godfrey back on
stage I was going to yank his chain this
morning and I haven't introduced under
the wrong name like we had done on
Tuesday as well but my new name is
Jonathan Jonathan - Jersey well thank
you very much it's very good to see you
such a large crowd here on a Friday
morning I point you to the information
resources page you have the clicker I
have the clear
the first the first is our is our master
page for all Mac os10 tools we try to
put everything up there we have a number
of additions to make both third-party
and internal and we continually develop
it we put the latest things on each of
the pages for each for each specific
technology below that we have apples
master let master mailing list page and
the project builder users page what do
we have now almost a thousand users
I'm keep waiting we're like 944 last
night come on get me over a thousand
here so go sign up where we're reaching
we're reaching here roadmap we have a
feedback form for all developer tools
this afternoon at 3:30 in room j1 not on
the roadmap but other important sessions
that are you know still technically part
of the tools track right after this
session in a2 we have the darwin
documentation product project and headed
doc and also at two o'clock we have the
apple c++ framework session which talks
about the apple class suites and mac app
for those people interested in those
areas those are going to be very good
sessions and my contact information if
you have any questions any interests and
he needs in tools you can always contact
me at rahman at apple.com
and we have the Mac OS 10 tools feedback
mailing list which actually distributes
an incoming email to all of the
engineering team so if you have feature
enhancements ideas we love to hear this
stuff we really want your feedback so
that that that's a great address if you
don't necessarily want to send it to the
whole community but just the 30 or so of
us on that list the interface builder
folks are on there as well and I know
everybody to distribute other requests
to in that and and also send bug reports
in as well lad that's how we actually
fully keep track of everything
you