Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "J. Johnston" <jjohnstn@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: frame id enhancement
Date: Fri, 17 Oct 2003 16:32:00 -0000	[thread overview]
Message-ID: <3F9019A6.30109@redhat.com> (raw)
In-Reply-To: <3F8FEF0B.7000104@redhat.com>

Patch checked into mainline.  Thanks.

-- Jeff J.

Andrew Cagney wrote:
> 
>> Is the revised attached patch ok?
> 
> 
> Yep, now I understand it.  Thanks.
> 
> Andrew
> 
> ex: frame.h
> 
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/frame.h,v
>> retrieving revision 1.110
>> diff -u -r1.110 frame.h
>> --- frame.h    10 Oct 2003 00:32:04 -0000    1.110
>> +++ frame.h    16 Oct 2003 23:30:50 -0000
>> @@ -95,8 +95,6 @@
>>       is used.  Watch out for all the legacy targets that still use the
>>       function pointer register or stack pointer register.  They are
>>       wrong.  */
>> -  /* NOTE: cagney/2002-11-16: The ia64 has two stacks and hence two
>> -     frame bases.  This will need to be expanded to accomodate that.  */
>>    CORE_ADDR stack_addr;
>>    /* The frame's code address.  This shall be constant through out the
>>       lifetime of the frame.  While the PC (a.k.a. resume address)
>> @@ -104,15 +102,33 @@
>>       Typically, it is set to the address of the entry point of the
>>       frame's function (as returned by frame_func_unwind().  */
>>    CORE_ADDR code_addr;
>> +  /* The frame's special address.  This shall be constant through out 
>> the
>> +     lifetime of the frame.  This is used for architectures that may 
>> have
>> +     frames that do not change the stack but are still distinct and 
>> have +     some form of distinct identifier (e.g. the ia64 which uses 
>> a 2nd +     stack for registers).  This field is treated as unordered 
>> - i.e. will
>> +     not be used in frame ordering comparisons such as frame_id_inner().
>> +     A zero in this field will be treated as a wild-card when comparing
>> +     frames for equality.  */
>> +  CORE_ADDR special_addr;
>>  };
>>  
>>  /* Methods for constructing and comparing Frame IDs.
>>  
>> -   NOTE: Given frameless functions A and B, where A calls B (and hence
>> +   NOTE: Given stackless functions A and B, where A calls B (and hence
>>     B is inner-to A).  The relationships: !eq(A,B); !eq(B,A);
>> -   !inner(A,B); !inner(B,A); all hold.  This is because, while B is
>> -   inner to A, B is not strictly inner to A (being frameless, they
>> -   have the same .base value).  */
>> +   !inner(A,B); !inner(B,A); all hold.
>> +
>> +   This is because, while B is inner-to A, B is not strictly inner-to 
>> A.  +   Being stackless, they have an identical .stack_addr value, and 
>> differ +   only by their unordered .code_addr and/or .special_addr 
>> values.
>> +
>> +   Because frame_id_inner is only used as a safety net (e.g.,
>> +   detect a corrupt stack) the lack of strictness is not a problem.
>> +   Code needing to determine an exact relationship between two frames
>> +   must instead use frame_id_eq and frame_id_unwind.  For instance,
>> +   in the above, to determine that A stepped-into B, the equation
>> +   "A.id != B.id && A.id == id_unwind (B)" can be used.  */
>>  
>>  /* For convenience.  All fields are zero.  */
>>  extern const struct frame_id null_frame_id;
>> @@ -120,9 +136,20 @@
>>  /* Construct a frame ID.  The first parameter is the frame's constant
>>     stack address (typically the outer-bound), and the second the
>>     frame's constant code address (typically the entry point) (or zero,
>> -   to indicate a wild card).  */
>> +   to indicate a wild card).  The special identifier address is
>> +   defaulted to zero.  */
>>  extern struct frame_id frame_id_build (CORE_ADDR stack_addr,
>>                         CORE_ADDR code_addr);
>> +
>> +/* Construct a special frame ID.  The first parameter is the frame's 
>> constant
>> +   stack address (typically the outer-bound), the second is the
>> +   frame's constant code address (typically the entry point) (or zero,
>> +   to indicate a wild card), and the third parameter is the frame's
>> +   special identifier address (or zero to indicate a wild card or +   
>> unused default).  */
>> +extern struct frame_id frame_id_build_special (CORE_ADDR stack_addr,
>> +                           CORE_ADDR code_addr,
>> +                           CORE_ADDR special_addr);
>>  
>>  /* Returns non-zero when L is a valid frame (a valid frame has a
>>     non-zero .base).  */
>> Index: frame.c
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/frame.c,v
>> retrieving revision 1.145
>> diff -u -r1.145 frame.c
>> --- frame.c    2 Oct 2003 20:28:29 -0000    1.145
>> +++ frame.c    16 Oct 2003 23:30:51 -0000
>> @@ -144,9 +144,10 @@
>>  void
>>  fprint_frame_id (struct ui_file *file, struct frame_id id)
>>  {
>> -  fprintf_unfiltered (file, "{stack=0x%s,code=0x%s}",
>> +  fprintf_unfiltered (file, "{stack=0x%s,code=0x%s,special=0x%s}",
>>                paddr_nz (id.stack_addr),
>> -              paddr_nz (id.code_addr));
>> +              paddr_nz (id.code_addr),
>> +              paddr_nz (id.special_addr));
>>  }
>>  
>>  static void
>> @@ -256,14 +257,22 @@
>>  const struct frame_id null_frame_id; /* All zeros.  */
>>  
>>  struct frame_id
>> -frame_id_build (CORE_ADDR stack_addr, CORE_ADDR code_addr)
>> +frame_id_build_special (CORE_ADDR stack_addr, CORE_ADDR code_addr,
>> +                        CORE_ADDR special_addr)
>>  {
>>    struct frame_id id;
>>    id.stack_addr = stack_addr;
>>    id.code_addr = code_addr;
>> +  id.special_addr = special_addr;
>>    return id;
>>  }
>>  
>> +struct frame_id
>> +frame_id_build (CORE_ADDR stack_addr, CORE_ADDR code_addr)
>> +{
>> +  return frame_id_build_special (stack_addr, code_addr, 0);
>> +}
>> +
>>  int
>>  frame_id_p (struct frame_id l)
>>  {
>> @@ -292,8 +301,14 @@
>>    else if (l.code_addr == 0 || r.code_addr == 0)
>>      /* A zero code addr is a wild card, always succeed.  */
>>      eq = 1;
>> -  else if (l.code_addr == r.code_addr)
>> -    /* The .stack and .code are identical, the ID's are identical.  */
>> +  else if (l.code_addr != r.code_addr)
>> +    /* If .code addresses are different, the frames are different.  */
>> +    eq = 0;
>> +  else if (l.special_addr == 0 || r.special_addr == 0)
>> +    /* A zero special addr is a wild card (or unused), always 
>> succeed.  */
>> +    eq = 1;
>> +  else if (l.special_addr == r.special_addr)
>> +    /* Frames are equal.  */
>>      eq = 1;
>>    else
>>      /* No luck.  */
>> @@ -320,7 +335,7 @@
>>      /* Only return non-zero when strictly inner than.  Note that, per
>>         comment in "frame.h", there is some fuzz here.  Frameless
>>         functions are not strictly inner than (same .stack but
>> -       different .code).  */
>> +       different .code and/or .special address).  */
>>      inner = INNER_THAN (l.stack_addr, r.stack_addr);
>>    if (frame_debug)
>>      {
> 
> 
> 
> 


  reply	other threads:[~2003-10-17 16:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-06 21:15 J. Johnston
2003-10-14 21:59 ` J. Johnston
2003-10-15 21:09 ` Andrew Cagney
2003-10-15 23:12   ` J. Johnston
2003-10-16 16:09     ` Andrew Cagney
2003-10-16 19:06       ` J. Johnston
2003-10-16 21:06         ` Andrew Cagney
2003-10-16 21:49           ` J. Johnston
2003-10-16 23:32             ` J. Johnston
2003-10-17 13:30               ` Andrew Cagney
2003-10-17 16:32                 ` J. Johnston [this message]
2003-10-17 18:11             ` Kevin Buettner
2003-10-17 19:34               ` J. Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F9019A6.30109@redhat.com \
    --to=jjohnstn@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox