RE: [RFC] 32-bit support for windows thread information block

[Kai Tietz <Kai dot Tietz at onevision dot com>]

"Pierre Muller" <muller@ics.u-strasbg.fr> wrote on 14.01.2009 14:15:32:

> 
> 
> > -----Message d'origine-----
> > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> > owner@sourceware.org] De la part de Kai Tietz
> > Envoyé : Wednesday, January 14, 2009 2:00 PM
> > À : Pierre Muller
> > Cc : gdb-patches@sourceware.org
> > Objet : Re: [RFC] 32-bit support for windows thread information block
> > 
> > gdb-patches-owner@sourceware.org wrote on 14.01.2009 12:21:53:
> > 
> > >  I implemented two new command that display
> > > a part of the information of the
> > > thread information block and on
> > > the structured exception handler chain.
> > >  I added these two command to the "info w32" command
> > > prefix, but got into troubles appearing below.
> > >
> > > I have several questions regarding the 64-bit support of
> > > windows nat files:
> > >
> > > 1) Do hardware watchpoints work?
> > >   the problem is that the dr[8] array is
> > > defined as a unsigned type,
> > > is this enough for win64?
> > >   Is "unsigned" type a 64-bit ?
> > >
> > >   In the _CONTEXT struct
> > >   the debug registers are defined as DWORD64...
> > 
> > For address above 4GB hardware watchpoints aren't working, reasoned by
> > truncation.
> 
>   This would be easily fixed by changing the 
> "unsigned" type into something that would be
> "DWORD64" on 64-bit and "DWORD" on 32-bit.
> 
>   The main problem for me is that I don't know 
> what would be a reasonable choice for that type?
> 
>   Would uintptr_t be OK here?

uintptr_t would be fine. DWORD_PTR would be the ms answer for this, but 
isn't CORE_ADDR the better choise here?

Cheers,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.