Hi Roderich, Roderich Schupp wrote: > the recent post about the problem of DLLs being re-extracted reminded > me of a hack I once used to diagnose a similar problem. It should > be possible to start a packed binary (which after the first stage > of extraction is just a custom perl executable) under the perl > debugger (i.e. somehow pass a "-d" or more general "-d:foo" > option down). Looking at the current PAR::Packer I noticed > that since then someone hacked in this PERL_PROFILING > build-time #define that causes "-d:DProf" to be passed down.
That was me. And yeah, it's a hack. :) > Suggestion: > - generalize this, so that any first argument of the binary > matching /^-d/ is passed down to the custom perl executable > - but don't do this for each pp packed binary (as that would > be a large security problem), instead create two variants of > myldr: one without the debug feature, one with > - implement an option to pp to use the debuggable myldr when > assembling the packed binary (bonus points for automatically > packing perl5db.pl if this option is used) I like the general idea of this. I'm not sure I like building two copies of myldr. Building and testing PAR::Packer can take half a century on slow computers as it stands and duplicating the build process seems wrong. Also, what you'd really be doing is duplicate PAR::StrippedPARL::Dynamic and ::Static which are the containers for the PAR loader when installed. So the build process could be: 1) make myldr without debugging, 2) write the results into the __DATA__ section of the container modules, 3) make clean myldr, 4) make myldr with debugging, 5) write the results to the __DATA__ section of the container modules. In that case, the tests should run for both of those containers. At the very least, the parl-extraction tests would have to run for both, but ideally also the pp tests which take so long. I guess whether having the distinction a build time decision or a packaging time decision is a matter of preference. I can see the benefits of both. It would be more friendly to the user to have it at packaging time (except for the extra build time) and more friendly to the maintainer if it's done at build time. What comes in on the packaging-side is that we cannot have pre-built .par binaries for both cases if we do it at build time. I'm undecided. What do others think? > Then we could ask people to prepare a debuggable binary > and run it. Note that this won't help per se in the case > of re-extracted DLLS, since this happens in a BEGIN block, > i.e. before the interactive debugger prompt. However, setting > the environment variable PERLDB_OPTS to something like > "NonStop=1 LineInfo=db.out AutoTrace=1" would generate > a statement trace even for this early parts of program execution. Ah! A veteran of the debugger! Scary stuff. Cheers, Steffen
