Message ID | 20211216194222.186992-1-adhemerval.zanella@linaro.org |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DA5603858439 for <patchwork@sourceware.org>; Thu, 16 Dec 2021 19:42:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DA5603858439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1639683767; bh=CAhVpGzH5RqwbGhbMQgSVU63Xl30s9AgoTXLSWKfKRA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=muc3ucUhVn+XyLTYWQEeuMrPMgk0YTzOEDe2rqEqMb2xXdOeHVG+XMyiuCfvDaK3x EdpScRYtwStLXK+UXrsTlc+30Uvek7JIBfE8L2SASfPFJhAW8WjA1mQuNRhn7qkyFY WTWRA2PXhaXbuXjRRctclVi9VpfN4lXURZJ9Y0/w= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by sourceware.org (Postfix) with ESMTPS id 917B93858414 for <libc-alpha@sourceware.org>; Thu, 16 Dec 2021 19:42:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 917B93858414 Received: by mail-qv1-xf2f.google.com with SMTP id p3so262847qvj.9 for <libc-alpha@sourceware.org>; Thu, 16 Dec 2021 11:42:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=CAhVpGzH5RqwbGhbMQgSVU63Xl30s9AgoTXLSWKfKRA=; b=tPUTEKBQASTE8GuIqMyKw4fje28J+0FlloplB6XiDHWLB+onW1Pcfw2onpWaKdPHe3 vudFOabwVrx5BHJ8sfT3KYyLlXassLzQIx+rN/omryefSgNqXtpZSPqEN5ajx9neayTz uv7humBnA2S7c56P5kmAMtbx8Uwse/+/wuANiajZl6vl/di8IFJmu9ccceZDnv4f/y/3 vfae3WBV6W0bic/o3PXBP+XZK0RFUeGTJTXpkdFJlqKShIhZAyR5XZp0UEgJk9i2YcP3 pbKEZNLNJGl/sdr6KO2Fbzy9iUnsY63165xzgNAEaVL4xDs/gqYuxqMlGhRs2zor4Q+L ElBA== X-Gm-Message-State: AOAM532ux79NC0GX9xQ4LCB38te5V6LFfFJRoexIbFsPJ+l9l5pfpRbu JjEvYTaNftnOoUQXkakWJ7nl2Jt78oIrng== X-Google-Smtp-Source: ABdhPJzBuKIcImhYBXSyyHdBiY9cZdhk82CLcqSykcYekQpMvB2C28//a4LiFZOdvbXTH4rk10wwbQ== X-Received: by 2002:ad4:5e8e:: with SMTP id jl14mr12049931qvb.112.1639683746068; Thu, 16 Dec 2021 11:42:26 -0800 (PST) Received: from birita.. ([2804:431:c7ca:103f:96e9:fe91:2aff:a44d]) by smtp.gmail.com with ESMTPSA id br13sm3503836qkb.10.2021.12.16.11.42.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Dec 2021 11:42:25 -0800 (PST) To: libc-alpha@sourceware.org, Stafford Horne <shorne@gmail.com> Subject: [PATCH 0/5] Architecture code cleanup Date: Thu, 16 Dec 2021 16:42:17 -0300 Message-Id: <20211216194222.186992-1-adhemerval.zanella@linaro.org> X-Mailer: git-send-email 2.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Adhemerval Zanella <adhemerval.zanella@linaro.org> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series | Architecture code cleanup | |
Message
Adhemerval Zanella Netto
Dec. 16, 2021, 7:42 p.m. UTC
These cleanups come from reviewing the OpenRISC submission. The tcb-offset.h is used mostly on setjmp/longjmp implementation to provide pointer mangle/demangle, but most ports do not use its definition (it should speed up a bit the build process). The libmemusage requires duplicate definition and adds a lot of boilerplate code: its internal atomics can be replaces by C11 atomics, which allows remove a lof of atomic-machine.h internal types; the internal time can be replaced with hp-timing.h, and for stack pointer information we can use either the __thread_stack_pointer (hurd) or CURRENT_STACK_FRAME (Linux). Adhemerval Zanella (5): Remove ununsed tcb-offset malloc: Use C11 atomics on libmemusage Remove atomic-machine.h boilerplates definition malloc: Use hp-timing on libmemusage malloc: Remove memusage.h malloc/memusage.c | 65 +++++++++++-------- sysdeps/aarch64/atomic-machine.h | 17 ----- sysdeps/aarch64/memusage.h | 21 ------ sysdeps/aarch64/nptl/Makefile | 21 ------ sysdeps/aarch64/nptl/tcb-offsets.sym | 6 -- sysdeps/aarch64/nptl/tls.h | 3 - sysdeps/alpha/atomic-machine.h | 27 +------- sysdeps/alpha/memusage.h | 20 ------ sysdeps/alpha/nptl/Makefile | 20 ------ sysdeps/alpha/nptl/tcb-offsets.sym | 13 ---- sysdeps/alpha/nptl/tls.h | 2 - sysdeps/arc/atomic-machine.h | 12 ---- sysdeps/arc/memusage.h | 23 ------- sysdeps/arc/nptl/Makefile | 22 ------- sysdeps/arc/nptl/tcb-offsets.sym | 11 ---- sysdeps/arm/atomic-machine.h | 17 ----- sysdeps/arm/memusage.h | 20 ------ sysdeps/arm/nptl/Makefile | 4 -- sysdeps/arm/nptl/tcb-offsets.sym | 10 --- sysdeps/arm/nptl/tls.h | 3 - sysdeps/csky/Makefile | 4 -- sysdeps/csky/atomic-machine.h | 10 --- sysdeps/csky/memusage.h | 21 ------ sysdeps/csky/nptl/Makefile | 20 ------ sysdeps/csky/nptl/tcb-offsets.sym | 10 --- sysdeps/csky/nptl/tls.h | 1 - sysdeps/generic/memusage.h | 51 --------------- sysdeps/hppa/memusage.h | 21 ------ sysdeps/hppa/nptl/Makefile | 20 ------ sysdeps/hppa/nptl/tcb-offsets.sym | 17 ----- sysdeps/hppa/nptl/tls.h | 3 - sysdeps/i386/htl/machine-sp.h | 2 +- sysdeps/i386/i586/memusage.h | 1 - sysdeps/i386/memusage.h | 20 ------ sysdeps/ia64/atomic-machine.h | 26 -------- sysdeps/ia64/memusage.h | 29 --------- sysdeps/m68k/coldfire/atomic-machine.h | 31 --------- sysdeps/m68k/m680x0/m68020/atomic-machine.h | 28 -------- sysdeps/m68k/memusage.h | 21 ------ sysdeps/m68k/nptl/Makefile | 20 ------ sysdeps/m68k/nptl/tcb-offsets.sym | 10 --- sysdeps/m68k/nptl/tls.h | 3 - sysdeps/mach/hurd/i386/tls.h | 1 - sysdeps/mach/i386/machine-sp.h | 2 +- sysdeps/microblaze/atomic-machine.h | 17 ----- sysdeps/microblaze/memusage.h | 21 ------ sysdeps/microblaze/nptl/Makefile | 21 ------ sysdeps/microblaze/nptl/tcb-offsets.sym | 10 --- sysdeps/microblaze/nptl/tls.h | 3 - sysdeps/mips/atomic-machine.h | 17 ----- sysdeps/mips/memusage.h | 20 ------ sysdeps/mips/nptl/Makefile | 20 ------ sysdeps/mips/nptl/tcb-offsets.sym | 10 --- sysdeps/mips/nptl/tls.h | 2 - sysdeps/nios2/Makefile | 4 -- sysdeps/nios2/memusage.h | 23 ------- sysdeps/powerpc/atomic-machine.h | 17 ----- sysdeps/powerpc/memusage.h | 20 ------ sysdeps/riscv/memusage.h | 21 ------ sysdeps/riscv/nptl/Makefile | 21 ------ sysdeps/riscv/nptl/tcb-offsets.sym | 6 -- sysdeps/s390/atomic-machine.h | 27 -------- sysdeps/s390/memusage.h | 20 ------ sysdeps/sh/memusage.h | 20 ------ sysdeps/sparc/atomic-machine.h | 27 -------- sysdeps/sparc/memusage.h | 20 ------ sysdeps/unix/sysv/linux/hppa/atomic-machine.h | 17 ----- .../sysv/linux/m68k/coldfire/atomic-machine.h | 11 ---- .../sysv/linux/machine-sp.h} | 16 +++-- .../unix/sysv/linux/nios2/atomic-machine.h | 12 ---- .../unix/sysv/linux/riscv/atomic-machine.h | 13 ---- sysdeps/unix/sysv/linux/sh/atomic-machine.h | 28 -------- sysdeps/x86/atomic-machine.h | 40 ++---------- sysdeps/x86_64/memusage.h | 21 ------ 74 files changed, 60 insertions(+), 1174 deletions(-) delete mode 100644 sysdeps/aarch64/memusage.h delete mode 100644 sysdeps/aarch64/nptl/Makefile delete mode 100644 sysdeps/aarch64/nptl/tcb-offsets.sym delete mode 100644 sysdeps/alpha/memusage.h delete mode 100644 sysdeps/alpha/nptl/Makefile delete mode 100644 sysdeps/alpha/nptl/tcb-offsets.sym delete mode 100644 sysdeps/arc/memusage.h delete mode 100644 sysdeps/arc/nptl/Makefile delete mode 100644 sysdeps/arc/nptl/tcb-offsets.sym delete mode 100644 sysdeps/arm/memusage.h delete mode 100644 sysdeps/arm/nptl/tcb-offsets.sym delete mode 100644 sysdeps/csky/memusage.h delete mode 100644 sysdeps/csky/nptl/Makefile delete mode 100644 sysdeps/csky/nptl/tcb-offsets.sym delete mode 100644 sysdeps/generic/memusage.h delete mode 100644 sysdeps/hppa/memusage.h delete mode 100644 sysdeps/hppa/nptl/Makefile delete mode 100644 sysdeps/hppa/nptl/tcb-offsets.sym delete mode 100644 sysdeps/i386/i586/memusage.h delete mode 100644 sysdeps/i386/memusage.h delete mode 100644 sysdeps/ia64/memusage.h delete mode 100644 sysdeps/m68k/memusage.h delete mode 100644 sysdeps/m68k/nptl/Makefile delete mode 100644 sysdeps/m68k/nptl/tcb-offsets.sym delete mode 100644 sysdeps/microblaze/memusage.h delete mode 100644 sysdeps/microblaze/nptl/Makefile delete mode 100644 sysdeps/microblaze/nptl/tcb-offsets.sym delete mode 100644 sysdeps/mips/memusage.h delete mode 100644 sysdeps/mips/nptl/Makefile delete mode 100644 sysdeps/mips/nptl/tcb-offsets.sym delete mode 100644 sysdeps/nios2/memusage.h delete mode 100644 sysdeps/powerpc/memusage.h delete mode 100644 sysdeps/riscv/memusage.h delete mode 100644 sysdeps/riscv/nptl/Makefile delete mode 100644 sysdeps/riscv/nptl/tcb-offsets.sym delete mode 100644 sysdeps/s390/memusage.h delete mode 100644 sysdeps/sh/memusage.h delete mode 100644 sysdeps/sparc/memusage.h rename sysdeps/{i386/i686/memusage.h => unix/sysv/linux/machine-sp.h} (68%) delete mode 100644 sysdeps/x86_64/memusage.h
Comments
On Thu, 16 Dec 2021, Adhemerval Zanella via Libc-alpha wrote: > The libmemusage requires duplicate definition and adds a lot of > boilerplate code: its internal atomics can be replaces by > C11 atomics, which allows remove a lof of atomic-machine.h > internal types; the internal time can be replaced with hp-timing.h, > and for stack pointer information we can use either the > __thread_stack_pointer (hurd) or CURRENT_STACK_FRAME (Linux). Has this patch series been tested with build-many-glibcs.py? (I'm concerned with making sure the atomics aren't introducing any circular dependencies on libatomic - that they're expanded entirely inline or to use libgcc operations.)
On 16/12/2021 18:41, Joseph Myers wrote: > On Thu, 16 Dec 2021, Adhemerval Zanella via Libc-alpha wrote: > >> The libmemusage requires duplicate definition and adds a lot of >> boilerplate code: its internal atomics can be replaces by >> C11 atomics, which allows remove a lof of atomic-machine.h >> internal types; the internal time can be replaced with hp-timing.h, >> and for stack pointer information we can use either the >> __thread_stack_pointer (hurd) or CURRENT_STACK_FRAME (Linux). > > Has this patch series been tested with build-many-glibcs.py? (I'm > concerned with making sure the atomics aren't introducing any circular > dependencies on libatomic - that they're expanded entirely inline or to > use libgcc operations.) > The C11 usage is for the types, memusage.c still uses catomic_* functions (which it is not optimal). My plan is to clean this up later patch.
On 16/12/2021 20:08, Adhemerval Zanella wrote: > > > On 16/12/2021 18:41, Joseph Myers wrote: >> On Thu, 16 Dec 2021, Adhemerval Zanella via Libc-alpha wrote: >> >>> The libmemusage requires duplicate definition and adds a lot of >>> boilerplate code: its internal atomics can be replaces by >>> C11 atomics, which allows remove a lof of atomic-machine.h >>> internal types; the internal time can be replaced with hp-timing.h, >>> and for stack pointer information we can use either the >>> __thread_stack_pointer (hurd) or CURRENT_STACK_FRAME (Linux). >> >> Has this patch series been tested with build-many-glibcs.py? (I'm >> concerned with making sure the atomics aren't introducing any circular >> dependencies on libatomic - that they're expanded entirely inline or to >> use libgcc operations.) >> > > The C11 usage is for the types, memusage.c still uses catomic_* functions > (which it is not optimal). My plan is to clean this up later patch. Scratch that, I just realized that did use _Atomic. I will check with build-many-glibcs.py.
On 16/12/2021 20:35, Adhemerval Zanella wrote: > > > On 16/12/2021 20:08, Adhemerval Zanella wrote: >> >> >> On 16/12/2021 18:41, Joseph Myers wrote: >>> On Thu, 16 Dec 2021, Adhemerval Zanella via Libc-alpha wrote: >>> >>>> The libmemusage requires duplicate definition and adds a lot of >>>> boilerplate code: its internal atomics can be replaces by >>>> C11 atomics, which allows remove a lof of atomic-machine.h >>>> internal types; the internal time can be replaced with hp-timing.h, >>>> and for stack pointer information we can use either the >>>> __thread_stack_pointer (hurd) or CURRENT_STACK_FRAME (Linux). >>> >>> Has this patch series been tested with build-many-glibcs.py? (I'm >>> concerned with making sure the atomics aren't introducing any circular >>> dependencies on libatomic - that they're expanded entirely inline or to >>> use libgcc operations.) >>> >> >> The C11 usage is for the types, memusage.c still uses catomic_* functions >> (which it is not optimal). My plan is to clean this up later patch. > > Scratch that, I just realized that did use _Atomic. I will check with > build-many-glibcs.py. It does pass on handful of architecture that might use libatomic, but thinking again it does seems the best strategy to use C11 atomics while issuing glibc handcrafted atomic functions/macros. I will just replace with plain [u]intXX_t types, since it is what we usually do in other places.