Bug 186435 - [libexec] [patch] Allow for an alternative run-time loader
Summary: [libexec] [patch] Allow for an alternative run-time loader
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2014-02-03 23:40 UTC by Yuri Victorovich
Modified: 2018-08-10 17:17 UTC (History)
2 users (show)

See Also:


Attachments
patch-rtld-elf-alt-loader.patch (4.71 KB, patch)
2014-02-23 08:50 UTC, Yuri Victorovich
no flags Details | Diff
patch (4.23 KB, patch)
2016-04-28 23:56 UTC, Yuri Victorovich
no flags Details | Diff
patch (4.65 KB, patch)
2016-04-29 00:17 UTC, Yuri Victorovich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer 2014-02-03 23:40:01 UTC
Synopsys:
This is a simple patch to run-time loader, which allows other parts of the process to load objects dynamically.

What this patch does:
This patch makes r_debug and related symbols in the ld-elf.so.1 run-time loader public.

Detailed description:
Currently, only r_debug_symbol is public out of all debugger-related symbols in ld-elf.so. This is done so that debuggers can add a breakpoint on it to get notified of changes in the set of loaded shared libraries. This is sufficient when ld-elf.so is the only one who loads objects.

Now imagine the situation when an application wants to load its own ELF objects in its own way, still having the benefit of using the debug info. Such application would need to have access to the list of objects maintained by ld-elf.so. r_debug variable contains this list.

Such application would necessarily be system specific, and would have to have the knowledge of some inner workings of ld-elf.so. But, in my opinion, this is a legitimate use and should be allowed. Therefore I am suggesting this patch. Except r_debug, it adds related lock object and functions to the list of publics, because they are needed to avoid race conditions.

This is, of course, not a mainstream way to do things, but nevertheless it should be allowed.
This is also a minor patch, and it can't possibly hurt anything else.

--begin patch--
--- libexec/rtld-elf/Symbol.map  (revision 260894)
+++ libexec/rtld-elf/Symbol.map  (working copy)
@@ -15,6 +15,11 @@
     dlinfo;
     dl_iterate_phdr;
     r_debug_state;
+    r_debug;
+    rtld_bind_lock;
+    rlock_acquire;
+    wlock_acquire;
+    lock_release;
     __tls_get_addr;
 };

--end patch--
Comment 1 kabaev 2014-02-23 00:06:01 UTC
I do not like this patch at all, sorry. While I do appreciate the goal,
the way taken here is just wrong - the locking done by rtld internally
is just that - internal detail that is not to be paraded publicly in
front of an an innocent outside world. Over several last years we have
been over several lock implementations and locking semantics have
changed subtly couple more times. Would you be willing instead to
formulate a functional interface that rtld can expose to provide
necessary services to add/remove dynamic objects and that will allow us
to keep all of this dirty laundry under the wraps?
 
The patch as is cannot be committed.

-- 
Alexander Kabaev
Comment 2 Yuri Victorovich freebsd_committer 2014-02-23 08:50:37 UTC
Yes, I knew that exposing locks is not nice. However, the upside was 
that the patch was extremely simple.

I reworked it into the proper implementation. I added r_debug_add and 
r_debug_delete, with all locks hidden in them. They by themselves are 
sufficient for the goal. I also added r_debug_iterate, in order to 
potentially gain access to the list we are manipulating with. This is 
just in order to not lose any functionality that was made available with 
the previous patch.

Yuri
Comment 3 Yuri Victorovich freebsd_committer 2016-04-28 23:56:32 UTC
Created attachment 169797 [details]
patch

Updated as of 10.3
Comment 4 Yuri Victorovich freebsd_committer 2016-04-29 00:17:21 UTC
Created attachment 169799 [details]
patch
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2018-05-21 00:00:05 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-21 00:00:33 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"
Comment 7 Kyle Evans freebsd_committer 2018-08-09 02:18:04 UTC
(In reply to Yuri Victorovich from comment #4)

Hi Yuri,

Can you rebase this patch against head and throw it into Phabricator, tagging kan@ and kib@ (maybe) for review, please?

If you could also add me to subscribers, I would appreciate it.
Comment 8 Yuri Victorovich freebsd_committer 2018-08-10 17:17:03 UTC
(In reply to Kyle Evans from comment #7)

Hi Kyle,

I'll update the patch within a few days.

Thanks!
Yuri