Message ID | mhng-6a19beb5-ec9a-420c-ae28-bd8cfae5e3da@palmer-si-x1c4 |
---|---|
State | New, archived |
Headers |
Received: (qmail 28649 invoked by alias); 20 Dec 2017 21:45:47 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 27544 invoked by uid 89); 20 Dec 2017 21:45:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy=H*RU:209.85.192.193, Hx-spam-relays-external:209.85.192.193, HContent-Transfer-Encoding:8bit X-HELO: mail-pf0-f193.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=2mt9DoXv9nD3l1PV5pOg3jFbmYq7TakhNUbZFeYql3o=; b=RvZQUBbvtkBb2ETuI6MSm6C6UF0MLcgUPJQ36NUd5M+MVeK7i2ruohqN53FRv9pbOR 7wy/aOnW6ztSdXxjnq434JrYVtXNUJSlbJhth9hKl3arxHPPWLBOfMLym+qg8QKc44NP Ef6vK02hTS4AU0ZVwHCZNRI2CEnSCYIUn0kQ+FQQcnf3aSft31ySnLvK8fEU6Rqw6ccg KsVqrpsiDylmnvtlCE7ZBA2E2wg2Ez2jAC/1DRydXuhtGW5cTZNvGw8UoGx64WKJGMxj 3qA9SsjM8jkemxc5s7t1v+bTFh7bycYbKGUC9utwpMy49lcJg5mhyrNFYZU77/eYc94J ffFg== X-Gm-Message-State: AKGB3mJK2Z0Y+XDMSkWW937c+oDxJtIQSMXFigLN8eiVocMcyebfD5Xo Bp1C6QkWtPB3PML72mo7CQ4Yes5ia88= X-Google-Smtp-Source: ACJfBovNwweXPV7WsfrEkBYF7iP9ie9qEGl/ZKY6c7bwPvclRtewc+iF2CA246QqULtrgQX5l4WUQA== X-Received: by 10.99.168.67 with SMTP id i3mr7519788pgp.330.1513806337268; Wed, 20 Dec 2017 13:45:37 -0800 (PST) Date: Wed, 20 Dec 2017 13:45:36 -0800 (PST) X-Google-Original-Date: Wed, 20 Dec 2017 13:40:16 PST (-0800) Subject: Re: RISC-V glibc port v2 In-Reply-To: <alpine.DEB.2.20.1712202108120.9009@digraph.polyomino.org.uk> CC: libc-alpha@sourceware.org, Andrew Waterman <andrew@sifive.com>, Darius Rad <darius@bluespec.com>, dj@redhat.com From: Palmer Dabbelt <palmer@dabbelt.com> To: joseph@codesourcery.com Message-ID: <mhng-6a19beb5-ec9a-420c-ae28-bd8cfae5e3da@palmer-si-x1c4> Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit |
Commit Message
Palmer Dabbelt
Dec. 20, 2017, 9:45 p.m. UTC
On Wed, 20 Dec 2017 13:11:02 PST (-0800), joseph@codesourcery.com wrote: > On Tue, 19 Dec 2017, Palmer Dabbelt wrote: > >> * Should we have padding in __pthread_rwlock_arch_t? I assume the padding on >> other architectures is there for ABI reasons and shouldn't be necessary for >> new ports, but the ports I usually rely on all have excatly the same padding >> so I'm worried there's another reason for this. > > The size was probably originally chosen to be the same as used by > Linuxthreads. Since then, there's been at least one rwlock rewrite that > increased the amount of space that's padding. > > On the whole I'd say it's safest to have that padding on RISC-V as well, > in case there are any more rewrites in future, since it's possible a > rewrite could increase the amount of space used as well as decreasing it, > and so if one architecture makes the type smaller than others that could > complicate any such future change needing more space. Sounds good. I'll add a comment
Comments
On 20/12/2017 19:45, Palmer Dabbelt wrote: > On Wed, 20 Dec 2017 13:11:02 PST (-0800), joseph@codesourcery.com wrote: >> On Tue, 19 Dec 2017, Palmer Dabbelt wrote: >> >>> * Should we have padding in __pthread_rwlock_arch_t? I assume the padding on >>> other architectures is there for ABI reasons and shouldn't be necessary for >>> new ports, but the ports I usually rely on all have excatly the same padding >>> so I'm worried there's another reason for this. >> >> The size was probably originally chosen to be the same as used by >> Linuxthreads. Since then, there's been at least one rwlock rewrite that >> increased the amount of space that's padding. >> >> On the whole I'd say it's safest to have that padding on RISC-V as well, >> in case there are any more rewrites in future, since it's possible a >> rewrite could increase the amount of space used as well as decreasing it, >> and so if one architecture makes the type smaller than others that could >> complicate any such future change needing more space. > > Sounds good. I'll add a comment > > diff --git a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h > index f15e024826ac..4fabc4a2cde2 100644 > --- a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h > +++ b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h > @@ -52,6 +52,10 @@ > #define __LOCK_ALIGNMENT > #define __ONCE_ALIGNMENT > > +/* There is a lot of padding in this structure. While it's not strictly > + necessary on RISC-V, we're going to leave it in to be on the safe side in > + case it's needed in the future. Most other architectures have the padding, > + so this gives us the same extensibility as everyone else has. */ > struct __pthread_rwlock_arch_t > { > unsigned int __readers; I have a patchset that should reorganize better the pthread type internal structures and add default version that will make new ports easier (no need to redefine them unless the port requires something special). I am planning to send it for reviews today or tomorrow.
On Mon, 25 Dec 2017, Adhemerval Zanella wrote: > I have a patchset that should reorganize better the pthread type > internal structures and add default version that will make new ports > easier (no need to redefine them unless the port requires something > special). I am planning to send it for reviews today or tomorrow. I think such a change is clearly too risky to go in during the release freeze, so it's not clear it's of any relevance to a new port being considered right now (unless consideration of such a port extends past the 2.27 release, of course).
diff --git a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h index f15e024826ac..4fabc4a2cde2 100644 --- a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h +++ b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h @@ -52,6 +52,10 @@ #define __LOCK_ALIGNMENT #define __ONCE_ALIGNMENT +/* There is a lot of padding in this structure. While it's not strictly + necessary on RISC-V, we're going to leave it in to be on the safe side in + case it's needed in the future. Most other architectures have the padding, + so this gives us the same extensibility as everyone else has. */ struct __pthread_rwlock_arch_t { unsigned int __readers;