You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently pt_inject can be used to execute code in a pt_process. Although this is a very low-level primitive, it is not very flexible. An additional function for loading shared libraries into processes is therefore desirable.
One approach is to describe shared libraries using pt_module, and add a function such as pt_process_module_load(struct pt_process *p, struct pt_module *m) to load them into processes. The drawback here is that it adds additional meaning to the pt_module structure, which would now describe both shared libraries loaded into a debuggee process, as well as on disk shared libraries. This weakens type safety, and creates behind the scenes management code overhead.
Another approach is to add pt_process_library_load(struct pt_process *p, const char *pathname), which is simple, but does not allow for other shared library representations than one that can be referred to by a pathname. In other words, we could load shared libraries from disk, but not from memory.
Finally, a new structure such as pt_library could be added to refer to libraries external to the debuggee, and the new function would be pt_process_library_load(struct pt_process *p, struct pt_library *l). Once loaded it would then appear as a pt_module within the debuggee process.
The last option has my preference, but I'm leaving this open for a bit for further discussion and contemplation.
The text was updated successfully, but these errors were encountered:
Currently pt_inject can be used to execute code in a pt_process. Although this is a very low-level primitive, it is not very flexible. An additional function for loading shared libraries into processes is therefore desirable.
One approach is to describe shared libraries using pt_module, and add a function such as pt_process_module_load(struct pt_process *p, struct pt_module *m) to load them into processes. The drawback here is that it adds additional meaning to the pt_module structure, which would now describe both shared libraries loaded into a debuggee process, as well as on disk shared libraries. This weakens type safety, and creates behind the scenes management code overhead.
Another approach is to add pt_process_library_load(struct pt_process *p, const char *pathname), which is simple, but does not allow for other shared library representations than one that can be referred to by a pathname. In other words, we could load shared libraries from disk, but not from memory.
Finally, a new structure such as pt_library could be added to refer to libraries external to the debuggee, and the new function would be pt_process_library_load(struct pt_process *p, struct pt_library *l). Once loaded it would then appear as a pt_module within the debuggee process.
The last option has my preference, but I'm leaving this open for a bit for further discussion and contemplation.
The text was updated successfully, but these errors were encountered: