This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [PATCH RFC] Make GNU/Linux/PPC port work again


Kevin Buettner wrote:
> 
> As I understand it (from Andrew), the tm.h files will eventually go
> away.
> 
> For a some targets, there's a single tdep.c file, so constants like
> the above can conveniently just be placed in the file itself.

I suspect that in the long run your approach will probably be what
ends up getting used, but we ought to plan it a little more before
acting.  For instance, the suggestion of moving platform-specific
sources into subdirs has been raised by several folks recently, and
I think it's worth reconsidering.  For now I'd vote to leave things
in tm.h so that when the time comes, there won't be "Kevin's weird
header files" :-) to figure out how to deal with.

> For other targets, we have a family of tdep.c files.  The way I like
> to think of it is as follows:
> 
>     <arch>-tdep.c       - main tdep.c file for a particular architecture
>     <arch>-<os/abi>-tdep.c
>                         - additional details for a particular OS or ABI
>                           (i.e, signal handling, shared library support)
> 
> We *could* just concatenate all of these into one big <arch>-tdep.c
> file, but I personally think it's cleaner to separate the details for
> different ABIs into separate files.

Let me take this opportunity to warn people of what usually happens
when we do this.  You need a piece of functionality in an OS/ABI
file, because contrary to what the original author thought, it's useful
for more than one OS or ABI.  Since you can't/don't want to link in the
inappropriate file just to get the one function, cut-n-paste rides into
town to, ahem, save the day, and voila, two copies of the same function
to maintain.  The next generation of maintainers hack one and not the
other, and we end up with two functions that are different, but it's
not clear why.

So one of the advantages of having a common <arch>-tdep.c is that it
strongly encourages people to share code that is common among systems
using the same type of CPU.  We can get the same effect by being
vigilant, but, as the DOJ said to Microsoft, "we prefer structural
remedies because it's less work for us". :-)

Stan

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