RE: [RFC/RFA] Allow cygwin native to compile with --enable-64-bit-bfd

["Pierre Muller" <muller@ics.u-strasbg.fr>]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Christopher Faylor
> Sent: Sunday, November 25, 2007 11:13 PM
> To: gdb-patches@sourceware.org
> Subject: Re: [RFC/RFA] Allow cygwin native to compile with --enable-64-
> bit-bfd
> 
> On Sun, Nov 25, 2007 at 02:08:23PM -0500, Daniel Jacobowitz wrote:
> >On Sun, Nov 25, 2007 at 12:32:08PM -0500, Christopher Faylor wrote:
> >> On Sat, Nov 24, 2007 at 05:47:27PM -0500, Daniel Jacobowitz wrote:
> >> >On Sat, Nov 24, 2007 at 04:07:08PM -0500, Christopher Faylor wrote:
> >> >> >   if (!target_read_string
> >> >> >-    ((CORE_ADDR) current_event.u.DebugString.lpDebugStringData,
> &s, 1024,
> >> >> >0)
> >> >> >+    ((CORE_ADDR) addr, &s, 1024, 0)
> >> >>
> >> >> How can coercing something to uintptr_t and then to CORE_ADDR
> achieve
> >> >> anything?  How does the double coercion help?
> >> >
> >> >Just the warning.  CORE_ADDR will be long long,
> >> >current_event.u.DebugString.lpDebugStringData will apparently be a
> pointer.
> >>
> >> And the warning is?
> >
> >Cast from pointer to integer of different size.  Casts are the way
> >we've handled it elsewhere in GDB, but I wouldn't complain about a
> >wrapper; casting host pointers to CORE_ADDRs is an action we try to
> >keep to a minimum anyway.
> 
> I wouldn't mind a double cast either, if there is precedent for that.

  I didn't find many double typecast in gdb directory:
grep "([a-zA-Z0-9 ]*) *([a-zA-Z0-9 ]*)" *nat* 
only found one occurrence:
spu-linux-nat.c:  return (ULONGEST) (unsigned long) res;
and this does not even seem to be a pointer<->integer cast...

  Please remember that my C knowledge is mainly limited to
the gdb sources themselves...
  so if I have a CORE_ADDR that could be 64 bit
and I want to cast it to a pointer, I should use
  (LPVOID) (uintptr_t) core_addr
and if I have a win32 API pointer that I want to
convert to a CORE_ADDR, I should use
  (CORE_ADDR) (uintptr_t) pointer_var.

  My patch contained two conversions of the first type and
four of the second type (all with the same memaddr variable)
are macros really useful? Maybe to avoid future
similar problems...

  If we go for macros, I have no idea how to name those.
  
#define CORE_ADDR_TO_POINTER (LPVOID) (uintptr_t)
and
#define POINTER_TO_CORE_ADDR (CORE_ADDR) (uintptr_t)

I don't know if more braces are needed or not...

  It's probably best to still use uintptr_t as 
Pedro was talking about trying to support win64, no?

Pierre