From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Joel Brobecker <brobecker@act-europe.fr>
Cc: gdb-patches@sources.redhat.com
Subject: Re: patch to gdb on Tru64 5.1
Date: Thu, 10 May 2001 08:32:00 -0000
Message-id: <3AF9B89F.2090007@cygnus.com>
References: <20010509082227.E23184@act-europe.fr>
X-SW-Source: 2001-05/msg00146.html

FYI, in addition to the description of the change, a ChangeLog entry is 
needed.


> Index: gdb/alpha-nat.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/alpha-nat.c,v
> retrieving revision 1.7
> diff -c -3 -p -r1.7 alpha-nat.c
> *** alpha-nat.c	2001/03/06 08:21:05	1.7
> --- alpha-nat.c	2001/05/09 05:33:21
> ***************
> *** 29,35 ****
>   #include <asm/reg.h>
> #include <alpha/ptrace.h>
> #else
> ! #include <machine/reg.h>
> #endif
>   #include <sys/user.h>
> --- 29,35 ----
>   #include <asm/reg.h>
> #include <alpha/ptrace.h>
> #else
> ! #include <alpha/coreregs.h>
> #endif
>   #include <sys/user.h>

Is this safe?  Hmm, looking at that part of the header:

#ifdef __linux__
#include <asm/reg.h>
#include <alpha/ptrace.h>
#else
#include <machine/reg.h>
#endif

the whole thing is somewhat bogus.  Anyway, you need to be certain that 
your change doesn't break at least the immediatly previous OS.


> + #ifdef NCF_REGS
> + #define EFL NCF_REGS
> +     CF_V0, CF_T0, CF_T1, CF_T2, CF_T3, CF_T4, CF_T5, CF_T6,
> +     CF_T7, CF_S0, CF_S1, CF_S2, CF_S3, CF_S4, CF_S5, CF_S6,
> +     CF_A0, CF_A1, CF_A2, CF_A3, CF_A4, CF_A5, CF_T8, CF_T9,
> +     CF_T10, CF_T11, CF_RA, CF_T12, CF_AT, CF_GP, CF_SP, -1,
> + #else
>   #define EFL (EF_SIZE / 8)
> + #define CF_PC EF_PC
>       EF_V0, EF_T0, EF_T1, EF_T2, EF_T3, EF_T4, EF_T5, EF_T6,
>       EF_T7, EF_S0, EF_S1, EF_S2, EF_S3, EF_S4, EF_S5, EF_S6,
>       EF_A0, EF_A1, EF_A2, EF_A3, EF_A4, EF_A5, EF_T8, EF_T9,
>       EF_T10, EF_T11, EF_RA, EF_T12, EF_AT, EF_GP, EF_SP, -1,
> + #endif
>       EFL + 0, EFL + 1, EFL + 2, EFL + 3, EFL + 4, EFL + 5, EFL + 6, EFL + 7,
>       EFL + 8, EFL + 9, EFL + 10, EFL + 11, EFL + 12, EFL + 13, EFL + 14, EFL + 15,
>       EFL + 16, EFL + 17, EFL + 18, EFL + 19, EFL + 20, EFL + 21, EFL + 22, EFL + 23,
>       EFL + 24, EFL + 25, EFL + 26, EFL + 27, EFL + 28, EFL + 29, EFL + 30, EFL + 31,
> !     CF_PC, -1
>     };

I think this needs a re-think.

In the above, half of core_reg_mapping[] is determined by the macro 
NFC_REGS.

Can you instead define both tables and select the correct one at runtime?


> Index: gdb/osfsolib.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/osfsolib.c,v
> retrieving revision 1.9
> diff -c -3 -p -r1.9 osfsolib.c
> *** osfsolib.c	2001/05/04 04:15:26	1.9
> --- osfsolib.c	2001/05/09 05:33:24
> *************** must be loaded manually, using `sharedli
> *** 933,935 ****
> --- 933,944 ----
>   		  &setlist),
>        &showlist);
>   }
> + 
> + 
> + int 
> + in_solib_dynsym_resolve_code (CORE_ADDR pc)
> + {
> +   /* This function is actually never used for the moment, but is needed
> +      because it is defined solib.h. We just return False all the time. */
> +   return 0;
> + }

I don't think this is necessary.  If the target is pulling in solib.h 
then it should probably link in solib.c.

--

With regard to needing an assignment, this is one is on the edge. ACT 
really do need to get their act (er groan) together and establish an 
assignment, even if it is only for future changes.

	Andrew