On Wed, Jan 22, 2025 at 11:18:44AM +0000, Jon Hunter wrote: > > On 22/01/2025 10:26, Arnd Bergmann wrote: > > On Wed, Jan 22, 2025, at 11:07, Niklas Cassel wrote: > > > On Tue, Jan 21, 2025 at 05:46:43PM +0000, Jon Hunter wrote: > > > > > diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/>> > > > > > > > > This change breaks building the kernel with GCC v7 and I see ... > > > > > > > > ERROR: modpost: "__aeabi_uldivmod" [drivers/misc/pci_endpoint_test.ko] > > > > undefined! > > > > ERROR: modpost: "__aeabi_ldivmod" [drivers/misc/pci_endpoint_test.ko] > > > > undefined! > > > > > > > > I know that this is an old GCC version, but this is a farm builder and the > > > > kernel still indicates that GCC v5.1 is still supported [0]. > > > > > > do you have any idea what is going on here? > > > > > > I'm a bit puzzled, since looking at other reports of this error, > > > e.g.: > > > https://lore.kernel.org/all/20241018151016.3496613-1-arnd@xxxxxxxxxx/ > > > > > > using div_u64() is usually the solution for this problem (for things that > > > are not performance critical), not the cause of it... any ideas? > > > > I have tried to look at the email thread, but not tried to reproduce > > it yet. I have two ideas about what might be happening: > > > > a) something causes a /different/ division to call into > > __aeabi_uldivmod(), not the one from div_u64(). > > > > b) the compiler notices one of the arguments to div_u64() being > > constant in some cases and splits the calling function into > > two special cases, for both the constant and non-constant > > cases. This sometimes confuses the __builtin_constant_p() > > in do_div() that decides to fall back to a 32-bit division. > > > > Try looking at the .s file when you run > > 'make drivers/misc/pci_endpoint_test.s' to see where exactly it > > calls the two division functions, maybe you see the problem then, > > otherwise I can try to reproduce it here. > > > FWIW I have encountered similar problems with this before with this compiler > ... > > https://lore.kernel.org/linux-tegra/7733a4ca-330b-4127-af12-33f376fbbc47@xxxxxxxxxx/ I had no errors when building this patch using: gcc (Debian 7.4.0-6) 7.4.0 on i386. neither with CONFIG_PHYS_ADDR_T_64BIT=y (CONFIG_X86_PAE=y) nor without it set. So perhaps this is a bug in gcc 7.x on arm32 or in the arm32 implementation of div_u64() ? Kind regards, Niklas
