lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 24 Oct 2023 11:30:01 -0400
From:   Yazen Ghannam <>
To:     kernel test robot <>,,,
Subject: Re: [PATCH v2 1/2] RAS: Introduce AMD Address Translation Library

On 10/16/2023 8:28 AM, kernel test robot wrote:
> Hi Yazen,
> kernel test robot noticed the following build errors:
> [auto build test ERROR on ras/edac-for-next]
> [also build test ERROR on linus/master v6.6-rc6 next-20231016]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> url:
> base: edac-for-next
> patch link:
> patch subject: [PATCH v2 1/2] RAS: Introduce AMD Address Translation Library
> config: i386-buildonly-randconfig-002-20231016 (
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce (this is a W=1 build): (
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <>
> | Closes:
> All errors (new ones prefixed by >>):
>     ld: drivers/ras/amd/atl/denormalize.o: in function `denormalize_address':
>>> denormalize.c:(.text+0x84f): undefined reference to `__umoddi3'

This is the code of interest:
	addr_mod = temp_addr_b % 3;

"temp_addr_b" is a u64 value.

__umoddi3() takes "unsigned long" values as input. This works on x86_64 
where "unsigned long" is 64-bits, but will fail on i386 where "unsigned 
long" is 32-bits. I *think* __umodti3() should be used which takes 
"unsigned long long" values as input. This would work on both i386 and 
x86_64, since "unsigned long long" will be 64-bits.

I was able to reproduce the issue with GCC 9 and 10, and the issue is 
not present with GCC 11 and 12.

I'm assuming a compiler/linker issue at the moment. In particular, I 
wonder if gcc and ld need to be matched. I'm using a newer ld version 
(2.38), and this works with newer gcc versions (11 and 12) but fails 
with the older versions (9 and 10).

Any thoughts?


Powered by blists - more mailing lists