Re: [5.1] Re: status of gdb on Tru64 5.1?

[Joel Brobecker <brobecker@act-europe.fr>]

> And the "note above" says:
>  * Note that the presence of a definition for EF_SP is used by locore.s
>  * to determine whether M_SP should be specified in ".mask" directives,
>  * and the setting of this bit 30 in the relevant procedure descriptor
>  * "regmask" is the basis for debuggers to interpret kernel exception
>  * frames in the old (33-quadword) or new (32-quadword) format.
> 
> So, just -D_EXCEPTION_FRAME isn't the only fix.

In our version of GDB, here is how we define the array. I originally
posted that and there have been legitimate comments saying that this was
ugly code...
<<
  static int core_reg_mapping[NUM_REGS] =
  {
#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
  };
>>

The least that I can do to make it a little bit less ugly is to rework
the code like this

| #ifdef NCF_REGS
|   static int core_reg_mapping[NUM_REGS] =
|   {
|     CF_V0, CF_T0, ...
|   };
| #else
| #define EFL (EF_SIZE / 8)
| #define CF_PC EF_PC
|   static int core_reg_mapping[NUM_REGS] =
|   {
|     EF_V0, EF_T0, ...
|   };
| #endif

I never worried about this so far because I was convinced that all this
issue was already dealt with. If you want to give it a try, you will
also need to change the #includes. Here is what I have:

<<
#include "defs.h"
#include "inferior.h"
#include "gdbcore.h"
#include "target.h"
#include <sys/ptrace.h>
#ifdef __linux__
#include <asm/reg.h>
#include <alpha/ptrace.h>
#else
#include <alpha/coreregs.h>
#endif
#include <sys/user.h>
>>

I am hoping that it would be possible to avoid including
alpha/coreregs.h. I never investigated this myself, since I thought
GDB was now building correctly on those Tru64 targets...

If nobody can have a look at this but me, I'll add this to my list of
things to do (I already have another bug on this target that I want to
kill).

-- 
Joel