From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: gdb-patches@sources.redhat.com Cc: keiths@redhat.com, kevinb@redhat.com Subject: [RFC] Accomodate 64-bit msymbols in expressions Date: Fri, 16 Feb 2001 16:04:00 -0000 Message-id: <3A8DBFEF.45B230C1@cygnus.com> X-SW-Source: 2001-02/msg00316.html 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 * 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 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 "love without fear"