Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Cary Coutant <cary@cup.hp.com>
To: "Alan Modra" <alan@linuxcare.com.au>,
	"David Huggins-Daines" <dhd@linuxcare.com>
Cc: <parisc-linux@thepuffingroup.com>
Subject: Re: [parisc-linux] userspace function pointers in the kernel
Date: Wed, 13 Sep 2000 10:11:03 -0700	[thread overview]
Message-ID: <200009131711.KAA21176@adlmail.cup.hp.com> (raw)

>The model I'm thinking of for elf32-hppa is along these lines:
>
>o  The linker creates a plt entry for all plabel relocs.  plt entries for
>   elf32-hppa are a function address, linkage table pointer pair, so
>   there's no need for the dynamic linker to allocate fptrs.
>o  A dynamic plabel reloc will have the function symbol, and an addend
>   into the plt.  This is a rather unusual reloc because the function
>   symbol value is ignored when calculating the final value.
>o  The dynamic linker builds a list or hash table of function symbols
>   versus plt offsets, and adjusts plabels so that only one plt entry is
>   ever used per function.

This is close to how it works on HP-UX, but we didn't use the table in 
your third bullet, so it became possible for the dynamic loader to come 
up with one function descriptor (PLT entry) one time, and a different one 
the next time.

Another thing you need to watch out for is when a library is dlclosed. 
Because the PLT entries are allocated when you see the reference -- not 
the definition -- you may not have a candidate PLT entry in the load 
module that contains the definition of the function (unless you also 
allocate PLT entries for all exported symbols). This means that you might 
be asked to dlclose a library that contains the PLT entry that is 
currently in use as the official function pointer for a function in 
another load module. If you go ahead and deallocate the library, you're 
hosed.

-cary

             reply	other threads:[~2000-09-13 17:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-13 17:11 Cary Coutant [this message]
2000-09-14  0:32 ` [parisc-linux] userspace function pointers in the kernel Alan Modra
  -- strict thread matches above, loose matches on Subject: below --
2000-09-13  1:05 Cary Coutant
2000-09-13  3:27 ` David Huggins-Daines
2000-09-13  4:06   ` Alan Modra
     [not found] <873dj5mfmb.fsf@linuxcare.com>
2000-09-13  0:59 ` Alan Modra
2000-09-12 20:54 Cary Coutant
2000-09-12 21:22 ` David Huggins-Daines
2000-09-13  0:23   ` Alan Modra
2000-09-12 20:12 David Huggins-Daines

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=200009131711.KAA21176@adlmail.cup.hp.com \
    --to=cary@cup.hp.com \
    --cc=alan@linuxcare.com.au \
    --cc=dhd@linuxcare.com \
    --cc=parisc-linux@thepuffingroup.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