Rod Evans wrote: > Roland Mainz wrote: > >>> What about adding an option to override "basename" with a different > >>> string ? > >> Anything is possible. Initially, I strived for simplicity. > > > > Ok... but a "basename" option may be usefull to avoid "ugly" filenames > > in the filesystem, e.g. mangled C++ names may not look "pretty" when > > they appear in the filesystem (and for more complex C++ symbol names you > > may hit the maximum filename length sooner or later...). > > Sure, it would be easy to add an option to provide for this if required. > (although I'd mot sure why you'd come up with a mangled C++ name in the > first place that you'd have to override).
What about C++ classes where a class member contains such data (OkOk... you could use a global variable containing the data generated by "elfwrap" and init the member variable in the constructor etc.) ? > > BTW: What about question about "read-only" in my previous email... does > > this matter in this case ? > > Sorry, missed this one. Presently the data is simply tagged SHF_ALLOC, > as those that have requested to use elfwrap() simply wanted to read data > in. Again, options could allow you to set any sections flags, and rather > than a simplistic -w (write) flag I'd probably go the route of allowing > any valid SHF_ flag to be set. Ok... ... is it possible to make "elfwrap" tag the data as "shareable between processes" (e.g. read-only) by default ? Otherwise we have a similar issue like the current Sun Studio 10/11 "cc" behaviour for string literals which eat memory per process instead of being shared between processes (unless you use "-xstrconst") ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
