This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Share ptrace options discovery/linux native code between GDB and gdbserver
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: lgustavo at codesourcery dot com, "'gdb-patches\ at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Tue, 30 Jul 2013 13:20:03 -0600
- Subject: Re: [PATCH] Share ptrace options discovery/linux native code between GDB and gdbserver
- References: <51F04092 dot 2070008 at codesourcery dot com> <51F80CDB dot 3050106 at redhat dot com>
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
Pedro> That's a roundabout way of ending up with all code in a
Pedro> single file anyway. And it left us with a weird linux-nat-common.c file
Pedro> in a few intermediate steps where it no longer hold code used by the
Pedro> gdb side backend (because by then there's no gdb side backend!). If the
Pedro> code within is well isolated, we could even consider not merging it
Pedro> back into linux-low.c in the end, keeping the backend split in smaller
Pedro> modules. But in order to do that, we best name it something actually
Pedro> indicative or its contents, and avoid coming up with new kitchen sinks.
Pedro> Say, this file holds the waitpid/__WALL/EINTR wrapper replacement, so
Pedro> what about linux-waitpid.c ? Then:
Pedro> linux-nat.c, gdbserver/linux-low.c,
Pedro> -> linux-nat.c, gdbserver/linux-low.c, common/linux-waitpid.c
Pedro> -> gdbserver/linux-low.c, common/linux-waitpid.c
Pedro> -> common/linux-low.c, common/linux-waitpid.c
My initial reaction was that combining movement and refactoring is bad.
But on reflection it seems like just movement: the functions (pretty
much) stay the same; they may get some minor tweaks (as you'd expect
from a merge); but putting them into separate smaller new files is
really no different from stuffing them all into one big new file.
So I'm on board.
More stuff to put on the project page on the wiki...
Tom