From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id BB40D3858D39; Wed, 15 Mar 2023 11:41:26 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BB40D3858D39
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1678880486;
	bh=ynei1ae2JT2+kX8eCsrEMAXBLQZV9QI+D3PdcOlQMNg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=nU+CF2HNFuaCRNV37g4U7KR2+Y3ZlFc41Fq0Jnk3Bb7xvnB7JJdZeGXHdasn1cAp1
	 8nNT9kj70E4bjenCwK3O1mKfs8KL6bi7xA++LR/dvrIiNqeTX9yts5H+ui2B/aIQuy
	 zoDIC0v1nKVXDqrnNavx5koIfeKNEtSxDxp6Zadg=
From: "stsp at users dot sourceforge.net"
 <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/30007] rfe: dlopen to specified address
Date: Wed, 15 Mar 2023 11:41:26 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: stsp at users dot sourceforge.net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-30007-131-KfViTSZ9Sg@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-30007-131@http.sourceware.org/bugzilla/>
References: <bug-30007-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <glibc-bugs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D30007

--- Comment #12 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jonathon Anderson from comment #8)
> The proposed la_premap and la_premap_dlmem (part of the dlmem() patch)
> collectively "solve" this problem by granting LD_AUDIT some limited contr=
ol
> over the object (segment) mapping process. My first impression from readi=
ng
> the test cases, they seem a bit too specific to this use case. IMHO they =
are
> also out-of-scope for LD_AUDIT:

OK, if this is the case (which is
entirely possible, even if I don't
agree with the provided reasoning),
then let's just not use audit. :)
I can just add the "premap_ops"
optional pointer to dlmem().

Advantages: much, much fewer changes.
No need for dlload_audit_module() for
that use-case, but I'll keep discussing
it as a "bonus", in case someone finds
it interesting to load audit modules at
run-time.
Everything is confined within dlmem().
Perfect for my use-case.
Plain perfect.

Disadvantages:
Well, extra arg that most people will
set to NULL. Very small disadvantage,
given that this API is not standard anyways.
And it will not be possible to specify the
reloc address for pre-existing functions
like dlopem()/dlmopen(), or prospective ones
like BSD's fdlopen(). I find that a bit pity
given that people requested that functionality
for currently existing APIs, but not a
problem for my use-case. I only need to
control dlmem(), not to help others on
stackoverflow. :)

So sounds better?

--=20
You are receiving this mail because:
You are on the CC list for the bug.=