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

Ulrich Weigand
2007-11-26T15:18:30Z

Pierre Muller wrote:

> 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...

Your regexp is missing "_", so it actually cannot match the
cases involving intptr_t. It's true that even so there is
not a large number of precedents, but that is because the
operation of casting between host pointers and CORE_ADDR
is quite rare (and that is how it should be!):

inf-ptrace.c: (PTRACE_TYPE_ARG3)(uintptr_t)
inf-ptrace.c: (PTRACE_TYPE_ARG3)(uintptr_t)rounded_offset,
inf-ptrace.c: (PTRACE_TYPE_ARG3)(uintptr_t)rounded_offset,
inf-ptrace.c: (PTRACE_TYPE_ARG3)(uintptr_t)rounded_offset,
inf-ptrace.c: buf[i] = ptrace (PT_READ_U, pid, (PTRACE_TYPE_ARG3)(uintptr_t)addr, 0);
inf-ptrace.c: ptrace (PT_WRITE_U, pid, (PTRACE_TYPE_ARG3)(uintptr_t)addr, buf[i]);
linux-thread-db.c: ? (CORE_ADDR) (intptr_t) notify.u.bptaddr
linux-thread-db.c: : (CORE_ADDR) (uintptr_t) notify.u.bptaddr),
linux-thread-db.c: ? (CORE_ADDR) (intptr_t) address
linux-thread-db.c: : (CORE_ADDR) (uintptr_t) address);
ppc-linux-nat.c: *addr_p = (CORE_ADDR) (uintptr_t) siginfo_p->si_addr;
proc-service.c: return (psaddr_t) (intptr_t) addr;
proc-service.c: return (psaddr_t) (uintptr_t) addr;
spu-linux-nat.c: return (ULONGEST) (unsigned long) res;
spu-linux-nat.c: *word = ptrace (PT_READ_I, tid, (PTRACE_TYPE_ARG3) (size_t) memaddr, 0);
spu-linux-nat.c: ptrace (PT_WRITE_D, tid, (PTRACE_TYPE_ARG3) (size_t) memaddr, word);

> 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.

Basically, yes. Except that "LPVOID" is rather a Windows-ism,
it is not actually defined anywhere else ...

You should be using "void *", or preferably the actual
target pointer type.

> 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...

I'd prefer to not have macros, but just an explicitly
written intermediate cast.

Bye,
Ulrich

--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com