Re: [RFC] ARI fixes: Remove NAT_FILE for solaris

[Pedro Alves <pedro at codesourcery dot com>]

On Friday 09 April 2010 19:43:53, Pierre Muller wrote:
> > -----Message d'origine-----
> > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> > owner@sourceware.org] De la part de Pedro Alves
> > Envoyé : Friday, April 09, 2010 6:13 PM
> > À : gdb-patches@sourceware.org
> > Cc : Pierre Muller
> > Objet : Re: [RFC] ARI fixes: Remove NAT_FILE for solaris
> > 
> > On Friday 09 April 2010 17:10:50, Pierre Muller wrote:
> > > This patch simply removes i386/nm-i386sol2.h
> > >
> > > The only remaining code was
> > > #ifdef NEW_PROC_API
> > > #define CANNOT_STEP_HW_WATCHPOINTS
> > > #endif
> > >
> > >   I moved that into gdb/configure.ac.
> > > The most difficult part was to get all the tools
> > > (in the correct versions) to be able to regenerate
> > > config.in and configure on a solaris machine.
> > 
> > This fixes nothing.  There's a reason we want to get rid
> > of macros defined in nm files and used in common code.  As is,
> > a cross debugger hosted on solaris behaves differently from
> > a cross debugger hosted on all other hosts.
> 
>   I agree, but I thought that doing this step by step would be easier...

In principle that's fine.  But, the only effect of your patch
is pacifying the ARI; it's a step backwards.  ARI is tool with
a purpose --- remind us of things we need to fix, not to have
clean results by hiding bugs!

> My big patches take ages to get in, so I prefer to do it bitwise!

Yeah, sorry, I still have one of those in my queue.

> 
>   How could we change this so that this
> would only trigger if we are debugging native and not some other 
> target?

First off, we get to decide if the special casing on solaris is
still needed in the first place.  It may not be needed anymore.
What does it affect?  What do the comments around it suggest?
For what versions of solaris was it relevant.  Etc..

Second, if we still need the workaround, can it be done all
within the target side?

>   Could we change the macro
> into a test that the current target is native solaris?

If we can't do the fix in the target side, then I don't
think that would be correct.  What if we're cross
debugging solaris from a non-solaris host (recently someone
mentioned they had a solaris gdbserver port)?  That would 
suggest a gdbarch flag instead (target_gdbarch).

But I'd first try to check if the workaround is still
relevant at all.

> I don't know enough on gdbarch and tdep structures
> to have an idea how to write such a test.
> 
>   Advices welcome.

-- 
Pedro Alves