Re: [PATCH] Fix frame ID comparison problem on s390

[Andrew Cagney <cagney at gnu dot org>]

> Andrew Cagney wrote:
>
>
> > > Symbol table code often returns 0 to indicate a failed lookup (here a 
> > > search for the function containing pc).  That zero can end up in the 
> > > frame ID.  Look at calls to get_frame_func / frame_func_unwind (which 
> > > I've proposed eliminating).
> > >
> > >  From memory architectures that do not implement dummy ID unwind also 
> > > end up with wild-card IDs (fortunatly the dummy-frame code works around 
> > > this).
> > >
> > > Broken tramp unwinders often leave the .code address zero (see paragraph 
> > > #1 for why).
>
>
> So, what would you recommend to solve the problem of 'wildcard zero pc'
> being confused with 'NULL pointer call'?  Is my original back-end hack
> OK with or, or do you have another target-independent suggestion?

No. Not really.

The wild card mechanism is needed (for when the function entry point 
address isn't known) but it needs to be made more robust.  One step on 
that path would be to extend the build interface:

> /* 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).  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);

with something like:

> extern struct frame_id frame_id_build_wild (CORE_ADDR stack_addr);

That way clients would explicitly build a wild-card frame ID, and the 
frame code was free to implement that mechanism anyway it saw fit.

Andrew