[RFC] Accomodate 64-bit msymbols in expressions

[RFC] Accomodate 64-bit msymbols in expressions

[Michael Snyder]

The following change is motivated by the fact that the addresses of
minimal symbols currently get truncated to 32 bits in expressions.

Does this look badly wrong to anybody?
2001-02-16  Michael Snyder  <msnyder@mvstp600e.cygnus.com>

	* parse.c (write_exp_msymbol): Make the type (long long), to 
	accomodate 64-bit addresses.

Index: parse.c
===================================================================
RCS file: /cvs/src/src/gdb/parse.c,v
retrieving revision 1.11
diff -c -3 -p -r1.11 parse.c
*** parse.c	2000/12/15 01:01:48	1.11
--- parse.c	2001/02/16 23:59:30
*************** static struct type *msym_data_symbol_typ
*** 403,415 ****
  static struct type *msym_unknown_symbol_type;
  
  void
! write_exp_msymbol (struct minimal_symbol *msymbol,
! 		   struct type *text_symbol_type, struct type *data_symbol_type)
  {
    CORE_ADDR addr;
  
    write_exp_elt_opcode (OP_LONG);
!   write_exp_elt_type (lookup_pointer_type (builtin_type_void));
  
    addr = SYMBOL_VALUE_ADDRESS (msymbol);
    if (overlay_debugging)
--- 403,417 ----
  static struct type *msym_unknown_symbol_type;
  
  void
! write_exp_msymbol (struct minimal_symbol *msymbol, 
! 		   struct type *text_symbol_type, 
! 		   struct type *data_symbol_type)
  {
    CORE_ADDR addr;
  
    write_exp_elt_opcode (OP_LONG);
!   /* Let's make the type big enough to hold a 64-bit address.  */
!   write_exp_elt_type (builtin_type_long_long);
  
    addr = SYMBOL_VALUE_ADDRESS (msymbol);
    if (overlay_debugging)
From chastain@cygnus.com Fri Feb 16 16:27:00 2001
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: gdb-patches@sources.redhat.com, jmoore@cygnus.com
Subject: Re: [RFA] Fix for gdb-gnats bug #14
Date: Fri, 16 Feb 2001 16:27:00 -0000
Message-id: <200102170027.QAA01551@bosch.cygnus.com>
X-SW-Source: 2001-02/msg00317.html
Content-length: 1480

I proofread this patch plus I tested on a Solaris 2.6 native with gcc
2.9-gnupro-99r1.  It works for me.

I recommend that the maintainers approve the patch as submitted.

But I have more comments ...

I note that the test has two branches: an hpux branch and a non-hpux
branch.  This is strange, because the underlying feature is not
target specific.

The hpux branch contains the correct expectatation: it expects the "step"
commands not to run.  I checked this by reading the test carefully and
also by examining test results:

  /tantor/build/gnupro-00r1/hppa1.1-hp-hpux10.20/tests/hppa1.1-hp-hpux10.20/010214/gdb/testsuite/gdb.log 
  /tantor/build/gnupro-00r1/sparc-sun-solaris2.6/tests/sparc-sun-solaris2.6/010204/gdb/testsuite/gdb.log 

So:

  . gdb always behaves as documented in the manual
  . the hpux version of the test is correct.
    gdb behaves as documented, and the test PASSes.
  . the non-hpux version of the test is incorrect.
    gdb behaves as documented, but the test FAILs.
  . your patch actually makes the non-hpux test the same as the hpux test

If you care to do more work, you could remove the hpux test, kill the
non-hpux expression completely, and use the hpux expression on all
platforms.

It's up to the maintainers (Stan Shebs and Fernando Nasser) whether
to accept the patch or remand it for more work.  I recommend accepting it
and then doing more work as a second patch.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

Re: [RFC] Accomodate 64-bit msymbols in expressions

[Kevin Buettner]

On Feb 16,  4:03pm, Michael Snyder wrote:

> The following change is motivated by the fact that the addresses of
> minimal symbols currently get truncated to 32 bits in expressions.
> 
> Does this look badly wrong to anybody?

Not badly wrong.  The only nit that I can pick is...

> !   /* Let's make the type big enough to hold a 64-bit address.  */
> !   write_exp_elt_type (builtin_type_long_long);

...that it might be preferable to use builtin_type_CORE_ADDR instead.

(I.e, think about what happens if TARGET_LONG_LONG_BIT == 32, but
TARGET_ADDR_BIT == 64.)

Kevin

Re: [RFC] Accomodate 64-bit msymbols in expressions

[Michael Snyder]

Kevin Buettner wrote:
> 
> On Feb 16,  4:03pm, Michael Snyder wrote:
> 
> > The following change is motivated by the fact that the addresses of
> > minimal symbols currently get truncated to 32 bits in expressions.
> >
> > Does this look badly wrong to anybody?
> 
> Not badly wrong.  The only nit that I can pick is...
> 
> > !   /* Let's make the type big enough to hold a 64-bit address.  */
> > !   write_exp_elt_type (builtin_type_long_long);
> 
> ...that it might be preferable to use builtin_type_CORE_ADDR instead.
> 
> (I.e, think about what happens if TARGET_LONG_LONG_BIT == 32, but
> TARGET_ADDR_BIT == 64.)

That's a good idea.  Thanks.