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.
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.
--- libexec/rtld-elf/Symbol.map (revision 260894)
+++ libexec/rtld-elf/Symbol.map (working copy)
@@ -15,6 +15,11 @@
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.
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.
Created attachment 169797 [details]
Updated as of 10.3
Created attachment 169799 [details]
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017
- Set Status to "Open"
(In reply to Yuri Victorovich from comment #4)
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)
I'll update the patch within a few days.