Hi,
I am just curious - has anybody looked into the Enbugger module?
Previously, I have "solved" the problem once by co-packaging the Perl executable
into the PAR binary, and then calling the script itself with debugger options,
but this way blows up the binary size unnecessarily.
To me, the Enbugger concept seems to be much more flexible.
Best regards,
Markus
Markus Jansen
Master Methods & Tools Engineer, Project Office
Development Unit Core Network Evolution
Ericsson GmbH
Eurolab R&D
Ericsson Allee 1
52134 Herzogenrath, Germany
www.ericsson.com Office: +49 2407 575 5157
Fax: +49 2407 575 98452
Mobile: +49 172 274 2003
Email: [EMAIL PROTECTED]
Ericsson GmbH. Sitz: Düsseldorf. Registergericht: Amtsgericht Düsseldorf, HRB
33012. Geschäftsführer: Carsten Ahrens. Aufsichtsratsvorsitzender: Anders Olin
This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you
believe this message has been sent to you in error, please notify the sender by
replying to this transmission and delete the message without disclosing it.
Thank you.
E-mail including attachments is susceptible to data corruption, interception,
unauthorized amendment, tampering and viruses, and we only send and receive
emails on the basis that we are not liable for any such corruption,
interception, amendment, tampering or viruses or any consequences thereof.
-----Original Message-----
From: Glenn Linderman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 10:00 PM
To: Roderich Schupp
Cc: Steffen Mueller; [email protected]
Subject: Re: [RFC] Option to build a debuggable packed binary
On approximately 1/8/2008 11:49 AM, came the following characters from the
keyboard of Roderich Schupp:
> On Jan 8, 2008 8:09 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
>
>> I'm not sure of where the implementation is, or what constraints it
>> is under, but would it be possible to provide this option based on an
>> environment variable, instead of a hacked build/package time option?
>> Pass the value of the environment variable as the first option to the
>> packed binary? Then instead of build or package time, it is a
>> run-time decision, and no special preparation need be done anywhere?
>
> The implementation is the easy part (just a few lines in myldr/main.c).
> Setting up the PAR::Packer build process is a real PITA -- that is if
> you want the "debuggable packed exceutable" option at packing-time
> (instead of at run-time) as in my original mail.
> Steffen has already described the mess.
>
> So I'm all for making it a run-time option, environment variable preferred:
> PAR_DEBUG is already taken, what about PAR_PERL_DEBUG or
> PAR_DEBUG_PERL?
>
> The only problem I see is that perl5db.pl (and stuff it depends on)
> will be needed at run-time (when debugging is requested), but will not
> have been packed. Hence we still need a new option for pp that in
> effect is a shortcut for -M perl5db.pl.
>
> Cheers, Roderich
Ah, so the new pp option ( --prepare_for_debugging equivalent to -M
perl5db.pl) would still be required to make a debuggable package, by including
the debugger. That makes sense.
And then the debuggable package would have a runtime switch (environment
variable) to actually turn on the debugger or not.
Is it possible to rework Profiling the same way, slightly cleaner than the
"hack"?
I guess the only remaining issue is if someone attempts to run an package that
was not created with --prepare_for_debugging, and has the environment variable
set. As long as an appropriate error results, I guess that would be OK.
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
