This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CFA: pseudo-reloc v2


On Sun, Oct 04, 2009 at 10:03:37PM +0200, Corinna Vinschen wrote:
>On Oct  4 10:52, Christopher Faylor wrote:
>> On Sun, Oct 04, 2009 at 01:25:04PM +0200, Corinna Vinschen wrote:
>> >On Oct  3 13:59, Charles Wilson wrote:
>> >> #1) Using fprintf and mingw-specific error messages. This is bad, even
>> >> if they are guarded by DEBUG:
>> >> 
>> >> #ifdef DEBUG
>> >>       fprintf (stderr, "internal mingw runtime error:"
>> >>                "psuedo_reloc version %d is unknown to this runtime.\n",
>> >>                (int) v2_hdr->version);
>> >> #endif
>> >> 
>> >> Maybe something like
>> >> 
>> >> #if defined(__INSIDE_CYGWIN__)
>> >>      system_printf (
>> >>         "Relocation error: invalid pseudo_reloc version %d.",
>> >>         int) v2_hdr->version);
>> >> #else
>> >> #if defined(DEBUG) && defined(__MINGW32__)
>> >>       fprintf (stderr, "internal mingw runtime error:"
>> >>                "psuedo_reloc version %d is unknown to this runtime.\n",
>> >>                (int) v2_hdr->version);
>> >> #endif
>> >
>> >The strace feature under the hood of system_printf is only available
>> >from within the Cygwin DLL itself.  The pseudo_reloc.c file is not part
>> >of the DLL, it's linked into the application.  Above all, the strace
>> >fetaure is only accessible from C++ code.
>> >
>> >So, actually fprintf(stderr) is more correct.  However, it's not safe to
>> >assume that stdio has already been initialized when the runtime
>> >relocator runs.  AFAICS, the relocator is called before dll_crt0_1 is
>> >called and only in that latter function, the stdio descriptors are
>> >initialized.
>> >
>> >Failing relocation is as bad as any other error starting an application.
>> >Wouldn't it be the right thing to raise an exception, along the lines of
>> >the Windows exception which is raised when a loadtime linked DLL can't
>> >be loaded?
>> 
>> I'd feel more comfortable with a real error message, even if you have to
>> use WriteConsole to display it.  Or, a real error message + an
>> exception.
>
>Here's another idea.  At one point Brian Dessent proposed a patch to
>detect a missing DLL.  Hmm, yes, here's the checkin of your patch
>implementing that, back on 2008-03-26.
>
>I was wondering if a similar technique could be used to print an error
>message in the parent process, if the relocation failed in the child
>process.  The idea would be to generate a specific status code which
>would then catched in status_exit, just like STATUS_DLL_NOT_FOUND.

I thought that was basically what Dave was proposing.  Maybe I'm missing
something but I don't see any benefit in passing the error up (or down)
to the cygwin dll.  The one benefit that I could see is that we could use
a presumably standardized method for reporting errors.  Although we don't
actually have that in the cygwin DLL currently.  Maybe we should.

>I'm just not sure how to generate that specific status code...

I think you'd just need ExitProcess ().

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]