Re: [DynInst_API:] Rewriter output file naming question

[Andrew Bernat <bernat@xxxxxxxxxxx>]

(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? 

Drew

On Nov 30, 2012, at 12:51 PM, Josh Stone <jistone@xxxxxxxxxx> wrote:

On 11/29/2012 05:35 PM, Josh Stone wrote:

Well disallowing the same input and output is an easy heuristic [...]

BTW, a colleague pointed out to me that disallowing the same input and
output by *name* is also flawed in the presence of hardlinks.  To be
really sure about the file you're clobbering, you'd need to stat it and
compare the dev/ino pair to the input.

In that scenario, the rename() scheme will leave the new content
disconnected, and any other hardlinked paths with remain with the old
content.  I think that's usually what you want when changing hardlinked
files, but it's worth noting.
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

--

Andrew Bernat

Paradyn Project

bernat@xxxxxxxxxxx

http://www.cs.wisc.edu/~bernat