From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
To: Pedro Alves <pedro_alves@portugalmail.pt>, gdb-patches@sourceware.org
Subject: Re: Support of gdb for Windows 64 native systems
Date: Sun, 14 Oct 2007 22:22:00 -0000 [thread overview]
Message-ID: <20071014221603.GA13096@ednor.casa.cgf.cx> (raw)
In-Reply-To: <471259B2.6050808@portugalmail.pt>
On Sun, Oct 14, 2007 at 07:02:26PM +0100, Pedro Alves wrote:
> Christopher Faylor wrote:
>>> + flags = DEBUG_ONLY_THIS_PROCESS;
>>> + toexec = exec_file;
>> This doesn't seem right. You moved this setting outside of an if block
>> and didn't accommodate the else condition.
>
> I didn't move it. The if inside the __CYGWIN__ block sets TOEXEC in both
> branches.
I'm talking about "flags".
> Here is rest of the hunk:
>>> +
>>> +#ifdef __CYGWIN__
>>> if (!useshell)
>>> {
>>> - flags = DEBUG_ONLY_THIS_PROCESS;
>>> cygwin_conv_to_win32_path (exec_file, real_path);
>>> toexec = real_path;
>>> }
>>> @@ -1784,6 +1798,7 @@ win32_create_inferior (char *exec_file,
>>> toexec = shell;
>>> flags = DEBUG_PROCESS;
>>> }
>>> +#endif
>
> This is what the resulting code looks like after the patch is applied:
>
> flags = DEBUG_ONLY_THIS_PROCESS;
> toexec = exec_file;
>
> #ifdef __CYGWIN__
> if (!useshell)
> {
> cygwin_conv_to_win32_path (exec_file, real_path);
> toexec = real_path;
> }
> else
> {
> char *newallargs;
> sh = getenv ("SHELL");
> if (!sh)
> sh = "/bin/sh";
> cygwin_conv_to_win32_path (sh, shell);
> newallargs = alloca (sizeof (" -c 'exec '") + strlen (exec_file)
> + strlen (allargs) + 2);
> sprintf (newallargs, " -c 'exec %s %s'", exec_file, allargs);
> allargs = newallargs;
> toexec = shell;
> flags = DEBUG_PROCESS;
> }
> #endif
>
> It could be changed into:
>
> #ifdef __CYGWIN__
> ...
> #else
> toexec = exec_file;
> #endif
>
> I prefer how it is now, but I'll respect your decision.
>
>>> +#ifdef __CYGWIN__
>>> add_setshow_boolean_cmd ("shell", class_support, &useshell, _("\
>>> Set use of shell to start subprocess."), _("\
>>> Show use of shell to start subprocess."), NULL,
>>> NULL,
>>> NULL, /* FIXME: i18n: */
>>> &setlist, &showlist);
>>> +#endif
>>>
>>> add_setshow_boolean_cmd ("cygwin-exceptions", class_support,
>>> &cygwin_exceptions, _("\
>>> Break when an exception is detected in the Cygwin DLL itself."), _("\
>> Seems like the above should be ifdef'ed too.
>
> Not sure why. The cygwin1.dll dll detection doesn't depend on any host
> habilities. Having a mingw hosted gdb be able to attach to a cygwin
> executable, and being able to debug it, seems useful. I imagine that
> it might prove useful to have a gdb that doesn't link to cygwin1.dll
> as a resort into debugging Cygwin issues.
There should be no cygwin accommodations in a pure windows port of gdb.
cgf
next prev parent reply other threads:[~2007-10-14 22:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <uprzkkrf7.fsf@gnu.org>
[not found] ` <20071012222842.GD21800@adacore.com>
[not found] ` <20071013024116.GB29152@adacore.com>
[not found] ` <uk5prl27s.fsf@gnu.org>
[not found] ` <20071013154715.GE29152@adacore.com>
[not found] ` <4711021C.8010805@portugalmail.pt>
[not found] ` <20071013205105.GA13789@adacore.com>
[not found] ` <47114BB7.1000501@portugalmail.pt>
[not found] ` <20071014051622.GC13789@adacore.com>
[not found] ` <471200C5.6050609@portugalmail.pt>
2007-10-14 18:03 ` Christopher Faylor
2007-10-14 19:55 ` Pedro Alves
2007-10-14 22:22 ` Christopher Faylor [this message]
2007-10-14 23:14 ` Daniel Jacobowitz
2007-10-15 18:54 ` Christopher Faylor
2007-10-15 19:19 ` Daniel Jacobowitz
2007-10-16 0:18 ` Pedro Alves
2007-10-16 4:21 ` Eli Zaretskii
2007-10-16 6:40 ` Christopher Faylor
2007-10-16 11:57 ` Pedro Alves
2007-10-16 12:41 ` Eli Zaretskii
2007-10-16 14:35 ` Christopher Faylor
2007-10-16 14:41 ` Pedro Alves
2007-10-16 15:56 ` Daniel Jacobowitz
2007-10-16 16:13 ` Christopher Faylor
2007-10-16 16:16 ` Eli Zaretskii
2007-10-16 18:23 ` Joel Brobecker
2007-10-16 18:57 ` Ulrich Weigand
2007-10-17 19:47 ` Pedro Alves
2007-10-17 22:00 ` Joel Brobecker
2007-10-18 4:06 ` Pedro Alves
2007-10-18 4:16 ` Eli Zaretskii
2007-10-18 10:07 ` Joel Brobecker
2007-10-18 20:20 ` Eli Zaretskii
2007-10-19 11:48 ` Joel Brobecker
2007-10-19 12:09 ` Daniel Jacobowitz
2007-10-19 12:27 ` Eli Zaretskii
2007-10-16 20:29 ` Pedro Alves
2007-10-14 23:29 ` Pedro Alves
2007-10-15 18:45 ` Christopher Faylor
2007-10-15 23:32 ` Pedro Alves
2007-10-14 21:16 ` Joel Brobecker
2007-10-14 22:22 ` Christopher Faylor
2007-10-15 8:58 ` Pedro Alves
2007-10-15 18:39 ` Christopher Faylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071014221603.GA13096@ednor.casa.cgf.cx \
--to=cgf-use-the-mailinglist-please@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=pedro_alves@portugalmail.pt \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox