Bug 186435
| Summary: | [libexec] [patch] Allow for an alternative run-time loader | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Yuri Victorovich <yuri> | ||||||||
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||||||
| Status: | Open --- | ||||||||||
| Severity: | Affects Only Me | CC: | emaste, kevans | ||||||||
| Priority: | Normal | Keywords: | patch | ||||||||
| Version: | Unspecified | ||||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| Attachments: |
|
||||||||||
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 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 Created attachment 169797 [details]
patch
Updated as of 10.3
Created attachment 169799 [details]
patch
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open" For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open" (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. (In reply to Kyle Evans from comment #7) Hi Kyle, I'll update the patch within a few days. Thanks! Yuri |
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--