Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Joseph,
> On Tue, 25 Feb 2020, Lukasz Majewski wrote:
>
> > Lets consider for example __mq_timedsend_time64.
> >
> > With lib_hidden_def/proto kept (NOT removed as in [1]):
> > GDB:
> > __GI___mq_timedsend_time64 [*]
> >
> > (No build errors, linking with test setup works as expected).
>
> What is the actual testcase, and the exact command line used to
> compile it?
The test case is a separate program [1] compiled with [2] (the
test_y2038 make target)
The glibc under test is installed on rootfs run by QEMU for ARM.
The lack of redirection, when I keep lib_hidden_proto/
lib_hidden_def for __mq_timedsend_time64, is seen when I debug
with GDB the 'test_y2038' program.
The glibc compiles correctly.
>
> _TIME_BITS=64 redirection is only relevant for programs built with
> glibc, using the installed headers - not for building glibc itself.
>
> lib_hidden_proto is only relevant for building glibc, with its
> internal headers - not for programs built with glibc.
It seems like not removing lib_hidden_proto/ lib_hidden_def
for __mq_timedsend_time64 in glibc sources prevents the redirection on
installed glibc / headers when 'test_y2038' program is run.
>
> If you're talking about a glibc testcase, such tests should be in
> tests not tests-internal, so _ISOMAC is defined when they are built,
> so the glibc internal headers just wrap the public ones without
> defining anything else. In particular, the asm redirections from
> public headers should be in effect when tests are compiled, but not
> the lib_hidden_proto redirections (but even for internal tests,
> lib_hidden_proto shouldn't do anything because the build
> process knows they are tests not part of libc).
Unfortunately, mine Y2038 tests are a set of compiled programs (it is a
'legacy' code) and have nothing in common with glibc test suite.
The workflow is as follows (standard Yocto/OE):
1. Built the glibc and prepare "package" for other recipes.
2. For tests get the glibc "package" as a prerequisite. Use its
exported headers and libraries to build tests. Prepare test "package"
3. Install both above packages to rootfs
4. Run the rootfs with QEMU.
>
> You should look at the preprocessed source from building the test
> with -save-temps and find out why the asm redirection from the public
> header isn't being effective (or if it is effective in the .o file
> for the test, look at what happens afterwards in glibc). Since
> lib_hidden_proto should not be called in the parts of headers
> included when building a test, its presence or absence should have no
> effect on the preprocessed source of the test.
Ok. I will dig the object files and generated temp files.
>
> > hidden_def (__mq_timedsend)
> > weak_alias (__mq_timedsend, mq_timedsend) [**]
> > hidden_weak (mq_timedsend)
>
> If you have lib_hidden_weak note you also need a corresponding
> lib_hidden_proto, for the name of the weak alias. But you
> probably don't need to have lib_hidden* for the weak alias at
> all, just make sure internal calls use the internal name.
As fair as I can tell the weak_alias () is necessary for correct
operation of mq_timedsend when external programs call it.
Glibc internally defines __mq_timedsend (also for archs with
__WORDSIZE==64), but it exports mq_timedsend (and user space programs
call it). One needs an alias (at least a weak one) between mq_timedsend
and __mq_timedsend{_time}. Am I correct?
>
Links:
[1] -
https://github.com/lmajewski/y2038-tests/blob/master/test_mq_timedsend.c#L25
[2] - https://github.com/lmajewski/y2038-tests/blob/master/Makefile
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpeaDpaxTvWW.pgp
Description: OpenPGP digital signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers
On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote: > This adds tests which will validate architecture page table helpers and > other accessors in their compliance with expected generic MM semantics. > This will help various architectures in validating changes to existing > page table helpers or addition of new ones. > > This test covers basic page table entry transformations including but not > limited to old, young, dirty, clean, write, write protect etc at various > level along with populating intermediate entries with next page table page > and validating them. > > Test page table pages are allocated from system memory with required size > and alignments. The mapped pfns at page table levels are derived from a > real pfn representing a valid kernel text symbol. This test gets called > inside kernel_init() right after async_synchronize_full(). > > This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected. Any > architecture, which is willing to subscribe this test will need to select > ARCH_HAS_DEBUG_VM_PGTABLE. For now this is limited to arc, arm64, x86, s390 > and ppc32 platforms where the test is known to build and run successfully. > Going forward, other architectures too can subscribe the test after fixing > any build or runtime problems with their page table helpers. Meanwhile for > better platform coverage, the test can also be enabled with CONFIG_EXPERT > even without ARCH_HAS_DEBUG_VM_PGTABLE. > > Folks interested in making sure that a given platform's page table helpers > conform to expected generic MM semantics should enable the above config > which will just trigger this test during boot. Any non conformity here will > be reported as an warning which would need to be fixed. This test will help > catch any changes to the agreed upon semantics expected from generic MM and > enable platforms to accommodate it thereafter. How useful is this that straightly crash the powerpc? [ 23.263425][T1] debug_vm_pgtable: debug_vm_pgtable: Validating architecture page table helpers [ 23.263625][T1] [ cut here ] [ 23.263649][T1] kernel BUG at arch/powerpc/mm/pgtable.c:274! [ 23.263675][T1] Oops: Exception in kernel mode, sig: 5 [#1] [ 23.263698][T1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV [ 23.263731][T1] Modules linked in: [ 23.263752][T1] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc3-next- 20200226 #1 [ 23.263776][T1] NIP: c007308c LR: c103dbd8 CTR: 0000 [ 23.263810][T1] REGS: c0003ddaf9c0 TRAP: 0700 Not tainted (5.6.0- rc3-next-20200226) [ 23.263846][T1] MSR: 90029033 CR: 22000228 XER: [ 23.263888][T1] CFAR: c0073030 IRQMASK: 0 [ 23.263888][T1] GPR00: c103dbd8 c0003ddafc50 c1656f00 c01d7b4ca080 [ 23.263888][T1] GPR04: 0009 c0003ddafc04 [ 23.263888][T1] GPR08: f0ff 0001 c16279d0 000a [ 23.263888][T1] GPR12: c01fae00 c0010e84 [ 23.263888][T1] GPR16: 8105 0100 c1689a18 [ 23.263888][T1] GPR20: c00020032c66 c00020032c62 c1716030 c00020032c60 [ 23.263888][T1] GPR24: 000d c1716030 c01d7b4ca080 c1716040 [ 23.263888][T1] GPR28: c1716038 [ 23.264122][T1] NIP [c007308c] assert_pte_locked+0x11c/0x320 [ 23.264154][T1] LR [c103dbd8] debug_vm_pgtable+0x770/0xb7c [ 23.264186][T1] Call Trace: [ 23.264206][T1] [c0003ddafc50] [c0999760] _raw_spin_unlock+0x30/0x70 (unreliable) [ 23.264244][T1] [c0003ddafcd0] [c103d924] debug_vm_pgtable+0x4bc/0xb7c [ 23.264279][T1] [c0003ddafdb0] [c0010eac] kernel_init+0x30/0x194 [ 23.264315][T1] [c0003ddafe20] [c000b748] ret_from_kernel_thread+0x5c/0x74 [ 23.264349][T1] Instruction dump: [ 23.264368][T1] 6000 3be1 7fbef436 eafa0040 7fffc030 3bff 7fff07b4 7038 [ 23.264409][T1] 7bff1f24 7d37f82a 7d290074 7929d182 <0b09> ebdb e93c 7fde4a14 [ 23.264460][T1] ---[ end trace 72d2931022e9ab24 ]--- [ 23.627311][T1] [ 24.627407][T1] Kernel panic - not syncing: Fatal exception [ 26.5 > > Cc: Andrew Morton > Cc: Mike Rapoport > Cc: Vineet Gupta > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Heiko Carstens > Cc: Vasily Gorbik > Cc: Christian Borntraeger > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav
Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers
On Wed, 2020-02-26 at 09:09 -0500, Qian Cai wrote: > On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote: > > This adds tests which will validate architecture page table helpers and > > other accessors in their compliance with expected generic MM semantics. > > This will help various architectures in validating changes to existing > > page table helpers or addition of new ones. > > > > This test covers basic page table entry transformations including but not > > limited to old, young, dirty, clean, write, write protect etc at various > > level along with populating intermediate entries with next page table page > > and validating them. > > > > Test page table pages are allocated from system memory with required size > > and alignments. The mapped pfns at page table levels are derived from a > > real pfn representing a valid kernel text symbol. This test gets called > > inside kernel_init() right after async_synchronize_full(). > > > > This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected. Any > > architecture, which is willing to subscribe this test will need to select > > ARCH_HAS_DEBUG_VM_PGTABLE. For now this is limited to arc, arm64, x86, s390 > > and ppc32 platforms where the test is known to build and run successfully. > > Going forward, other architectures too can subscribe the test after fixing > > any build or runtime problems with their page table helpers. Meanwhile for > > better platform coverage, the test can also be enabled with CONFIG_EXPERT > > even without ARCH_HAS_DEBUG_VM_PGTABLE. > > > > Folks interested in making sure that a given platform's page table helpers > > conform to expected generic MM semantics should enable the above config > > which will just trigger this test during boot. Any non conformity here will > > be reported as an warning which would need to be fixed. This test will help > > catch any changes to the agreed upon semantics expected from generic MM and > > enable platforms to accommodate it thereafter. > > How useful is this that straightly crash the powerpc? And then generate warnings on arm64, [ 146.634626][T1] debug_vm_pgtable: debug_vm_pgtable: Validating architecture page table helpers [ 146.643995][T1] [ cut here ] [ 146.649350][T1] virt_to_phys used for non-linear address: (ptrval) (start_kernel+0x0/0x580) [ 146.658840][T1] WARNING: CPU: 165 PID: 1 at arch/arm64/mm/physaddr.c:15 __virt_to_phys+0x98/0xe0 [ 146.667976][T1] Modules linked in: [ 146.671741][T1] CPU: 165 PID: 1 Comm: swapper/0 Tainted: G L5.6.0-rc3-next-20200226 #1 [ 146.681397][T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019 [ 146.691840][T1] pstate: 6049 (nZCv daif +PAN -UAO) [ 146.697334][T1] pc : __virt_to_phys+0x98/0xe0 [ 146.702045][T1] lr : __virt_to_phys+0x98/0xe0 [ 146.706753][T1] sp : 18ff00082b7afe10 [ 146.710766][T1] x29: 18ff00082b7afe30 x28: [ 146.716782][T1] x27: x26: [ 146.722798][T1] x25: x24: [ 146.728813][T1] x23: x22: [ 146.734827][T1] x21: x20: 9000135b4000 [ 146.740842][T1] x19: 900011200858 x18: [ 146.746857][T1] x17: x16: [ 146.752872][T1] x15: x14: 3078302b6c656e72 [ 146.758887][T1] x13: 656b5f7472617473 x12: 90001369ea90 [ 146.764901][T1] x11: 00c9 x10: 800082b76c0e [ 146.770917][T1] x9 : 9d6a2e2260401300 x8 : 9d6a2e2260401300 [ 146.776932][T1] x7 : x6 : [ 146.782946][T1] x5 : 0080 x4 : [ 146.788960][T1] x3 : 0010 x2 : 0008 [ 146.794975][T1] x1 : 0006 x0 : 0053 [ 146.800990][T1] Call trace: [ 146.804140][T1] __virt_to_phys+0x98/0xe0 [ 146.808512][T1] debug_vm_pgtable+0x74/0x3fc [ 146.813140][T1] kernel_init+0x1c/0x208 [ 146.817334][T1] ret_from_fork+0x10/0x18 [ 146.821608][T1] irq event stamp: 19843388 [ 146.825978][T1] hardirqs last enabled at (19843387): [] console_unlock+0x8d0/0x970 [ 146.835553][T1] hardirqs last disabled at (19843388): [] do_debug_exception+0x58/0x2cc [ 146.845387][T1] softirqs last enabled at (19843384): [] __do_softirq+0x864/0x900 [ 146.854796][T1] softirqs last disabled at (19843377): [] irq_exit+0x1c8/0x238 [ 146.863845][T1] ---[ end trace 31678d9e845dff89 ]--- > > [ 23.263425][T1] debug_vm_pgtable: debug_vm_pgtable: Validating > architecture page table help
Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers
Le 26/02/2020 à 15:12, Qian Cai a écrit : On Wed, 2020-02-26 at 09:09 -0500, Qian Cai wrote: On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote: How useful is this that straightly crash the powerpc? And then generate warnings on arm64, [ 146.634626][T1] debug_vm_pgtable: debug_vm_pgtable: Validating architecture page table helpers [ 146.643995][T1] [ cut here ] [ 146.649350][T1] virt_to_phys used for non-linear address: (ptrval) (start_kernel+0x0/0x580) Must be something wrong with the following in debug_vm_pgtable() paddr = __pa(&start_kernel); Is there any explaination why start_kernel() is not in linear memory on ARM64 ? Christophe ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers
Le 26/02/2020 à 15:09, Qian Cai a écrit : On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote: This adds tests which will validate architecture page table helpers and other accessors in their compliance with expected generic MM semantics. This will help various architectures in validating changes to existing page table helpers or addition of new ones. This test covers basic page table entry transformations including but not limited to old, young, dirty, clean, write, write protect etc at various level along with populating intermediate entries with next page table page and validating them. Test page table pages are allocated from system memory with required size and alignments. The mapped pfns at page table levels are derived from a real pfn representing a valid kernel text symbol. This test gets called inside kernel_init() right after async_synchronize_full(). This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected. Any architecture, which is willing to subscribe this test will need to select ARCH_HAS_DEBUG_VM_PGTABLE. For now this is limited to arc, arm64, x86, s390 and ppc32 platforms where the test is known to build and run successfully. Going forward, other architectures too can subscribe the test after fixing any build or runtime problems with their page table helpers. Meanwhile for better platform coverage, the test can also be enabled with CONFIG_EXPERT even without ARCH_HAS_DEBUG_VM_PGTABLE. Folks interested in making sure that a given platform's page table helpers conform to expected generic MM semantics should enable the above config which will just trigger this test during boot. Any non conformity here will be reported as an warning which would need to be fixed. This test will help catch any changes to the agreed upon semantics expected from generic MM and enable platforms to accommodate it thereafter. How useful is this that straightly crash the powerpc? [ 23.263425][T1] debug_vm_pgtable: debug_vm_pgtable: Validating architecture page table helpers [ 23.263625][T1] [ cut here ] [ 23.263649][T1] kernel BUG at arch/powerpc/mm/pgtable.c:274! The problem on PPC64 is known and has to be investigated and fixed. Christophe ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
On Wed, 26 Feb 2020, Lukasz Majewski wrote: > > > hidden_def (__mq_timedsend) > > > weak_alias (__mq_timedsend, mq_timedsend) [**] > > > hidden_weak (mq_timedsend) > > > > If you have lib_hidden_weak note you also need a corresponding > > lib_hidden_proto, for the name of the weak alias. But you > > probably don't need to have lib_hidden* for the weak alias at > > all, just make sure internal calls use the internal name. > > As fair as I can tell the weak_alias () is necessary for correct > operation of mq_timedsend when external programs call it. I wasn't commenting on the weak_alias call, but on the hidden_weak one. If you have hidden_weak (mq_timedsend), you also need lib_hidden_proto (mq_timedsend) in the internal header (and vice versa, hidden_proto implies you need hidden_weak). You don't need hidden_weak (mq_timedsend) unless there is an *internal call to mq_timedsend from within the same library that defines it*. Since such an internal call could just use __mq_timedsend instead, you probably don't need hidden_weak / hidden_proto for mq_timedsend. (If you don't have an internal call to __mq_timedsend, you don't need the hidden_* for that name either.) -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers
On Wed, 2020-02-26 at 15:45 +0100, Christophe Leroy wrote: > > Le 26/02/2020 à 15:09, Qian Cai a écrit : > > On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote: > > > This adds tests which will validate architecture page table helpers and > > > other accessors in their compliance with expected generic MM semantics. > > > This will help various architectures in validating changes to existing > > > page table helpers or addition of new ones. > > > > > > This test covers basic page table entry transformations including but not > > > limited to old, young, dirty, clean, write, write protect etc at various > > > level along with populating intermediate entries with next page table page > > > and validating them. > > > > > > Test page table pages are allocated from system memory with required size > > > and alignments. The mapped pfns at page table levels are derived from a > > > real pfn representing a valid kernel text symbol. This test gets called > > > inside kernel_init() right after async_synchronize_full(). > > > > > > This test gets built and run when CONFIG_DEBUG_VM_PGTABLE is selected. Any > > > architecture, which is willing to subscribe this test will need to select > > > ARCH_HAS_DEBUG_VM_PGTABLE. For now this is limited to arc, arm64, x86, > > > s390 > > > and ppc32 platforms where the test is known to build and run successfully. > > > Going forward, other architectures too can subscribe the test after fixing > > > any build or runtime problems with their page table helpers. Meanwhile for > > > better platform coverage, the test can also be enabled with CONFIG_EXPERT > > > even without ARCH_HAS_DEBUG_VM_PGTABLE. > > > > > > Folks interested in making sure that a given platform's page table helpers > > > conform to expected generic MM semantics should enable the above config > > > which will just trigger this test during boot. Any non conformity here > > > will > > > be reported as an warning which would need to be fixed. This test will > > > help > > > catch any changes to the agreed upon semantics expected from generic MM > > > and > > > enable platforms to accommodate it thereafter. > > > > How useful is this that straightly crash the powerpc? > > > > [ 23.263425][T1] debug_vm_pgtable: debug_vm_pgtable: Validating > > architecture page table helpers > > [ 23.263625][T1] [ cut here ] > > [ 23.263649][T1] kernel BUG at arch/powerpc/mm/pgtable.c:274! > > The problem on PPC64 is known and has to be investigated and fixed. It might be interesting to hear what powerpc64 maintainers would say about it and if it is actually worth "fixing" in the arch code, but that BUG_ON() was there since 2009 and had not been exposed until this patch comes alone? ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64)
Hi Joseph, > On Wed, 26 Feb 2020, Lukasz Majewski wrote: > > > > > hidden_def (__mq_timedsend) > > > > weak_alias (__mq_timedsend, mq_timedsend) [**] > > > > hidden_weak (mq_timedsend) > > > > > > If you have lib_hidden_weak note you also need a > > > corresponding lib_hidden_proto, for the name of the weak > > > alias. But you probably don't need to have lib_hidden* for > > > the weak alias at all, just make sure internal calls use the > > > internal name. > > > > As fair as I can tell the weak_alias () is necessary for correct > > operation of mq_timedsend when external programs call it. > > I wasn't commenting on the weak_alias call, but on the hidden_weak > one. Ach... indeed - sorry for misunderstanding. > > If you have hidden_weak (mq_timedsend), you also need > lib_hidden_proto (mq_timedsend) in the internal header (and > vice versa, hidden_proto implies you need hidden_weak). > > You don't need hidden_weak (mq_timedsend) unless there is an > *internal call to mq_timedsend from within the same library that > defines it*. > > Since such an internal call could just use __mq_timedsend instead, > you probably don't need hidden_weak / hidden_proto for mq_timedsend. > > (If you don't have an internal call to __mq_timedsend, you don't need > the hidden_* for that name either.) > Thanks for the explanation. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpJmlc3KmuVy.pgp Description: OpenPGP digital signature ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
ELF_INITFINI for ARC (was Re: [PATCH] Introduce and ELF_INITFINI for all architectures)
Hi Florian,
On 2/20/20 10:48 AM, Florian Weimer wrote:
> * Andreas Schwab:
>
>> environ is empty.
>
> That's because libc.so.6 still has DT_INIT, from which _environ and
> other variables are set up. I assumed binutils would convert that into
> DT_INITARRAY because the architecture is not supposed to have DT_INIT.
> Without that, it's hard to declare that there is no DT_INIT, and the
> patch essentially breaks ABI (because DT_INIT processing is gone).
>
> This should fix the breakage:
>
> Subject: Use ELF constructor instead of _init in libc.so
>
> On !ELF_INITFINI architectures, _init is no longer called by the dynamic
> linker. We can use an ELF constructor instead because the constructor
> order does not matter. (The other constructors are used to set up libio
> vtable bypasses and do not depend on this initialization routine.)
>
> diff --git a/csu/init-first.c b/csu/init-first.c
> index 1cd8a75098..1fa1633657 100644
> --- a/csu/init-first.c
> +++ b/csu/init-first.c
> @@ -46,9 +46,8 @@ __libc_init_first (int argc, char **argv, char **envp)
>/* For DSOs we do not need __libc_init_first but instead _init. */
> }
>
> -void
> -attribute_hidden
> -_init (int argc, char **argv, char **envp)
> +static void __attribute__ ((constructor))
> +init (int argc, char **argv, char **envp)
> {
> #endif
>
This (or lack thereof) turned out to be the nasty busbox sh crash (and kernel
init
panic) on ARC based off rebased upstream (latest RV32 from Alistair) containing
the original patch f4349837d93b4df. I tried this fixup and it seems to work. The
DT_INIT entry goes away and init does run as part of init_array.
It seems that commit also removed init_array from sysdeps/{riscv,csky}/Implies -
so newer arches. I suppose I need to do that for ARC as well - but could you
please explain (or point to documentation) which explains how this the Implies
stuff works.
> But I'm no longer sure if RISC-V is actually an !ELF_INITFINI
> architecture.
And an arch is !ELF_INITFINI if it supports initarray ?
I did switch ARC gcc [1] / binutils [2]to initarray last year
[1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-January/005318.html
[2]
http://lists.infradead.org/pipermail/linux-snps-arc/2019-February/005388.html
Thx,
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ELF_INITFINI for ARC (was Re: [PATCH] Introduce and ELF_INITFINI for all architectures)
* Vineet Gupta:
> It seems that commit also removed init_array from
> sysdeps/{riscv,csky}/Implies - so newer arches. I suppose I need to do
> that for ARC as well - but could you please explain (or point to
> documentation) which explains how this the Implies stuff works.
You are very lucky. The mechanism is explained in the section Porting
the GNU C Library in the manual:
It's one of the few aspects of our build systems that's documented.
However, in commit f4349837d93b4dfe9ba09791e280ee2d6c99919f ("Introduce
and ELF_INITFINI for all architectures") I replaced the
use of the implies mechanism with a new header file, .
This allows us to control the default for new targets in a more explicit
way. Previously, new ports had to include initarray explicitly, and we
know from past experience (the lack of removal of the sysctl function
comes to my mind) that this does not work.
>> But I'm no longer sure if RISC-V is actually an !ELF_INITFINI
>> architecture.
>
> And an arch is !ELF_INITFINI if it supports initarray ?
Not necessarily. glibc always supports DT_INITARRAY for all targets,
but on some targets, it is necessary to honor DT_INIT/DT_FINI for legacy
binaries at least. (I hope no targets are left where binutils produces
DT_INIT for regular ELF constructors, but I haven't checked.)
> I did switch ARC gcc [1] / binutils [2]to initarray last year
>
> [1]
> http://lists.infradead.org/pipermail/linux-snps-arc/2019-January/005318.html
> [2]
> http://lists.infradead.org/pipermail/linux-snps-arc/2019-February/005388.html
I haven't followed the ARC contribution process closely, sorry. Do you
plan to contribute the port with a GLIBC_2.32 ABI baseline, or do you
want to support older binaries for an earlier non-upstream port,
backdating the baseline?
This matters because in the GLIBC_2.32 case, old binaries will not work
anyway, so we may as well require that they are rebuilt without
DT_INIT/DT_FINI. In this case, the glibc master defaults should work.
If you want to support old binaries (which use older symbol versions
such as GLIBC_2.17), it may make sense to keep DT_INIT/DT_FINI support
as well. To achieve this, you need to add an header
file with
/* Enable DT_INIT/DT_FINI support. */
#define ELF_INITFINI 1
and keep the crti.S and crtn.S files you already have.
Thanks,
Florian
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ELF_INITFINI for ARC (was Re: [PATCH] Introduce and ELF_INITFINI for all architectures)
On 2/26/20 11:27 AM, Florian Weimer wrote: > I haven't followed the ARC contribution process closely, sorry. Do you > plan to contribute the port with a GLIBC_2.32 ABI baseline, or do you > want to support older binaries for an earlier non-upstream port, > backdating the baseline? No we don't need to support old binaries: 2.32 will be baseline > This matters because in the GLIBC_2.32 case, old binaries will not work > anyway, so we may as well require that they are rebuilt without > DT_INIT/DT_FINI. In this case, the glibc master defaults should work. Understood ! > If you want to support old binaries (which use older symbol versions > such as GLIBC_2.17), it may make sense to keep DT_INIT/DT_FINI support > as well. To achieve this, you need to add an header > file with > > /* Enable DT_INIT/DT_FINI support. */ > #define ELF_INITFINI 1 > > and keep the crti.S and crtn.S files you already have. Per the review comments on ARC port last year [1], I was advised to remove the ARC specific crt*.S so those are anyhow gone. [1] https://sourceware.org/ml/libc-alpha/2019-01/msg00654.html ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers
On 02/26/2020 08:14 PM, Christophe Leroy wrote: > > > Le 26/02/2020 à 15:12, Qian Cai a écrit : >> On Wed, 2020-02-26 at 09:09 -0500, Qian Cai wrote: >>> On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote: >>> >>> How useful is this that straightly crash the powerpc? >> >> And then generate warnings on arm64, >> >> [ 146.634626][T1] debug_vm_pgtable: debug_vm_pgtable: Validating >> architecture page table helpers >> [ 146.643995][T1] [ cut here ] >> [ 146.649350][T1] virt_to_phys used for non-linear address: >> (ptrval) (start_kernel+0x0/0x580) > > Must be something wrong with the following in debug_vm_pgtable() > > paddr = __pa(&start_kernel); > > Is there any explaination why start_kernel() is not in linear memory on ARM64 > ? Cc: + James Morse This warning gets exposed with DEBUG_VIRTUAL due to __pa() on a kernel symbol i.e 'start_kernel' which might be outside the linear map. This happens due to kernel mapping position randomization with KASLR. Adding James here in case he might like to add more. __pa_symbol() should have been used instead, for accessing the physical address here. On arm64 __pa() does check for linear address with __is_lm_address() and switch accordingly if it is a kernel text symbol. Nevertheless, its much better to use __pa_symbol() here rather than __pa(). Rather than respining the patch once more, will just send a fix replacing this helper __pa() with __pa_symbol() for Andrew to pick up as this patch is already part of linux-next (next-20200226). But can definitely respin if that will be preferred. Thanks Qian for catching this. > > Christophe > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers
On Thu, 27 Feb 2020 08:04:05 +0530 Anshuman Khandual wrote: > > Must be something wrong with the following in debug_vm_pgtable() > > > > paddr = __pa(&start_kernel); > > > > Is there any explaination why start_kernel() is not in linear memory on > > ARM64 ? > > > Cc: + James Morse > > This warning gets exposed with DEBUG_VIRTUAL due to __pa() on a kernel symbol > i.e 'start_kernel' which might be outside the linear map. This happens due to > kernel mapping position randomization with KASLR. Adding James here in case he > might like to add more. > > __pa_symbol() should have been used instead, for accessing the physical > address > here. On arm64 __pa() does check for linear address with __is_lm_address() and > switch accordingly if it is a kernel text symbol. Nevertheless, its much > better > to use __pa_symbol() here rather than __pa(). > > Rather than respining the patch once more, will just send a fix replacing this > helper __pa() with __pa_symbol() for Andrew to pick up as this patch is > already > part of linux-next (next-20200226). But can definitely respin if that will be > preferred. I didn't see this fix? I assume it's this? If so, are we sure it's OK to be added to -next without testing?? From: Andrew Morton Subject: mm-debug-add-tests-validating-architecture-page-table-helpers-fix A warning gets exposed with DEBUG_VIRTUAL due to __pa() on a kernel symbol i.e 'start_kernel' which might be outside the linear map. This happens due to kernel mapping position randomization with KASLR. __pa_symbol() should have been used instead, for accessing the physical address here. On arm64 __pa() does check for linear address with __is_lm_address() and switch accordingly if it is a kernel text symbol. Nevertheless, its much better to use __pa_symbol() here rather than __pa(). Reported-by: Qian Cai Cc: Anshuman Khandual Cc: James Morse Cc: Christophe Leroy Signed-off-by: Andrew Morton --- mm/debug_vm_pgtable.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/debug_vm_pgtable.c~mm-debug-add-tests-validating-architecture-page-table-helpers-fix +++ a/mm/debug_vm_pgtable.c @@ -331,7 +331,7 @@ void __init debug_vm_pgtable(void) * helps avoid large memory block allocations to be used for mapping * at higher page table levels. */ - paddr = __pa(&start_kernel); + paddr = __pa_symbol(&start_kernel); pte_aligned = (paddr & PAGE_MASK) >> PAGE_SHIFT; pmd_aligned = (paddr & PMD_MASK) >> PAGE_SHIFT; _ ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V14] mm/debug: Add tests validating architecture page table helpers
On 02/27/2020 09:33 AM, Andrew Morton wrote: > On Thu, 27 Feb 2020 08:04:05 +0530 Anshuman Khandual > wrote: > >>> Must be something wrong with the following in debug_vm_pgtable() >>> >>> paddr = __pa(&start_kernel); >>> >>> Is there any explaination why start_kernel() is not in linear memory on >>> ARM64 ? >> >> >> Cc: + James Morse >> >> This warning gets exposed with DEBUG_VIRTUAL due to __pa() on a kernel symbol >> i.e 'start_kernel' which might be outside the linear map. This happens due to >> kernel mapping position randomization with KASLR. Adding James here in case >> he >> might like to add more. >> >> __pa_symbol() should have been used instead, for accessing the physical >> address >> here. On arm64 __pa() does check for linear address with __is_lm_address() >> and >> switch accordingly if it is a kernel text symbol. Nevertheless, its much >> better >> to use __pa_symbol() here rather than __pa(). >> >> Rather than respining the patch once more, will just send a fix replacing >> this >> helper __pa() with __pa_symbol() for Andrew to pick up as this patch is >> already >> part of linux-next (next-20200226). But can definitely respin if that will be >> preferred. > > I didn't see this fix? I assume it's this? If so, are we sure it's OK to be > added to -next without testing?? My patch just missed your response here within a minute :) Please consider this. It has been tested on x86 and arm64. https://patchwork.kernel.org/patch/11407715/ > > > > From: Andrew Morton > Subject: mm-debug-add-tests-validating-architecture-page-table-helpers-fix > > A warning gets exposed with DEBUG_VIRTUAL due to __pa() on a kernel symbol > i.e 'start_kernel' which might be outside the linear map. This happens > due to kernel mapping position randomization with KASLR. > > __pa_symbol() should have been used instead, for accessing the physical > address here. On arm64 __pa() does check for linear address with > __is_lm_address() and switch accordingly if it is a kernel text symbol. > Nevertheless, its much better to use __pa_symbol() here rather than > __pa(). > > Reported-by: Qian Cai > Cc: Anshuman Khandual > Cc: James Morse > Cc: Christophe Leroy > Signed-off-by: Andrew Morton > --- > > mm/debug_vm_pgtable.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- > a/mm/debug_vm_pgtable.c~mm-debug-add-tests-validating-architecture-page-table-helpers-fix > +++ a/mm/debug_vm_pgtable.c > @@ -331,7 +331,7 @@ void __init debug_vm_pgtable(void) >* helps avoid large memory block allocations to be used for mapping >* at higher page table levels. >*/ > - paddr = __pa(&start_kernel); > + paddr = __pa_symbol(&start_kernel); > > pte_aligned = (paddr & PAGE_MASK) >> PAGE_SHIFT; > pmd_aligned = (paddr & PMD_MASK) >> PAGE_SHIFT; > _ > > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
