Re: Strange stepping behaviour with PPC 32 and secure PLTs

[PAUL GILLIAM <pgilliam@us.ibm.com>]

This is a followup to this message:
http://sourceware.org/ml/gdb/2006-03/msg00224.html

To recap, when I try to 'next' over a call to a library subroutine, it
kind of does a stepi instead.

This is for a 32-bit ppc target program that uses the new secure PLT's.

After some digging, I have found that the code in infrun.c that is
supposed to notice that we are next'ing over a subroutine call isn't.

Here is an excerpt:
        if (frame_id_eq (frame_unwind_id (get_current_frame ()),
        step_frame_id))
            {
              /* It's a subroutine call.  */
              CORE_ADDR real_stop_pc;
              . . .
              if (step_over_calls == STEP_OVER_ALL)
                {
                  /* We're doing a "next", set a breakpoint at callee's return
                     address (the address at which the caller will
                     resume).  */
                  insert_step_resume_breakpoint_at_frame (get_prev_frame (get_current_frame ()));
                  keep_going (ecs);
                  return;
                }
              . . .
            }
        
The reason this code is not working is that the two frame ID's are different: the call to
frame_unwind_id is not working because lookup_minimal_symbol_by_pc_section() can't find
the right symbol.  It does find a symbol that would work, but because the it's in the
'unknown' section and the PC is in the '.text' section, it's ignored.  It might be more
accurate to say that there is no 'right' symbol.

In the non-secure PLT case, there is a symbol 'foo@plt' where foo is the name of the 
library subroutine.  This is a synthetic symbol made up by BFD for the plt associated
with 'foo' and it's in the '.plt' secton.  Sense PLT's are executable, the PC will also be
in the '.plt' section and all is well.

In the secure PLT case, the ignored symbol in the 'unknown' section is taken from the
executables symbol table.  BFD does synthesize a 'foo@plt' symbol, but it's in the
'.data' section, as it should be sense secure PLT's are not executable.

One way to fix this is for BFD to synthesize a new symbol in addition to 'foo@plt', let's
say we call it 'foo@stub'.  This new symbol would be in the '.text' section and would
be found by lookup_minimal_symbol_by_pc_section() and all would be well.  BFD would know
that such a symbol should be generated if it was dealing with a ppc32 object file whose
'.plt' section was not executable.

I would rather have a GDB only solution.

A possibility would be to change lookup_minimal_symbol_by_pc_section() so that a symbol in
the 'unknown' section would not be ignored if it was of type 'mst_solib_trampoline'.

Or we could change prim_record_minimal_symbol_and_info() to set the section to SECT_OFF_TEXT (objfile)
if the type is 'mst_solib_trampoline' (this is what prim_record_minimal_symbol() does).  /* I tried
this and it's not quite what's needed: we need to diddle with 'bfd_section', not 'section'. */

Any thoughts?

If I don't hear anything soon, I'll submit a better patch to hack prim_record_minimal_symbol_and_info()
to gdb-patches@ and see what happens in that list.

-=# Paul #=-