All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Huggins-Daines <dhd@linuxcare.com>
To: John Marvin <jsm@udlkern.fc.hp.com>
Cc: parisc-linux@thepuffingroup.com
Subject: Re: Bug in shared libraries
Date: 20 Oct 2000 11:20:35 -0400	[thread overview]
Message-ID: <8766mn1qv0.fsf@linuxcare.com> (raw)
In-Reply-To: John Marvin's message of "Fri, 20 Oct 2000 08:37:54 -0600 (MDT)"

John Marvin <jsm@udlkern.fc.hp.com> writes:

> Here is a partial dump from ld-2.1.94.so. The instruction at offset 3c60
> below, "stw r6,0(r7)", is the first faulting instruction that is attempting
> to write into its own .rodata section. Once this is fixed, there may
> be others.

Yes, I know what this is now.  The problem is that the compiler places
static PLABELs in .rodata instead of .data.  This doesn't cause any
problems for static executables since all the relocations on these
PLABELs will be resolved in the final link.  However when building
shared objects they will get emitted as dynamic relocations.

That's actually not supposed to make the dynamic linker crash though,
because the linker will set a flag (and create a dynamic tag) to
indicate that the read-only segments in the object should be remapped
read-write during relocation processing.

I wonder if the problem is actually that the call to mprotect() that
ld.so makes in order to remap its text segment read-write is failing,
or not having the desired effect.

Still it is wrong to be putting relocatable stuff in the text segment
(duh :) I'd meant to fix this eventually but it never affected us
before, so I sort of ignored it.  Too bad we didn't have a working
page fault handler earlier... it would really have been nice to catch
it early.

I guess I will "fix" the compiler to put them in .data instead for the
ELF32 target.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

  reply	other threads:[~2000-10-20 15:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-20 14:37 Bug in shared libraries John Marvin
2000-10-20 15:20 ` David Huggins-Daines [this message]
2000-10-24  5:02   ` Alan Modra
2000-10-24  6:19     ` Alan Modra
2000-10-24 14:09       ` Alan Modra

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=8766mn1qv0.fsf@linuxcare.com \
    --to=dhd@linuxcare.com \
    --cc=jsm@udlkern.fc.hp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.