This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Re: [PATCH] Always include defs.h first.
On 11/08/2012 06:12 PM, Doug Evans wrote: > > Another thing to consider: > I'd like to move gdb to being more componentized (for lack of a better word). > i.e., made up of application independent pieces. > common/ is a minor step in this direction. Yeah. I recently wrote the below in an internal discussion. Allow me to just paste it here, as it just fits. This was about the direction of local/remote parity project once we reach a state where we can consider reusing gdbserver's backend within gdb, instead of the linux-nat.c/linux-low.c & friends duplication. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The division depends on how much of gdbserver we'd put into GDB. One idea is to split at the target_ops level, where gdb's target_ops vector calls gdbserver's target_ops methods (bypassing most of "core" gdbserver code, RSP etc.) But gdbserver's backends make use of e.g., breakpoints, behind gdb's back. It may prove to be better to keep core gdb agnostic of this, and import gdbserver's breakpoints and regcache modules into gdb too (strictly for target side stuff), instead of adapting the backends use the main gdb's breakpoints list and regcaches. I never liked the "common" moniker much. It is a bit artificial and an artifact. It tells us that the code is used by more than one something, but it doesn't tell us really what's inside. IMO, it's not much different from saying the gdb/ is the new common and allowing gdb/gdbserver/ to refer to files under gdb/ . In the extreme, we could end up with half of gdb under common/ in a few years... I was hoping we could so a better split, say, start by putting the native target code (target_ops&friends) into its own dir. Or maybe call it "libbackend/"... In any case, I think we have two kinds of "common" stuff. There's the native target backends (ptrace and friends), but there's also the host side common stuff. If you strip both gdb and gdbserver of their native target backends (e.g, in gdbserver, you end up with "main()", command line option processing, the event loop, the RSP mashalling, etc.., you'll still find things that are common between the two programs. The event loop is an obvious example. So it feels to me that we could take the opportunity to do a better code division. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Note that gdbserver doesn't have defs.h and lots of files in common/ do the Well aware. :-) -- Pedro Alves