This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Windows DLL support update.
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