Good morning. It's Friday morning. How many people are awake? It's great to see such a good-sized crowd here on the last day of the conference. I hope you have a good day today. We have a great show this morning. Uh, I'd like to bring on Dave Payne, manager of the Developer Tool Applications group. And he's going to talk about debugging.

,. So did you all enjoy our campus last night? Nice place, isn't it? All right, so lots to 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 X 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 are really getting down and dirty with GDB, the command line debugger. Then bring Metrowerks on stage to take a look at debugging in CodeWarrior Pro 6.

So really, which of these that you use depends on what you're building on Mac OS X. 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 Metrowerks 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 the common 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 talk pretty directly to it on Mac OS X itself. In the case of Code Warrior, Apple and Metrowerks work 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 Metrowerks 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 X machine with GDB and with your target application. Because it's going through the MetroWorks-- it's actually a remote debugging protocol-- Code Warrior can work on Mac OS 9 or Mac OS X and do debugging of applications there.

But again, which one you use depends on what you're building. With Carbon applications, you can build them as either MACO or PEF. For all else in the system, MACO is the primary binary format for the system. It's the native format. It's what we use for everything. So we've built the OS with that since essentially the dawn of time from the base that we developed it from back at 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 Mach-O applications. So all of the BSD APIs are accessible, all of your frameworks. So Cocoa, all of the Carbon frameworks are actually implemented as Mach-O frameworks on the system. You can do, so you can write all different types of applications as Mach-O. If you're writing, say, an I/O Kit module, so a device driver or kernel extension, you would do that in Mako as well. You can use Mako in a PEF application by doing a Mako plugin, a CFPlugin, that loads transparently. You don't have to know that it's Mako, really. So the new project builder IDE fully supports development with Mako. GDB supports debugging of that. Metrowerks will be working to provide a full Mako development suite as well. So you'll have that option as well in a future release of Metrowerks.

Your other option for Carbon binaries is to develop a PEF binary. That's the native format on Mac OS 9. We've provided a code fragment manager to load PEF containers on Mac OS X to provide transitional support for Carbon applications coming in. You can have one of these PEF binaries can actually run on both Mac OS 9 or Mac OS X. Our preference, actually, is that you use the new bundle packaging scheme to come up with an app package that you can take advantage of localization and everything else from the app package. You can have a Maco binary for Mac OS X and a PEF binary for Mac OS 9 and be double-clickable on each. But PEF alone is an acceptable option. To do that today, you would use CodeWarrior to do that. But Metrowerks has provided full debugging support for Code Warrior binaries running on-- or Carbon PEF binaries running on Mac OS X. So again, Metrowerks is also working to provide MacO functionality.

And in my project builder session on Wednesday, we also demonstrated kind of a bleeding edge functionality of generating a PEF 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 Rad Hagee, debugging engineer for Project Builder. And he'll take you through some of the Project Builder debugging details. Thanks, Nick.

Good morning, everyone. I'll be talking about Project Builder and debugging on Mac OS X and some of the larger issues that you might run into specific to Mac OS X. 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 X platform initiatives, mainly Carbon and its use of opaque data types, and the semantics of the Mac OS X dynamic shared library mechanism.

Because we encourage the use of frameworks and shared libraries, Project Builder supports cross-project debugging where one project can build the framework and another project can use it. And then finally, 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 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 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 with opaque data types or abstract data types because you can't look into them. So how can we debug these in the Mac OS X 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 you can't do that with opaque data types. So what we can do is we can take advantage of the debugging system on Mac OS X and run functions during the debugging session inside the debugged 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 textual representation of the CFData types, dictionaries, and strings, and so forth. In Carbon, 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 a print resource chain prints all the information about the resources active at the moment. And then there's some in the QuickDraw framework that, instead of providing the textual information, provide 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 we use the term dynamic shared libraries or dilibs on Mac OS X to emphasize the specific semantics of shared libraries on Mac OS X. They come in, well, we say two types, but it's more of two ways of representing on the file system, 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 avoid this problem?

The general question we want to explore is that on Mac OS X, shared libraries and frameworks are designed to be installed at a specific location. And how do you do development when you don't want to install them? So let's look at the details of how this process works. At build time, when you build your shared library, part of your configuration information you give to the build system in Project Builder is the path where you're going to install the framework or the 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, ah, 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 developer, you're probably running as your own user ID with permissions that don't allow you to actually install or modify files inside the file system. Usually that's done as root 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 are various environment variables that control how the dynamic link editor, DYLD, accesses and finds shared libraries. And if you do end up using these, you should consult the manual page, man-dyld, and find out all you can do with the dynamic link editor. If you're also going to Mac hack, it 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 thing. If you use Project Builder, we take care of all this for you so that you can just build your projects 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, we're really encouraging using the app packaging model. And one of the things we plan to put into the package are private frameworks used by the application. We're not quite there yet, but the intent is the application will be completely self-contained. OK.

Now that-- if you put your shared library inside a framework, inside the packaging, 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, these are binary files. The shared libraries 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 runtime error checking at core foundation and Carbon do extra checking of parameters. They can do internal state checking to ensure consistency that the APIs are used correctly. And finally, there's a profiled version which is used with the Gprof profiling system. Again, the low level environment variable that controls this is DYLD image suffix, but Project Builder allows you to access these directly.

So now we'll talk a bit more in detail about Project Builder itself, go over how to configure things, breakpoints, and then we'll have a demo. now. As we've said, Project Builder enables cross-project debugging. And to do that, you need to build your projects, and specifically the products of your project, and have them put in a common location so that we can find them at compile time and at runtime.

And we'll go over in the demo how to do that. We use the term executable for the thing that you're going to debug. It can be, for right now, it's a binary. It can eventually be Java or it can be some other kind of program. And you can set various settings on the executable, such as the arguments, essentially the command line arguments, argv and argc, 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, of 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 function is being called and what the stack backtrace is. We have a summary of all the breakpoints in your project. And the key word is here, they're your breakpoints. And each member of the development team has his or her own set of breakpoints that are stored independently but persistently. So now I'd like to bring up Dave Ewing, who's going to help me with the-- there he is-- the demo. Dave works on our Java debugger.

All right, if we could have-- all right, demo three. All right, first let's look at the preferences, the build preferences in Project Builder. And the key here is just wanted to show you that there are two settings, which are file system paths, which are where you build. And this is very important to set for cross-project debugging and runtime settings so we can find your frameworks. Okay.

Now let's look at the Targets tab. Target has many settings, and Target logically has an executable or a set of executables. You can add your own if your project builds a-- builds a library, or if you're working with a legacy project, so-called, that uses the make system, it's an open source project, 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, in most cases, what debugger to use. There are various corner cases. if you're debugging Java and you've got native code and you wanna use the GDB debugger, that's what you'd come here and select that. And then there's a runtime tab. I should mention that this version of Project Builder is post-DP4, the runtime tab isn't on there. But it gives you an idea, we can now select which variants of the system frameworks 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. and we'll run with it. This is appearance sample, it's the 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, oh, it's too big and we've crashed. Just to note how to read the output here, says your program is exited with a signal, that's the Unix way of saying there was 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 will 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 persistent 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. Alright, now let's fire up the debugger.

Make it a little bigger. And if we move the slider this time, trap on the breakpoint, get a list of threads in the stack we're in and variables. Let's Just a little bit to show you. Can you close up the console, Dave, so we can-- there we go. You can see the local item value changed.

Now this is C++ program. There's the implicit this pointer passed to each method. The way data is displayed for C++ objects is each superclass of your, its member data is represented as kind of a pseudo structure that you can disclose. Now we see there's a F 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 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 the calling, call site to call this function. And you can see now we've got some information about the dialogue and the function. Let's just do print resource change just to show kind of some global information that you can get from Carbon.

Tell you 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 to find what we want. Okay, I think we're running a little short on time, so thanks, Dave. Thank you. If we can go back to the slides, please. All right. Just a note about what we're planning in the future. Project builders are a work in progress.

We know there's lots. We have a large constituency, and each group has different needs. Some want low level, some want more high level. And we're planning to do all that in the coming months. Dave's working on Java debugging, which is coming along. So later on, we'll be giving you the email list for feedback. And we'd really appreciate any feedback on the debugging system, and specifically what features 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 Klee Dinas. He's our GDB expert. Hey Klee.

I'm Klee Dinas, 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 the system. Basically, the role of GDB in our system is very simple. GDB is the Mac's bug for Mac OS X. Really, it fulfills the same roles in the system that Mac's bug fulfilled on Mac OS 9.

Our intent is that it be something that's available as a foundation for other debugging environments, and also that it be available as 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 Metrowerks 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. 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, 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 plug-ins, and since it's open source, it's got the ability to add new commands and 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 GDB visible at the top level. That said, what I'm going to be talking about a little bit is some reasons you might choose to use GDB from the command line today. And as I said 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 we 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 in the short term. Some of the features we're going to be showing you are the expression evaluator, which basically gives you a C interpreter or a C++ interpreter or an Objective-C interpreter at the command line. Scriptability, which 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 debugging, 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 just to give you a taste of the sort of things you can do. We've got full documentation on the system in 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 MaxBug equivalent. Can everybody see that? The text?

Specifically the people in the back? Just wave if you can. All right. So what we're going to do 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 MaxBug 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 the Unix system call for opening a file. And we're going to go ahead and continue the finder.

and Dave is going to do something to cause it to open a file. And you'll see over in the command window, the finder has stopped and opened. We're going to take a look around, sort of snoop a bit to see where we are, maybe get a back trace. You can see we've gone through some chain of C++ calls that 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 gonna 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-- I guess first we'll be looking at the-- May as well finish. You can give it commands to apply to all commands. In this case, we've gotten a backtrace of all of the threads.

Or you might want to just give it an expression. So you might want to just tell it to print the contents of register 3. And I'll give it to you as an integer, which isn't very useful, so you might tell it to print it 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.

I'm not going to go too far into the expression. Basically, anything that's a legal C 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 is 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 breakpoint. And what I'm going to do is I'm going to tell it first to not print the breakpoint line every time.

Then I'm going to tell it to print the first argument, which I just happen to know is R3 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 detail that'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 an artifact of our HFS implementation. In this case, what I'd like to do is just focus on the plist, 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.plist.

So if we're just interested to see which files that end in plist are getting opened, we can actually attach a condition. In this case, we're just going to take R3 and we're going to string compare it with.plist. And if that expression doesn't evaluate true, in this case, if it doesn't end in plist, it's going to just skip that breakpoint entirely. So now when we continue.

Now we just see the plists that are being loaded by the system. Thank you. And certainly, you can come up with 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 3 in the morning. I was desperate to figure out 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 genned up a little tiny program, most of that's documentation, that defines two commands. which sets a stopwatch for CPU time. And the other is curr, which tells you how much CPU time you've used since the last time you typed "mark." Basically, it just calls the getRUsage function in the system to tell you how much CPU time has been used. So what we're going to do is we're going to take a look at a small program that I rigged up that's just basically allocates 64 meg of memory and zeroes it two different ways. One way is the slow way. The other way is the fast way. And it's not a very interesting program, but when we take a look at it, He's just going to load the iProfiling library. So we take a look at main. One more. You'll see it makes a big buffer, zeroes it the fast way, if you can list that.

and then lists the zeros at the slow way. And what we'll find is that when we run this, I'm sorry? - I've got a break point. - Oh, I'd love a break point, thank you. That'd be very good. When we run this, we're going to step forward to where we want to end up.

We're going to step to right before the fast zero. We're going to set a mark. We're going to step over fast zero. Step over, Fast Zero. We're going to allocate 64 meg, and then we're going to type curr to see how long that took. 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 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 its use as a profiling tool, although it really saved my butt one Sunday night. 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 One thing that surprised me just before we were putting DP4 out was one of our support engineers sent us an email saying, "Hey, I really missed all those max bugs commands, so I rigged up a quick max bug compatibility library."

And so, you know, I gave it a try, and I even-- I tried actually many of the Maxbooks, and most of the Maxbooks commands that I knew and discovered 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 I thank you very much.

Thanks, Klee. Thanks, Dave. Thanks, Rab. 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 skankiness we were typing in here, but more intending to show that the power is there. This is an open source debugger, so I believe if the sources aren't already in Darwin, and they're going to be 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, 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 4, DP4. What you're seeing here in DP4 is the first release that we've done of this. I think that given that that's a 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 in the 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 get some conflicting demands, and so I really want to hear sort of 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 a public email list for Project Builder. I checked this out last night. It is online at this point.

So in the area that lists addresses are set up for Apple, projectbuilder-users at public.lists.apple.com. That's for the community to discuss Project Builder usage. Feedback that gets directly back to us. This is the great place to send me and the team requests, is the macos10-tools-feedback at group.apple.com address. For support with Project Builder, there's also the DTS site and e-mail list there. And as we talked about, Project Builder will be available through the quarterly tool CDs to 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 Metrowerks, specifically Ken Ryle, the lead engineer on debugging at Metrowerks. Thanks, Dave. Thank you.

Well, if you were here at our session last year, we talked about debugging on Mac OS X. And at that point, Apple had helped us put together a debug node that let us debug remotely from a Mac OS 9 machine to Mac OS X. And we've been busy since then bringing Code Warrior to Mac OS X. 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 6 tools that we've been handing out here at the show. The actual tools will ship later this year, but the CD has tools that you can start now building and debugging applications on Mac OS X. So what's really new in these tools is that the IDE is fully carbonized. It runs natively on Mac OS X, and you can do single machine debugging. So you can take all of the CarbonPep apps that you've been running on 9, carbonize them, and use the same debugger on 10 that you've been debugging on 9. We've also done a lot more work in two-machine debugging for this release. Before we did 9 to 9 debugging, and we also did debugging from 9 to 10, but we've fleshed that out now so you can really do four-way debugging from 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 Dave talked about, the Metrics tools right now build CarbonPep applications for Mac OS X. Our Maco tools are in development, and you'll see those in later releases. Right now, these are designed to transition your CarbonPep apps that you've been building online and bring them to 10 and let you debug them the same way. So with that, I'll go to a demo and show you you can do with the tools that are on the Pro 6 CD.

The first thing I'm going to do is start DebugNub. DebugNub is the piece of debugging technology that Dave and Klee and his team collaborated on with Metrowerks to provide a link between the CodeWarrior debug protocols and GDB. With the tools on the CD, you have to start DebugNub manually, but be sure and sign up to the beta program and 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 two machine debugger that we shipped with the 5.3 tools, I'll show you a couple differences in 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 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 project's target settings.

and tell it specifically you can enable remote debugging and tell it specifically which connection type you're going to work with. Also specify the remote download path, which if you're debugging on Mac OS X needs to be a Unix style path. And also tell the debugger to launch a remote host application if you're remote debugging a 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 power plant sample. And ask it to debug. So what it's doing now is launching your Carbon PEF app and stopping at the first breakpoint. Let me resize a couple windows. So at this point, you're in the same Code Warrior debugger that you've been using on 9. You can do all the normal things, step, set breakpoints, look at variables, look at registers, processes, all the same user interfaces here available to you. And-- breakpoints, run to those. And then we continue running. We have our power plant appearance application. find the source that creates a new window instead of break point here.

And then we stop at that breakpoint. So as you can see here, I'm not going to try and demo all the debugger features in CodeWarrior, because you're probably familiar with them. Really, our news here is just that all those same features are available natively on Mac OS X for single machine debugging.

So that's really the demonstration that all the same things you've been used to doing on 9 can now work on 10 in Code Warrior. We're also in the future working with Apple to provide an interface to some of the advanced GDB features that Klee came out and talked about. So we'll be extending Code Warrior debugging support on 10 to let you do some of the things that GDB makes possible on 10 that weren't really very easy to do on 9. So we'll 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 are available on the Pro 6 beta CD, and that's been available to people at our sessions. We've been handing those out at the show. And again, please get into the beta program because we'll have new releases over the summer that add additional debugging support for Mac OS X and just sort of polish up the Pro 6 tools. And be sure and also send your feedback to the web, our website, and send that to us through the beta program. And now, here's Godfrey again.

Big hands for Ken. Thank you very much, Ken. Okay, so this is just a slide giving you some contact. I repeat, the developer tools group email address, so you can contact us with feedback and your ideas. You can always contact me as the technology manager for development tools at Apple, and Ken Ryle, the core debugger engineering lead at Metrowerks. And with that, we have one more session in the tools track immediately after this one in Hall C. We have a feedback forum for the Apple Developer Tools. Hope to see a good number of you there. Okay, with that, we can bring the house lights up and start Q&A. Can I ask our presenters to come up on stage? Thank you.