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

[Kevin Buettner]

On Jul 19,  6:27pm, Stan Shebs wrote:

> > 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". :-)

I see your point - and am even aware of some places where this has
happened - but I believe your argument hinges on the premise that we
"can't/don't want to link in the inappropriate file just to get the
one function...".  However, once things are multi-arched, you *have*
to link in all of the ABI specific tdep.c files.  The reason for this
is that <arch>_gdbarch_init() is responsible for setting up the
various methods depending upon which ABI is getting used and it has to
know about all of them.  (Okay, you could avoid linking in these
various files if you're willing to introduce ifdefs into the code, but
I'm not willing to do this.)

E.g, in my (proposed) patches for rs6000-tdep.c, the following
bit of code was added to change the gdbarch initializations:

  if (osabi == ELFOSABI_LINUX)
    {
      set_gdbarch_frameless_function_invocation (gdbarch,
	ppc_linux_frameless_function_invocation);
      ...
    }
  else
    {
      set_gdbarch_frameless_function_invocation (gdbarch,
	rs6000_frameless_function_invocation);
      ...
    }

ppc_linux_frameless_function_invocation() is really linux specific
since the details concerning sigtramp frames are not spelled out in
the ABI.

But, in another part of the function, I have the following:

  if (sysv_abi)
    set_gdbarch_push_arguments (gdbarch, ppc_sysv_abi_push_arguments);
  else
    set_gdbarch_push_arguments (gdbarch, rs6000_push_arguments);

I've put ppc_sysv_abi_push_arguments() in ppc-linux-tdep.c, but
it will be used by non-linux targets as well.