From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
To: Pedro Alves <pedro_alves@portugalmail.pt>, gdb-patches@sourceware.org
Subject: Re: Windows DLL support update.
Date: Thu, 16 Aug 2007 01:59:00 -0000 [thread overview]
Message-ID: <20070816015907.GA4167@ednor.casa.cgf.cx> (raw)
In-Reply-To: <46C39D10.3020001@portugalmail.pt>
On Thu, Aug 16, 2007 at 01:40:48AM +0100, Pedro Alves wrote:
> Christopher Faylor wrote:
>> On Tue, Aug 14, 2007 at 01:23:28AM +0100, Pedro Alves wrote:
>>> Here is the new version of the patch that converts native win32
>>> debugging to use the new solib-target.c.
>> I have a few of questions/observations wrt the win32-nat.c changes.
>
> Thanks for such a quick review.
>
>> 1) Does it still properly handle the "exceptions" that are thrown by
>> cygwin which must be ignored? I believe that the most populr source
>> of complaints about those came from people who were using pthreads
>> functions.
>
> Yes. I tried with this:
> http://www.cygwin.com/ml/cygwin/2006-05/msg00650.html
>
> 'set cygwin-exceptions 1' shows the SEGV, 'set cygwin-exceptions 0'
> doesn't.
>
>> 2) Is there some reason you didn't record the cygwin load/start address
>> in win32_make_so? Isn't all of the information you need available when
>> that function is called?
>
> I could open a bfd and look for .text like old solib_symbols_add
> does, but the so_list of the main list will have one open, so we can
> use that instead. I'll want to move these bits of cygwin detection and
> exception ignoring into a win32-tdep.c file that can be reused
> when remote debugging. This is step in that direction, but I'll
> understand if you still prefer the old way.
>
>> 3) If the answer to the above question is no, then it seems like
>> cygwin_load_start and cygwin_load_end should be static variables local
>> to ignore_access_violation_p.
>
> Storing the cygwin1.dll addresses and reusing
> it across runs should be ok if we assume that we are always
> debugging cygwin apps, but it could mask an access exception in
> a non-cygwin app that happened to occur in a dll loaded in that
> range by coincidence. I was going to leave it for later, but
> since you've asked, I'm now clearing the start/end addresses
> in do_initial_win32_stuff. This shows why they can't be local
> static.
>
> > I wonder if that logic should even be
> > further broken out into its own inside_cygwin(addr) function.
>
> Wonder no more. Done.
>
>> 4) I'd prefer it if you dropped the _p from "ignore_access_violation".
>
> Done.
>
>
> I gave it another testsuite spin, and it looks good.
Ok. I approve the win32 specific parts. Thanks for the explanations.
cgf
prev parent reply other threads:[~2007-08-16 1:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-14 0:24 Pedro Alves
2007-08-14 0:43 ` Pedro Alves
2007-08-14 12:10 ` Christopher Faylor
2007-08-16 0:44 ` Pedro Alves
2007-08-16 0:57 ` Daniel Jacobowitz
2007-08-17 23:26 ` Pedro Alves
2007-08-16 1:59 ` Christopher Faylor [this message]
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=20070816015907.GA4167@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