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