On Fri, 30 Nov 2012, Andrew Bernat wrote:
(Adding paradyn-staff to the list).
Of course, and I have a patch that does that in.
However, this exposes a different problem which you mentioned before. Right now, our behavior is to allow a user to open an executable and its
libraries as a single workspace, and the user can modify both. However, the write binary call takes a single name - the name for the new binary.
Any modified libraries are written out with their original names in the current directory. This leads to two problems:
1) Overwriting libraries if they're in the current directory;
2) Local copies of (e.g.) libc, which can get picked up by LD_LIBRARY_PATH when executing other programs.
We have a couple of proposed changes to make for this; I'd appreciate people's inputs.
1) Keep current behavior and allow (via mktemp/rename) safely overwriting open files.
2) Add an infix string to modified libraries that uniquely identifies them (e.g., libc-dyninst.so) and update the binary to use that name as a
dependence. Said string would be user-modifiable, default to "dyninst" most likely, and could be set to empty to emulate behavior #1.
3) Introduce a callback during rewrite that requests the user provide a new string name for any modified libraries. Again, a default would map
to option 2, and users could manually recreate option 1.
I'm leaning towards option 2. If users want to rewrite a library in isolation they can using the file rewrite interface anyway.
Thoughts?
Allowing library renaming can get dangerous. If you have a renamed
libc-dyninst.so, then you're likely going to turn up loading both the
original libc.so and libc-dyninst.so--and you don't want two libcs loaded
at once (I've done that, it's bad).
If you rename a library you essentially have to also rewrite everything
your app can load that depends on that library. That's usually not
feasible.
I'd suggest leaving things mostly as-is. Perhaps make overwriting of
existing files an explicit error condition. Right now you essentially
have to manually put your rewritten files in a dedicated directory, which
is slightly annoying, but unlike the alternatives it's not particularly
dangerous.
-Matt
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}