This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: patch to gdb on Tru64 5.1
- To: Joel Brobecker <brobecker at act-europe dot fr>
- Subject: Re: patch to gdb on Tru64 5.1
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 09 May 2001 17:37:35 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <20010509082227.E23184@act-europe.fr>
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