This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Share ptrace options discovery/linux native code between GDB and gdbserver


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]