This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Several large changes to GDB have been proposed lately, and more are in the pipe; I thought I'd give everybody a quick summary of what's going on. Feel free to comment on anything here! MULTI-ARCH: Over the past several months, Andrew Cagney has been quietly turning the funky target description macros into something more like modern executable code. The ultimate goal of this to be able to handle architectures with objects, just as we do now for target vectors or BFDs. The primary beneficiary will be GDBers doing maintenance, but new systems on the horizon will use this feature as well. EVENT LOOP: Elena Zannoni is in the process of getting approval to check in a large body of code that shift GDB over to an event-driven model, where both user interaction and target events are handled uniformly. Again, this is primarily infrastructure, but she's also working on something very user-visible... ASYNC DEBUG: One of the benefits of being event-driven is that it will become possible to interact with GDB while the inferior is running! This won't always be sensible - what if the program is modifying the data you're trying to format? - but it will be very useful for monitoring programs that don't like being interrupted and resumed continously, such as servers. WFI REORG: Unfortunately, the infamous wait_for_inferior interferes with this plan by being an infinite loop with a tangled body. Building on work started by Edie Epstein, I'm transforming WFI into a simpler and clearer body of code that only runs the equivalent of one pass through the old loop before returning control to its caller. I'm making the change incrementally, preserving the old code carefully and watching for regressions. REFORMAT: Over the years GDB sources have accumulated detritus from many different coding styles, despite the official GNU standard's encouragement of uniformity, and now there is much confusion about the correct style for GDB. So I propose a flag day, in which we run GNU indent over all the code at once. The CVS diffs will be massive, old patches will fail (although one could run indent on the patches), but then we can use indent all the time and never have to deal with this again. ANSI/ISO C: So far I've not seen any reports of people being hosed by the pure standard C code in 4.18. By the end of June we'll know for sure; then we can whack all the K&R compat bits and go to new-style code everywhere. Stan