Re: [PATCH] Shared library fixes for GNU/Linux/PPC port

[Kevin Buettner <kevinb at cygnus dot com>]

On Feb 25,  1:28pm, Andrew Cagney wrote:

> >     The differences between ppc_linux_memory_remove_breakpoint () and
> >     memory_remove_breakpoint () are minor.  All that the former does
> >     that the latter does not is check to make sure that the breakpoint
> >     location actually contains a breakpoint (trap instruction) prior
> >     to attempting to write back the old contents.  If it does contain
> >     a trap instruction, we allow the old contents to be written back.
> >     Otherwise, we silently do nothing.
> > 
> >     It seems to me that we ought to be using this version in
> >     mem-break.c for all other targets (using the mem-break.c
> >     facilities) too.  The only downside that more traffic is generated
> >     for remote targets since we'll have an extra fetch of a memory
> >     word each time a breakpoint is removed.
> 
> Rather than make this the default behavour (and introduce extra remote
> traffic) would it be better to provide this behavour as a new type of
> breakpoint?  The shlib stuff could then insert a checking breakpoint.

I'll have to study it some more.  It sounds like a good idea, but I
think we'll have to complicate the breakpoint machinery somewhat to
insert these special breakpoints.  (For this particular platform, we'd
insert the special breakpoint when the address in question is in a
PLT.)

> I'd also be curious to know if this shlib mechanism is standard for
> SVR4/PPC or just Linux.

>From my reading of the SVR4/PPC ABI, it looks like it's standard.  The
following text is especially relevant:

    For the PowerPC, the procedure linkage table (the .plt section) is
                                                                    ^^
    not initialized in the executable or shared object file.  Instead,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    the link editor simply reserves space for it and the dynamic
    linker initializes it and manages it according to its own,
    possibly implementation-dependent needs, subject to the following
    constraints:

    1. The first 18 words (72 bytes) of the procedure linkage table
       are reserved for use by the dynamic linker.  There shall be no
       branches from the executable or shared object into these first
       18 words.

    2.  If the executable or shared object requires N procedure
       linkage table entries, the link editor shall reserve 3*N words
       (12*N bytes) following the 18 reserved words.  The first 2*N of
       these words are the procedure linkage table entries themselves. 
       The static linker directs calls to bytes (72 + (i-1)*8), for i
       between 1 and N inclusive.  The remaining N words (4*N bytes)
       are reserved for use by the dynamic linker.

Kevin