From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25549 invoked by alias); 11 Feb 2010 13:30:46 -0000 Received: (qmail 25529 invoked by uid 22791); 11 Feb 2010 13:30:45 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Feb 2010 13:30:35 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1BDUXAS030324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Feb 2010 08:30:34 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1BDUVpd007627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 08:30:33 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id o1BDUVuH010634; Thu, 11 Feb 2010 14:30:31 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id o1BDUUQU010633; Thu, 11 Feb 2010 14:30:30 +0100 Date: Thu, 11 Feb 2010 13:30:00 -0000 From: Jan Kratochvil To: Mark Kettenis Cc: binutils@sourceware.org, gdb-patches@sourceware.org Subject: [cancelled] Re: [patch] bfd/: bfd_elf_bfd_from_remote_memory 32bit &= 0xffffffff Message-ID: <20100211133030.GA9615@host0.dyn.jankratochvil.net> References: <20100211115730.GA7358@host0.dyn.jankratochvil.net> <201002111250.o1BCoquc020269@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002111250.o1BCoquc020269@glazunov.sibelius.xs4all.nl> User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00287.txt.bz2 Hi, cancelling this patch review request. On Thu, 11 Feb 2010 13:50:52 +0100, Mark Kettenis wrote: > Please define "garbage". I suspect that what you really mean is that > BFD currently returns sign-extended addresses in some cases. I meant garbage (bits with arbitrary unknown content). But as I see now fixing few GDB places to always sign-extend the displacement CORE_ADDR will permit using the current standard 64bit math operators even for 32bit inferiors. And I can even drop the whole prepared 200KB GDB patch. > > --- a/gdb/symfile-mem.c > > +++ b/gdb/symfile-mem.c > > @@ -72,6 +73,7 @@ symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, char *name, > > bfd_vma loadbase; > > struct section_addr_info *sai; > > unsigned int i; > > + int addr_bit = gdbarch_addr_bit (target_gdbarch); > > > > if (bfd_get_flavour (templ) != bfd_target_elf_flavour) > > error (_("add-symbol-file-from-memory not supported for this target")); > > @@ -103,6 +105,9 @@ symbol_file_add_from_memory (struct bfd *templ, CORE_ADDR addr, char *name, > > if ((bfd_get_section_flags (nbfd, sec) & (SEC_ALLOC|SEC_LOAD)) != 0) > > { > > sai->other[i].addr = bfd_get_section_vma (nbfd, sec) + loadbase; > > + if (addr_bit < (sizeof (ULONGEST) * HOST_CHAR_BIT)) > > + sai->other[i].addr &= ((ULONGEST) 1 << addr_bit) - 1; > > + > > sai->other[i].name = (char *) bfd_get_section_name (nbfd, sec); > > sai->other[i].sectindex = sec->index; > > ++i; > > I'm somewhat worried about this change. Does this mean that on x86 > Linux executables get loaded at an address that is high enough that we > section address basically wrap around? In fact always: As 32bit vDSO is built for (non-randomized) address 0xffffe000 but it gets placed thanks to the randomization on random VMA space: 00d36000-00d37000 r-xp 00000000 00:00 0 [vdso] > Also, if we go this route, I bet you'll be adding code like this to a > lot of functions. It may be better to introduce a function that > returns the mask directly, say gdbarch_addr_mask() and use that > unconditionally, like: > > sai->other[i].addr = bfd_get_section_vma (nbfd, sec) + loadbase; > + sai->other[i].addr &= gdbarch_addr_mask(gdbarch); This patch followed the current GDB way of doing it. My prepared but hopefully obsoleted now patch was using specifically: sai->other[i].addr = addr_add_offset (gdbarch, sai->other[i].addr, loadbase); Thanks, Jan