From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46001 invoked by alias); 24 Jun 2017 13:11:48 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 45915 invoked by uid 89); 24 Jun 2017 13:11:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=57PM X-HELO: mail-pf0-f177.google.com Received: from mail-pf0-f177.google.com (HELO mail-pf0-f177.google.com) (209.85.192.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 24 Jun 2017 13:11:43 +0000 Received: by mail-pf0-f177.google.com with SMTP id c73so35148114pfk.2 for ; Sat, 24 Jun 2017 06:11:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xcu/NfSSacpCK/DMVN7vN0NNvoU5rHpqFNohS//KTSc=; b=UusWApdhNrQteY+7QSl7rbVVWoTzrKvVQJG4MrZCpFzff5ayBsE/5dL3txqyHazf7u 9zku0CoVVT658o8s8FuqXbJ0Bk4gcIFQri4xLSU184DPmw6O9EyNgNcENA3lLyWf2mPM xXECxNnCqCT04ue67eghiGL8cjX7mcCBF88M7s9MHLBLKlVmcbW9NipPM7EAHAAKp0qA yj863iWsW2lT9OPVN29S6ocRveGEwaGE8chkDMKQuSHgEaLlmScpTZyTtE0hUhWuIiIk eWWGnEgcbhwZ3i8jA2ubsEPzp/fAFTK2X333n4gPSiY2rn/rD02/d8ZE6NCfpeNUe7bv TZxA== X-Gm-Message-State: AKS2vOzAUXs01XAaNzMXKR3sMj1FVcyylJxQ0BwkpMDjSoZ6yBG+JaUg jSuUdGLFEi3E1ITR X-Received: by 10.84.162.204 with SMTP id o12mr14706019plg.23.1498309902233; Sat, 24 Jun 2017 06:11:42 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-71-80.tyqh2.lon.bigpond.net.au. [58.160.71.80]) by smtp.gmail.com with ESMTPSA id d62sm15735203pga.2.2017.06.24.06.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jun 2017 06:11:41 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 45224C1B57; Sat, 24 Jun 2017 22:41:37 +0930 (ACST) Date: Sat, 24 Jun 2017 13:11:00 -0000 From: Alan Modra To: Alexander Fedotov Cc: binutils@sourceware.org, Edmar Wienskoski Subject: Re: [PATCH] PowerPC VLE changes Message-ID: <20170624131137.GL8406@bubble.grove.modra.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00324.txt.bz2 On Fri, Jun 23, 2017 at 11:51:57PM +0300, Alexander Fedotov wrote: > Hello Alan > > We want to upstream our changes for VLE, LSP, SPE2 and other stuff. > All of them are based on 2.28 release. Please rebase against current master, and provide Changelog entries. > - if (symaddr - reladdr + max_branch_offset > - < 2 * max_branch_offset) > - continue; > + > + /* I don't trust the relocation check using ' ... < (2 * max_branch_offset)' I do trust it. This change is silly. > - stub_rtype = R_PPC_RELAX; > + stub_rtype = (target_stub_type == stub_entry_type_vle) ? R_PPC_VLE_RELAX : R_PPC_RELAX; Overlong lines. Wrap to 80 chars or less. > @@ -7385,10 +7503,21 @@ > case R_PPC_REL24: > case R_PPC_LOCAL24PC: > case R_PPC_PLTREL24: > - t0 = bfd_get_32 (abfd, hit_addr); > - t0 &= ~0x3fffffc; > - t0 |= val & 0x3fffffc; > - bfd_put_32 (abfd, t0, hit_addr); > + if (r_type == R_PPC_PLTREL24 > + && (elf_section_flags (isec) & SHF_PPC_VLE) != 0) Something is fishy here. Why is PLTREL24 treated differently when VLE? You haven't changed the insn here! > @@ -9063,8 +9214,8 @@ > } > else > { > - stub = stub_entry; > - size = ARRAY_SIZE (stub_entry); > + stub = (r_type == R_PPC_VLE_RELAX) ? stub_entry_vle : stub_entry; > + size = ARRAY_SIZE (stub_entry); /* stub_entry and stub_entry_vle must be same size */ Overlong line again. An assert would be better than a comment. > --- binutils-2.28/binutils/objdump.c 2017-03-02 11:23:53.000000000 +0300 > +++ binutils-2.28-vle/binutils/objdump.c 2017-06-23 17:25:21.641299056 +0300 > @@ -481,6 +481,10 @@ > PF (SEC_NEVER_LOAD, "NEVER_LOAD"); > PF (SEC_EXCLUDE, "EXCLUDE"); > PF (SEC_SORT_ENTRIES, "SORT_ENTRIES"); > + if (bfd_get_arch(abfd) == bfd_arch_powerpc || bfd_get_arch (abfd) == bfd_mach_ppc_vle) > + { > + PF (SEC_TIC54X_BLOCK, "VLE"); /* hack, would have to include ppc.h */ > + } Ick. Don't do this, define a flag in bfd/section.c. > diff -ruN binutils-2.28/include/elf/ppc.h binutils-2.28-vle/include/elf/ppc.h > --- binutils-2.28/include/elf/ppc.h 2017-03-02 11:23:54.000000000 +0300 > +++ binutils-2.28-vle/include/elf/ppc.h 2017-06-23 17:34:20.838930833 +0300 > @@ -79,8 +79,10 @@ > RELOC_NUMBER (R_PPC_RELAX, 48) > RELOC_NUMBER (R_PPC_RELAX_PLT, 49) > RELOC_NUMBER (R_PPC_RELAX_PLTREL24, 50) > + RELOC_NUMBER (R_PPC_VLE_RELAX, 51) > /* Reloc only used internally by gas. As above, value is unimportant. */ > - RELOC_NUMBER (R_PPC_16DX_HA, 51) > + RELOC_NUMBER (R_PPC_16DX_HA, 52) > + RELOC_NUMBER (R_PPC_VLE_PLTREL24, 53) > #endif This seems an odd place to put R_PPC_VLE_PLTREL24. Is it just an internal relocation? (I don't see anything that would use it, nor the new R_PPC_VLE_ADDR20. Missing patch?) > +/* BFD section headers flag. */ > +#define SEC_PPC_VLE SEC_TIC54X_BLOCK No, this define is in the wrong place, and if you'd defined it in section.c you would see why you can't reuse SEC_TIC54X_BLOCK. -- Alan Modra Australia Development Lab, IBM