From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31457 invoked by alias); 22 Feb 2013 00:58:48 -0000 Received: (qmail 31437 invoked by uid 22791); 22 Feb 2013 00:58:46 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-pb0-f49.google.com (HELO mail-pb0-f49.google.com) (209.85.160.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Feb 2013 00:58:41 +0000 Received: by mail-pb0-f49.google.com with SMTP id xa12so79908pbc.8 for ; Thu, 21 Feb 2013 16:58:41 -0800 (PST) X-Received: by 10.68.233.229 with SMTP id tz5mr76542pbc.172.1361494721328; Thu, 21 Feb 2013 16:58:41 -0800 (PST) Received: from bubble.grove.modra.org ([101.166.26.37]) by mx.google.com with ESMTPS id 1sm476013pbg.18.2013.02.21.16.58.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 16:58:40 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 87668EA19F6; Fri, 22 Feb 2013 11:28:33 +1030 (CST) Date: Fri, 22 Feb 2013 00:58:00 -0000 From: Alan Modra To: Tom Tromey Cc: "Maciej W. Rozycki" , Richard Sandiford , Catherine Moore , binutils@sourceware.org, gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] MIPS: Compressed PLT/stubs support Message-ID: <20130222005833.GJ3080@bubble.grove.modra.org> Mail-Followup-To: Tom Tromey , "Maciej W. Rozycki" , Richard Sandiford , Catherine Moore , binutils@sourceware.org, gdb-patches@sourceware.org References: <87wqu19y1x.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wqu19y1x.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2013-02/txt/msg00578.txt.bz2 On Thu, Feb 21, 2013 at 02:06:34PM -0700, Tom Tromey wrote: > Maciej> if (type != ST_SYNTHETIC) > Maciej> elf_sym = (elf_symbol_type *) sym; > Maciej> - else > Maciej> + else if (((sym->udata.i | 0xff) ^ 0xff) != 0) > Maciej> elf_sym = (elf_symbol_type *) sym->udata.p; > Maciej> + else > Maciej> + elf_sym = NULL; > > This seems iffy to me. I suppose what gives me pause is the possibility > that this condition will trigger on some other port that does something > odd in BFD. ppc64 is the only target that currently provides get_synthetic_symtab returning non-NULL values of udata. We have union { void *p; bfd_vma i; } udata; "i" is always 64 bits when ppc64 is supported by BFD. The size of "p" depends on the host. If they happen to both be 64-bit the analysis is easy and Maciej's change will break ppc64 if "p" can have an address in the range [0,255]. For 32-bit little-endian hosts we get the same result. For 32-bit big-endian hosts, "p" occupies the high 32 bits of "i", so any non-NULL value of "p" will pass the new test. I doubt we care about hosts that might allocate memory from the zero page, so Maciej's change is OK as far as I'm concerned. Hmm, perhaps a cleaner change would be implement make_msymbol_special for ppc64 and move the udata.p special case out of elf_symtab_read? -- Alan Modra Australia Development Lab, IBM