[rfc] more findvar harvard fixes

[rfc] more findvar harvard fixes

[Andrew Cagney]

Hello,

The attached patch follows through a few harvard architecture problems 
Nick Duffek and Jim Blandy worked though in the recent thread:

http://sources.redhat.com/ml/gdb-patches/2001-07/msg00382.html

Given I think I'm just finishing these changes, I think this is pretty 
obvious so I'll check it in in a few days.

Look ok to people.

	Andrew
From ac131313@cygnus.com Sat Sep 22 16:09:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Kevin Buettner <kevinb@cygnus.com>, Fernando Nasser <fnasser@cygnus.com>, jason-swarelist@molenda.com, gdb-patches@sources.redhat.com, tromey@cygnus.com
Subject: Re: [RFA] Version 2 of patch to add 'maint profile-gdb' command
Date: Sat, 22 Sep 2001 16:09:00 -0000
Message-id: <3BAD1A02.1000702@cygnus.com>
References: <Pine.SUN.3.91.1010920101719.3922A-100000@is>
X-SW-Source: 2001-09/msg00304.html
Content-length: 692

> On Wed, 19 Sep 2001, Kevin Buettner wrote:
> 
> 
>> I like having the maintenance commands all lumped under "maint".  That
>> way I can use tab completion to see all of the maintenance related commands
>> when I do
>> 
>> (gdb) maint <TAB>
>> 
>> I think a set/show would be useful for some activities; couldn't
>> we add "maint set ..." and "maint show ..."  ?
> 
> 
> That seems to be a good idea, IMHO.

Turns out there is already a ``maint info'' so a ``maint set/show'' 
makes good sense.  Try the attached.

Jason, I think it is pretty clear where to add the profiling bit :-)
Eli, if the doco entry is going in gdb.texinfo, can you suggest where?
Fernando, is this part ok?

Andrew

Re: [rfc] more findvar harvard fixes

[Michael Snyder]

Andrew Cagney wrote:
> 
> Hello,
> 
> The attached patch follows through a few harvard architecture problems
> Nick Duffek and Jim Blandy worked though in the recent thread:
> 
> http://sources.redhat.com/ml/gdb-patches/2001-07/msg00382.html
> 
> Given I think I'm just finishing these changes, I think this is pretty
> obvious so I'll check it in in a few days.
> 
> Look ok to people.
> 
>         Andrew

Looks reasonably sane to me.  ;-)

> 
>   ----------------------------------------------------------------------------------------------------
> 2001-09-22  Andrew Cagney  <ac131313@redhat.com>
> 
>         * findvar.c (read_var_value): For LOC_INDIRECT and LOC_REF_ARG
>         convert the pointer into a CORE_ADDRs.
> 
> Index: findvar.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/findvar.c,v
> retrieving revision 1.22
> diff -p -r1.22 findvar.c
> *** findvar.c   2001/08/01 18:39:23     1.22
> --- findvar.c   2001/09/22 21:00:33
> *************** read_var_value (register struct symbol *
> *** 471,488 ****
>         break;
> 
>       case LOC_INDIRECT:
> !       /* The import slot does not have a real address in it from the
> !          dynamic loader (dld.sl on HP-UX), if the target hasn't begun
> !          execution yet, so check for that. */
> !       if (!target_has_execution)
> !       error ("\
>   Attempt to access variable defined in different shared object or load module when\n\
>   addresses have not been bound by the dynamic loader. Try again when executable is running.");
> 
> !       addr = SYMBOL_VALUE_ADDRESS (var);
> !       addr = read_memory_unsigned_integer
> !       (addr, TARGET_PTR_BIT / TARGET_CHAR_BIT);
> !       break;
> 
>       case LOC_ARG:
>         if (frame == NULL)
> --- 471,491 ----
>         break;
> 
>       case LOC_INDIRECT:
> !       {
> !       /* The import slot does not have a real address in it from the
> !          dynamic loader (dld.sl on HP-UX), if the target hasn't
> !          begun execution yet, so check for that. */
> !       CORE_ADDR locaddr;
> !       struct value *loc;
> !       if (!target_has_execution)
> !         error ("\
>   Attempt to access variable defined in different shared object or load module when\n\
>   addresses have not been bound by the dynamic loader. Try again when executable is running.");
> 
> !       locaddr = SYMBOL_VALUE_ADDRESS (var);
> !       loc = value_at (lookup_pointer_type (type), locaddr, NULL);
> !       addr = value_as_pointer (loc);
> !       }
> 
>       case LOC_ARG:
>         if (frame == NULL)
> *************** addresses have not been bound by the dyn
> *** 494,508 ****
>         break;
> 
>       case LOC_REF_ARG:
> !       if (frame == NULL)
> !       return 0;
> !       addr = FRAME_ARGS_ADDRESS (frame);
> !       if (!addr)
> !       return 0;
> !       addr += SYMBOL_VALUE (var);
> !       addr = read_memory_unsigned_integer
> !       (addr, TARGET_PTR_BIT / TARGET_CHAR_BIT);
> !       break;
> 
>       case LOC_LOCAL:
>       case LOC_LOCAL_ARG:
> --- 497,515 ----
>         break;
> 
>       case LOC_REF_ARG:
> !       {
> !       struct value *ref;
> !       CORE_ADDR argref;
> !       if (frame == NULL)
> !         return 0;
> !       argref = FRAME_ARGS_ADDRESS (frame);
> !       if (!argref)
> !         return 0;
> !       argref += SYMBOL_VALUE (var);
> !       ref = value_at (lookup_pointer_type (type), argref, NULL);
> !       addr = value_as_pointer (ref);
> !       break;
> !       }
> 
>       case LOC_LOCAL:
>       case LOC_LOCAL_ARG:

Re: [rfc] more findvar harvard fixes

[Andrew Cagney]

>> Andrew
> 
> 
> Looks reasonably sane to me.   [;-)] 
> 
  Thanks for looking at it, I've checked it in.

Andrew