From: Carlos O'Donell <carlos@redhat.com>
To: hegdesmailbox@gmail.com, gnu-gabi@sourceware.org
Subject: Re: GNU dlopen(3) differs from POSIX/IEEE
Date: Fri, 01 Jan 2016 00:00:00 -0000 [thread overview]
Message-ID: <ca68d193-0a5d-1dc1-dc8c-bc59c8c27627@redhat.com> (raw)
In-Reply-To: <25bc0c78-19ae-8974-b142-bb57f21cdb3d@gmail.com>
On 06/13/2016 10:48 AM, Suprateeka R Hegde wrote:
> Without provding libfoo on the link line, I could not get a JUMP_SLOT
> for foo. So I provided -lfoo for the link-edit phase and then renamed
> libfoo.so to libfoo1.so and also created a dummy libfoo.so without
> foo. This way, I could get a JUMP_SLOT for foo. This hack was not
> necessary on other platforms as foo gets a PLT entry even without
> definition. By getting a JUMP_SLOT, I could verify if LD_PRELOAD
> works in this case.
Correct, you don't get a PLT entry for foo unless it's in a shared
library at link-edit time.
Could you actually provide the exact steps you used in a GNU/Linux-
--based system to produce the final executable?
My experience is that you will either see a failure at link-edit
time, failure at runtime (missing libfoo.so, undefined symbol foo),
and will never get to the point where you can run the application
and get a segfault. I'm curious to see exactly the way you constructed
the scenario.
Therefore if the application's global symbol references all must be
defined before it starts there is no possibility for dlopen with
RTLD_GLOBAL to add symbols to the global scope that can be used
to result such symbols, because they are already resolved.
--
Cheers,
Carlos.
next prev parent reply other threads:[~2016-06-13 17:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-01 0:00 Suprateeka R Hegde
2016-01-01 0:00 ` Carlos O'Donell [this message]
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` Florian Weimer
2016-01-01 0:00 ` Szabolcs Nagy
2016-01-01 0:00 ` Florian Weimer
2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Carlos O'Donell
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=ca68d193-0a5d-1dc1-dc8c-bc59c8c27627@redhat.com \
--to=carlos@redhat.com \
--cc=gnu-gabi@sourceware.org \
--cc=hegdesmailbox@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).