From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2733 invoked by alias); 3 Jul 2003 20:49:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2723 invoked from network); 3 Jul 2003 20:49:34 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 3 Jul 2003 20:49:34 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p2/8.12.5) with ESMTP id h63KnOEW005819; Thu, 3 Jul 2003 22:49:24 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6) with ESMTP id h63KnOkM014677; Thu, 3 Jul 2003 22:49:24 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6/Submit) id h63KnN9O014661; Thu, 3 Jul 2003 22:49:23 +0200 (CEST) To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC] gag some compiler warnings References: <16132.24210.943200.572653@localhost.redhat.com> From: Mark Kettenis Date: Thu, 03 Jul 2003 20:49:00 -0000 In-Reply-To: Elena Zannoni's message of "Thu, 3 Jul 2003 12:49:22 -0400" Message-ID: <86el17wd2k.fsf@elgar.kettenis.dyndns.org> X-SW-Source: 2003-07/txt/msg00088.txt.bz2 Elena Zannoni writes: > I am seeing these on a 64 bit system, when building gdb in 32-bit mode: > > /home/cygnus/ezannoni/gdb-6/src/gdb/infptrace.c: In function `child_xfer_memory': > /home/cygnus/ezannoni/gdb-6/src/gdb/infptrace.c:570: warning: cast to pointer from integer of different size > > The problem is that we pass a CORE_ADDR (which is 8 bytes long) to > ptrace and we cast it to PTRACE_ARG3_TYPE (which is 4 bytes long). > > Is this ok? Not too pretty, I know. > * infptrace.c (child_xfer_memory): Cast ptrace argument to long, > for cases in which CORE_ADDR size and pointer size don't agree. Hmm. I don't think this is OK. This could easily hide genuine problems. What system is this? Or perhaps a better question: what is the prototype of ptrace() in 32-bit mode on this system, and what is your definition of PTRACE_ARG3_TYPE on this system? Mark