status of gdb on Tru64 5.1?

status of gdb on Tru64 5.1?

[Coleman, Michael]

Hi,

Does anyone know the status of gdb on Tru64 5.1?  Neither the latest release
nor the CVS head currently compile.  (The CVS head seems to have problems
with the register definitions used in alpha-nat.c:101-108.)

Any help appreciated,
Mike

Mike Coleman, Scientific Programmer, +1 816 926 4419
Stowers Institute for Biomedical Research, 1000 E. 50th St., Kansas City, MO
64110

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

[Andrew Cagney]

> On Thu, Sep 13, 2001 at 11:43:31AM +0200, Joel Brobecker wrote:
> 
>> > Now, the executable I got did not work properly. I can
>> > start it, load a file, but the command 'run' crashes the
>> > program (see prototypical session below.)
> 
>> 
>> Try the most recent sources, they should contain the changes that will
>> allow you to compile GDB on your plateform. Let me know if it doesn't,
>> I'll try to help you out.
> 
> 
> Most recent as in the 5.1 branch or HEAD?

Is there an update on this? I.e. does GDB work on True64?  (hmm, 
perhaphs, I've already asked this question).

Andrew

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

[Joel Brobecker]

> Is there an update on this? I.e. does GDB work on True64?  (hmm, 
> perhaphs, I've already asked this question).

I recently sent the following message to somebody enquiring the status
of GDB on Tru64:
<<
> Does anyone know if/when the tru64 5.1 patch for gdb will be added?  I just
> pulled down the latest CVS and it's not in there.

I am not clear about the patch you are talking about. The first patch I
submitted for Tru64 5.1 did not meet the GDB standards. For one thing, I
had to break it down into smaller pieces. But most of the important
changes were better done by Nick Duffeck, so his changes were checked
in, and I only integrated small pieces that his patch did not contain.
      
> Alternatively, if Joel's patch works, can one of you send me the
> alpha-osf5.mh patch (or diff from alpha-osf3.mh)?  (It wasn't included in
> Joel's original post.)
      
The bad news is that I just tried today's snapshot and I also failed to
build it. I don't think this is because of the lack of the
alpha-osf5.mh. For me, the build failed in alpha-nat.c, where it fails
to find the EF_* macros. This is probably a minor problem, these macros
are defined inside /usr/include/machine/reg.h (BTW, on our machine,
"machine" is actually a link to "alpha"). And it is #include'd from
alpha-nat.c, they are just conditionalized by

   #if defined(_KERNEL) || defined(_EXCEPTION_FRAME)
        
I unfortunately don't have much more time at the moment to help you more
on this issue. I hope this will help you making some progress.
>>

I'm not sure anymore, but I thought that Nick's patch was allowing GDB
to build on both Tru64 4.0 and 5.1... Strangely, I even remember being
able to rebuild it myself on our machines. Either I have incorrect
memories, or maybe a later change broke the build, or we forgot
to check-in something.

For the compilation problem, I still have the original fix that I sent
with my first message. I can clean it to satisfy Andrew's comments, and
resubmit it. But I would prefer to some feedback from others, to see if
they have the same build problems or not. At the moment, I am still
unclear whether it is local to our machine, or a forgotten change.

-- 
Joel

Re: status of gdb on Tru64 5.1?

[gdb]

On Tue, Sep 25, 2001 at 08:58:55AM -0500, Coleman, Michael wrote:
> Does anyone know the status of gdb on Tru64 5.1?  Neither the latest release
> nor the CVS head currently compile.  (The CVS head seems to have problems
> with the register definitions used in alpha-nat.c:101-108.)

I can build the 5.1 branch on Tru64 UNIX 5.1. I have not tested yet
though.

-- 
albert chin (china@thewrittenword.com)

Re: status of gdb on Tru64 5.1?

[gdb]

On Thu, Sep 27, 2001 at 09:39:35AM -0500, gdb@thewrittenword.com wrote:
> On Tue, Sep 25, 2001 at 08:58:55AM -0500, Coleman, Michael wrote:
> > Does anyone know the status of gdb on Tru64 5.1?  Neither the latest release
> > nor the CVS head currently compile.  (The CVS head seems to have problems
> > with the register definitions used in alpha-nat.c:101-108.)
> 
> I can build the 5.1 branch on Tru64 UNIX 5.1. I have not tested yet
> though.

Oops, scratch that:
cc -c -std    -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode
-I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl
-I./../intl  -DMI_OUT=1 -DUI_OUT=1   alpha-nat.c
cc: Error: alpha-nat.c, line 101: In the initializer for
core_reg_mapping[0], "EF_V0" is not declared. (undeclared)
    EF_V0, EF_T0, EF_T1, EF_T2, EF_T3, EF_T4, EF_T5, EF_T6,
----^
cc: Error: alpha-nat.c, line 101: In the initializer for
core_reg_mapping[1], "EF_T0" is not declared. (undeclared)
    EF_V0, EF_T0, EF_T1, EF_T2, EF_T3, EF_T4, EF_T5, EF_T6,
-----------^
cc: Error: alpha-nat.c, line 101: In the initializer for
core_reg_mapping[2], "EF_T1" is not declared. (undeclared)
...

-- 
albert chin (china@thewrittenword.com)

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

[gdb]

On Thu, Sep 27, 2001 at 10:03:10AM +0200, Joel Brobecker wrote:
> > Is there an update on this? I.e. does GDB work on True64?  (hmm, 
> > perhaphs, I've already asked this question).
> 
> I recently sent the following message to somebody enquiring the status
> of GDB on Tru64:
> <<
> > Does anyone know if/when the tru64 5.1 patch for gdb will be added?  I just
> > pulled down the latest CVS and it's not in there.
> 
> I am not clear about the patch you are talking about. The first patch I
> submitted for Tru64 5.1 did not meet the GDB standards. For one thing, I
> had to break it down into smaller pieces. But most of the important
> changes were better done by Nick Duffeck, so his changes were checked
> in, and I only integrated small pieces that his patch did not contain.
>       
> > Alternatively, if Joel's patch works, can one of you send me the
> > alpha-osf5.mh patch (or diff from alpha-osf3.mh)?  (It wasn't included in
> > Joel's original post.)
>       
> The bad news is that I just tried today's snapshot and I also failed to
> build it. I don't think this is because of the lack of the
> alpha-osf5.mh. For me, the build failed in alpha-nat.c, where it fails
> to find the EF_* macros. This is probably a minor problem, these macros
> are defined inside /usr/include/machine/reg.h (BTW, on our machine,
> "machine" is actually a link to "alpha"). And it is #include'd from
> alpha-nat.c, they are just conditionalized by
> 
>    #if defined(_KERNEL) || defined(_EXCEPTION_FRAME)

There is one #define that changed with 5.1 (from <machine/reg.h>:
#undef EF_SP                    /* r30: stack pointer (see note above) */

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.

-- 
albert chin (china@thewrittenword.com)

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

[Joel Brobecker]

> 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