patch to gdb on Tru64 5.1

patch to gdb on Tru64 5.1

[Joel Brobecker]

Hi,

I am an employee of Ada Core Technologies, Inc, and I've done some work
on gdb to make it work on Tru64 5.1 (it currently does not compile on
this plateform). ACT is happy to contribute the changes that we made in
the hope that it will be useful to others.

Here is the patch agains the latest CVS sources that will allow gdb to
compile and work on Tru64 5.1 using the native cc compiler. I don't know
if it will successfully build with gcc.

On top of the patch, there is this new file 'alpha-osf5.mh' in
'gdb/config/alpha' that will need to be created. I am attaching it as
well.

The ChangeLog:

alpha-nat.c:
------------
fetch_osf_core_registers: adapt the table used to map the regnum to
 the core register section index to work on Tru64 5.1 as well.

configure.host:
---------------
set gdb_host to alpha-osf5 for Tru64 5+ (instead of alpha-osf3).

osfsolib.c:
-----------
in_solib_dynsym_resolve_code: provide a dummy implementation for this
 function. It is not used on Tru64, but is needed anyway to avoid
 undefined symbols (it is declared in solib.h, which is not target
 dependent). The best approach is probably to conditionalize the
 definition of this procedure in solib.h so that it is not defined
 when building on Tru64 5+, but I am not sure how to do that yet.

alpha-osf5.mh:
--------------
new file. This is a modified version of alpha-osf3.mh where
 -DUSE_LDR_ROUTINES is added to the compilation flags. This forces gdb to
 use the xproc library to load the symbols, instead of relying on an
 empirical algorithm (which does not work on Tru64 5.1 anymore). Added
 the associated linking flags to NAT_CLIBS.

Cheers,
-- 
Joel
From kettenis@wins.uva.nl Wed May 09 03:00:00 2001
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sources.redhat.com
Subject: [PATCH]: More macro-into-function conversion for x86
Date: Wed, 09 May 2001 03:00:00 -0000
Message-id: <200105090959.f499xkE02434@delius.kettenis.local>
X-SW-Source: 2001-05/msg00120.html
Content-length: 3812

Checked in.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* i386-tdep.c (i386_register_virtual_type): New function.
	(i386_register_convertible): New function.
	* config/i386/tm-i386.h (REGISTER_VIRTUAL_TYPE): Redefine in terms
	of i386_register_virtual_type.
	(REGISTER_CONVERTIBLE): Redefine in terms of
	i386_register_convertible.
	(i386_register_virtual_type, i386_register_convertible): New
	prototypes.

Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.29
diff -u -p -r1.29 i386-tdep.c
--- i386-tdep.c 2001/04/19 11:39:47 1.29
+++ i386-tdep.c 2001/05/09 09:56:37
@@ -905,6 +905,37 @@ i386_extract_struct_value_address (char 
 }
 \f
 
+/* Return the GDB type object for the "standard" data type of data in
+   register REGNUM.  Perhaps %esi and %edi should go here, but
+   potentially they could be used for things other than address.  */
+
+struct type *
+i386_register_virtual_type (int regnum)
+{
+  if (regnum == PC_REGNUM || regnum == FP_REGNUM || regnum == SP_REGNUM)
+    return lookup_pointer_type (builtin_type_void);
+
+  if (IS_FP_REGNUM (regnum))
+    return builtin_type_long_double;
+
+  if (IS_SSE_REGNUM (regnum))
+    return builtin_type_v4sf;
+
+  return builtin_type_int;
+}
+
+/* Return true iff register REGNUM's virtual format is different from
+   its raw format.  Note that this definition assumes that the host
+   supports IEEE 32-bit floats, since it doesn't say that SSE
+   registers need conversion.  Even if we can't find a counterexample,
+   this is still sloppy.  */
+
+int
+i386_register_convertible (int regnum)
+{
+  return IS_FP_REGNUM (regnum);
+}
+
 /* Convert data from raw format for register REGNUM in buffer FROM to
    virtual format with type TYPE in buffer TO.  In principle both
    formats are identical except that the virtual format has two extra
Index: config/i386/tm-i386.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v
retrieving revision 1.17
diff -u -p -r1.17 tm-i386.h
--- config/i386/tm-i386.h 2001/04/19 11:39:48 1.17
+++ config/i386/tm-i386.h 2001/05/09 09:56:37
@@ -238,23 +238,17 @@ extern int i386_register_virtual_size[];
 /* Largest value REGISTER_VIRTUAL_SIZE can have.  */
 #define MAX_REGISTER_VIRTUAL_SIZE 16
 
-/* Return the GDB type object for the "standard" data type of data in 
-   register N.  Perhaps si and di should go here, but potentially they
-   could be used for things other than address.  */
+/* Return the GDB type object for the "standard" data type of data in
+   register REGNUM.  */
 
-#define REGISTER_VIRTUAL_TYPE(N)				\
-  (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM)	\
-   ? lookup_pointer_type (builtin_type_void)			\
-   : IS_FP_REGNUM(N) ? builtin_type_long_double			\
-   : IS_SSE_REGNUM(N) ? builtin_type_v4sf			\
-   : builtin_type_int)
+#define REGISTER_VIRTUAL_TYPE(regnum) i386_register_virtual_type (regnum)
+extern struct type *i386_register_virtual_type (int regnum);
 
-/* REGISTER_CONVERTIBLE(N) is true iff register N's virtual format is
-   different from its raw format.  Note that this definition assumes
-   that the host supports IEEE 32-bit floats, since it doesn't say
-   that SSE registers need conversion.  Even if we can't find a
-   counterexample, this is still sloppy.  */
-#define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n))
+/* Return true iff register REGNUM's virtual format is different from
+   its raw format.  */
+
+#define REGISTER_CONVERTIBLE(regnum) i386_register_convertible (regnum)
+extern int i386_register_convertible (int regnum);
 
 /* Convert data from raw format for register REGNUM in buffer FROM to
    virtual format with type TYPE in buffer TO.  */

Re: patch to gdb on Tru64 5.1

[Christopher Faylor]

On Wed, May 09, 2001 at 08:22:28AM +0200, Joel Brobecker wrote:
>Hi,
>
>I am an employee of Ada Core Technologies, Inc, and I've done some work
>on gdb to make it work on Tru64 5.1 (it currently does not compile on
>this plateform). ACT is happy to contribute the changes that we made in
>the hope that it will be useful to others.
>
>Here is the patch agains the latest CVS sources that will allow gdb to
>compile and work on Tru64 5.1 using the native cc compiler. I don't know
>if it will successfully build with gcc.
>
>On top of the patch, there is this new file 'alpha-osf5.mh' in
>'gdb/config/alpha' that will need to be created. I am attaching it as
>well.

I just checked and I don't see any assignments with the FSF for gdb work
from ACT.  This is sort of surprising since I believe that there are two
ACT representatives on the GDB steering committee.  Maybe I missed
something or maybe this is another ACT.

Anyway, IMO, you'll need an assignment with the FSF if you want to get
your change into the official gdb.  This change is around thirty lines
or so and adds a new file and so I believe it does not qualify as a
trivial patch.

If you do decide to submit this formally, you'll also want to submit a
true ChangeLog entry in the accepted format.  Check out the gdb web site
at http://sources.redhat.com/gdb/ for pointers on how to do this.

cgf

Re: patch to gdb on Tru64 5.1

[Joel Brobecker]

> I just checked and I don't see any assignments with the FSF for gdb work
> from ACT.  This is sort of surprising since I believe that there are two
> ACT representatives on the GDB steering committee.  Maybe I missed
> something or maybe this is another ACT.

Yes, it is surprising. I will ask Robert Dewar to clear things out as
quickly as possible.

> If you do decide to submit this formally, you'll also want to submit a
> true ChangeLog entry in the accepted format.  Check out the gdb web site
> at http://sources.redhat.com/gdb/ for pointers on how to do this.

Right, thanks for the pointer.

-- 
Joel

Re: patch to gdb on Tru64 5.1

[Jim Blandy]

Joel Brobecker <brobecker@act-europe.fr> writes:
> I am an employee of Ada Core Technologies, Inc, and I've done some work
> on gdb to make it work on Tru64 5.1 (it currently does not compile on
> this plateform). ACT is happy to contribute the changes that we made in
> the hope that it will be useful to others.

I've sent him the FSF copyright assignment form.

Re: patch to gdb on Tru64 5.1

[Christopher Faylor]

On Wed, May 09, 2001 at 07:57:01PM +0200, Joel Brobecker wrote:
>> I just checked and I don't see any assignments with the FSF for gdb work
>> from ACT.  This is sort of surprising since I believe that there are two
>> ACT representatives on the GDB steering committee.  Maybe I missed
>> something or maybe this is another ACT.
>
>Yes, it is surprising. I will ask Robert Dewar to clear things out as
>quickly as possible.

Rober Dewar does have an assignment (of course) but it is only for GCC:

ANY GNAT GCC    Ada Core Technologies   2001-02-11
Assigns past and future changes to FSF-owned software (GNAT 1995-present).
(Robert Dewar)

cgf

Re: patch to gdb on Tru64 5.1

[Andrew Cagney]

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

Re: patch to gdb on Tru64 5.1

[Andrew Cagney]

 > I just checked and I don't see any assignments with the FSF for gdb
 > work from ACT.  This is sort of surprising since I believe that
 > there are two ACT representatives on the GDB steering committee.
 > Maybe I missed something or maybe this is another ACT.
 >
 > Anyway, IMO, you'll need an assignment with the FSF if you want to
 > get your change into the official gdb.  This change is around
 > thirty lines or so and adds a new file and so I believe it does not
 >  qualify as a trivial patch.

Look at it as several, largely independant, patches (as it should have 
been submitted).

Some(the configury ones) wouldn't need an assignment since they are 
obvious.  The final change to alpha-nat.c, however, could be
more interesting.

Andrew

Re: patch to gdb on Tru64 5.1

[Nick Duffek]

Hi,

On 9-May-2001, Joel Brobecker wrote:

>I am an employee of Ada Core Technologies, Inc, and I've done some work
>on gdb to make it work on Tru64 5.1 (it currently does not compile on
>this plateform).

Recently I did the same thing.

>alpha-nat.c:
>------------
>fetch_osf_core_registers: adapt the table used to map the regnum to
> the core register section index to work on Tru64 5.1 as well.

I did that slightly differently:

@@ -95,16 +95,19 @@ fetch_osf_core_registers (char *core_reg
      The floating point register values are garbage in OSF/1.2 core files.  */
   static int core_reg_mapping[NUM_REGS] =
   {
-#define EFL (EF_SIZE / 8)
-    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,
-    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,
-    EF_PC, -1
+    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,
+    NCF_REGS + 0, NCF_REGS + 1, NCF_REGS + 2, NCF_REGS + 3,
+    NCF_REGS + 4, NCF_REGS + 5, NCF_REGS + 6, NCF_REGS + 7,
+    NCF_REGS + 8, NCF_REGS + 9, NCF_REGS + 10, NCF_REGS + 11,
+    NCF_REGS + 12, NCF_REGS + 13, NCF_REGS + 14, NCF_REGS + 15,
+    NCF_REGS + 16, NCF_REGS + 17, NCF_REGS + 18, NCF_REGS + 19,
+    NCF_REGS + 20, NCF_REGS + 21, NCF_REGS + 22, NCF_REGS + 23,
+    NCF_REGS + 24, NCF_REGS + 25, NCF_REGS + 26, NCF_REGS + 27,
+    NCF_REGS + 28, NCF_REGS + 29, NCF_REGS + 30, NCF_REGS + 31,
+    CF_PC, -1
   };
   static char zerobuf[MAX_REGISTER_RAW_SIZE] =
   {0};

I think that approach addresses Andrew's comment about mixing EF macros
with CF ones.

>alpha-osf5.mh:
>--------------
>new file. This is a modified version of alpha-osf3.mh where
> -DUSE_LDR_ROUTINES is added to the compilation flags. This forces gdb to
> use the xproc library to load the symbols, instead of relying on an
> empirical algorithm (which does not work on Tru64 5.1 anymore).

That didn't work when I tried it, because the xproc routines only allow a
process to examine itself.  It _seems_ to work because GDB happens to load
the same shared libraries as most programs it debugs (libc.so and
libm.so), but it doesn't when debugging programs linked against other
shared libs.

I'll post an alternative patch for shared library support in a separate
message.

Nick

Re: patch to gdb on Tru64 5.1

[Joel Brobecker]

> > 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.

I tried to compile the code on a machine running 4.0f, and it actually
works much better with this change.

> 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?

I don't understand your suggestion. The conditionalization is needed in
order to successfully compile on Tru64 5.1. If I had 2 tables, one of
them would not compile.

-- 
Joel

Re: patch to gdb on Tru64 5.1

[Joel Brobecker]

> >alpha-nat.c:
> >------------
> >fetch_osf_core_registers: adapt the table used to map the regnum to
> > the core register section index to work on Tru64 5.1 as well.
> 
> I did that slightly differently:

Thanks for you suggestion. However, I tried your change, but then I
could not build gdb on Dec Unix 4.0f...

> >alpha-osf5.mh:
> >--------------
> >new file. This is a modified version of alpha-osf3.mh where
> > -DUSE_LDR_ROUTINES is added to the compilation flags. This forces gdb to
> > use the xproc library to load the symbols, instead of relying on an
> > empirical algorithm (which does not work on Tru64 5.1 anymore).
> 
> That didn't work when I tried it, because the xproc routines only allow a
> process to examine itself.  It _seems_ to work because GDB happens to load
> the same shared libraries as most programs it debugs (libc.so and
> libm.so), but it doesn't when debugging programs linked against other
> shared libs.
> 
> I'll post an alternative patch for shared library support in a separate
> message.

I am looking forward to it.

-- 
Joel

Re: patch to gdb on Tru64 5.1

[Nick Duffek]

On 11-May-2001, Joel Brobecker wrote:

>Thanks for you suggestion. However, I tried your change, but then I
>could not build gdb on Dec Unix 4.0f...

Yes, sorry about that, I think your patch is better after all.

Nick

Re: patch to gdb on Tru64 5.1

[Andrew Cagney]

>> 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?
> 
> 
> I don't understand your suggestion. The conditionalization is needed in
> order to successfully compile on Tru64 5.1. If I had 2 tables, one of
> them would not compile.

I've two requests:

	o	per NickD's post, could the table be initialised
		as either two separate entries, a single simple
		table.  Not something that is split down the middle
		by a #if/#else/#endif

	o	is it possible to compile in both tables
		so that the correct table can be selected
		at run time.  In theory allowing GDB to
		handle both 4.x and 5.x core files.

It sounds like the second one isn't going to fly.

To give some background to my second request, GDB is moving away from 
the good old days where it was always built/configured for a very 
specific host/target combination. Depending on that combination, certain 
features would, or would not be available.  For instance, 
shared-library, thread and core file support were all once native-only. 
  For an increasing number of targets, that is no longer the case.

	enjoy,
		Andrew

Re: patch to gdb on Tru64 5.1

[Nick Duffek]

On 11-May-2001, Andrew Cagney wrote:

>	o	is it possible to compile in both tables
>		so that the correct table can be selected
>		at run time.  In theory allowing GDB to
>		handle both 4.x and 5.x core files.

There's only one table.  In the transition from 4.x to 5.x, EF_* #defines
in system header files were renamed to CF_*, but their values didn't
change.  Therefore, a single table allows GDB to handle both 4.x and 5.x
core files.

Maybe a comment to that effect would be enough to prevent future
confusion?

Nick