Strange stepping behaviour with PPC 64 and secure PLTs

Strange stepping behaviour with PPC 64 and secure PLTs

[PAUL GILLIAM]

On a system with secure PLTs for 32-bit apps, when 'next'ing through a
simple 32-bit hello world program, GDB does not execute 'printf' and
then stop.  Instead, it seems to get lost in the 'lazy' invocation of
the dynamic loader.  Here is a transcript:

        pgilliam:~/gdb/tree-head> build/gdb/gdb hello32
        GNU gdb 6.4.50.20060330-cvs
        ...
        This GDB was configured as "powerpc64-unknown-linux-gnu"...Using
        host libthread_db library "/lib64/power4/libthread_db.so.1".
        
        (gdb) start
        Breakpoint 1 at 0x100004a4: file hello-simp.c, line 6.
        Starting program: /home/pgilliam/gdb/tree-head/hello32
        main () at hello-simp.c:6
        6           printf("Hello, world\n");
        (gdb) bt
        #0  main () at hello-simp.c:6
        (gdb) n
        0x10000810 in call___do_global_ctors_aux ()
        (gdb) bt
        #0  0x10000810 in call___do_global_ctors_aux ()
        #1  0x0fea97f0 in generic_start_main ()
        from /lib/power4/libc.so.6
        #2  0x0fea9a4c in __libc_start_main ()
        from /lib/power4/libc.so.6
        #3  0x00000000 in ?? ()
        (gdb) n
        Single stepping until exit from function
        call___do_global_ctors_aux,
        which has no line number information.
        0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1
        (gdb) bt
        #0  0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1
        #1  0x100004b0 in main () at hello-simp.c:6
        (gdb) n
        Single stepping until exit from function _dl_runtime_resolve,
        which has no line number information.
        0x0fef4f70 in puts () from /lib/power4/libc.so.6
        (gdb) bt
        #0  0x0fef4f70 in puts () from /lib/power4/libc.so.6
        #1  0x100004b0 in main () at hello-simp.c:6
        (gdb) n
        Single stepping until exit from function puts,
        which has no line number information.
        
        ---- apparent hang here (really single stepping through 'puts')
        ---

If I "finish" out of 'call___do_global_ctors_aux', things don't get back
on track.  Instead, GDB "finish"s out of 'main':

        pgilliam:~/gdb/tree-head> build/gdb/gdb hello32
        GNU gdb 6.4.50.20060330-cvs
        ...
        This GDB was configured as "powerpc64-unknown-linux-gnu"...Using
        host libthread_db library "/lib64/power4/libthread_db.so.1".
        
        (gdb) start
        Breakpoint 1 at 0x100004a4: file hello-simp.c, line 6.
        Starting program: /home/pgilliam/gdb/tree-head/hello32
        main () at hello-simp.c:6
        6           printf("Hello, world\n");
        (gdb) bt
        #0  main () at hello-simp.c:6
        (gdb) n
        0x10000810 in call___do_global_ctors_aux ()
        (gdb) bt
        #0  0x10000810 in call___do_global_ctors_aux ()
        #1  0x0fea97f0 in generic_start_main ()
        from /lib/power4/libc.so.6
        #2  0x0fea9a4c in __libc_start_main ()
        from /lib/power4/libc.so.6
        #3  0x00000000 in ?? ()
        (gdb) finish
        Run till exit from #0  0x10000810 in call___do_global_ctors_aux
        ()
        Hello, world
        0x0fea97f0 in generic_start_main () from /lib/power4/libc.so.6
        (gdb) q
        
If I do a "next" instead of a finish when stopped at
call___do_global_ctors_aux, then the stack looks right again and a
"finish" will get things back on track.
        
        pgilliam@elm3b18:~/gdb/tree-head> build/gdb/gdb hello32
        GNU gdb 6.4.50.20060330-cvs
        ...
        This GDB was configured as "powerpc64-unknown-linux-gnu"...Using
        host libthread_db library "/lib64/power4/libthread_db.so.1".
        
        (gdb) start
        Breakpoint 1 at 0x100004a4: file hello-simp.c, line 6.
        Starting program: /home/pgilliam/gdb/tree-head/hello32
        main () at hello-simp.c:6
        6           printf("Hello, world\n");
        (gdb) bt
        #0  main () at hello-simp.c:6
        (gdb) n
        0x10000810 in call___do_global_ctors_aux ()
        (gdb) bt
        #0  0x10000810 in call___do_global_ctors_aux ()
        #1  0x0fea97f0 in generic_start_main ()
        from /lib/power4/libc.so.6
        #2  0x0fea9a4c in __libc_start_main ()
        from /lib/power4/libc.so.6
        #3  0x00000000 in ?? ()
        (gdb) n
        Single stepping until exit from function
        call___do_global_ctors_aux,
        which has no line number information.
        0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1
        (gdb) bt
        #0  0xf7ff5110 in _dl_runtime_resolve () from /lib/ld.so.1
        #1  0x100004b0 in main () at hello-simp.c:6
        (gdb) finish
        Run till exit from #0  0xf7ff5110 in _dl_runtime_resolve ()
        from /lib/ld.so.1
        Hello, world
        main () at hello-simp.c:7
        7       }
        (gdb) bt
        #0  main () at hello-simp.c:7
        (gdb) c
        Continuing.
        
        Program exited with code 015.
        (gdb) q
        

Note: in the old 32-bit PowerPC ABI the value of a PLT entry was an
executable instruction.  This was deemed security risk so in the new
ABI, PLT entries are pointer to routines, much like they are for 64-bit
apps.  In GDB for PowerPC, finding the real address of the function is
done by 'bfd_get_synthetic_symtab' when the elf file is loaded.  If this
routine was not working correctly due to a change in the ABI, would that
explain what I am seeing?

-=# Paul #=-

Re: Strange stepping behaviour with PPC 32 and secure PLTs

[PAUL GILLIAM]

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 #=-

Re: Strange stepping behaviour with PPC 32 and secure PLTs

[Daniel Jacobowitz]

On Thu, May 11, 2006 at 04:15:17PM -0700, PAUL GILLIAM wrote:
> 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.

Why?

The BFD solution is much more useful: it will make disassembly have
useful labels in both objdump and gdb when stopped in a stub.

rs6000_skip_trampoline_code may also be involved.

> 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'.

What do you mean by "unknown section"?

-- 
Daniel Jacobowitz
CodeSourcery