Re: Typecasting a void pointer to unsigned long in zsmalloc.c

[Leam Hall <leamhall@gmail.com>]

On 1/24/25 15:45, Sotir Danailov wrote:
> I found this page which looks a bit legacy and doesn't seem to be
> linked on kernel.org anywhere: https://www.kernel.org/doc/
> In here, under "Standards documents applicable to the Linux kernel",
> there's an interesting line:
> "LP64 standard defining the size of char, short, int, and long on
> 32-bit and 64-bit platforms." and it links to this:
> https://unix.org/whitepapers/64bit.html
> In the link, under "64-bit Data Models", there's a table, which shows
> that LP64 means:
> char 8 bits, short 16 bits, int 32 bits, long 64 bits, pointer 64 bits
> 
> This lead me to:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build
> which explains that for "System V AMD64 ABI":
> on page 12: "all pointer types are 64-bit objects (LP64)"
> on page 17: there's a table showing that "unsigned long (LP64)" is 8 bytes.
> 
> Finally, in GCC's manual for x86:
> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mabi-7
> "The default is to use the Microsoft ABI when targeting Microsoft
> Windows and the SysV ABI on all other systems."
> 
> I was wondering how it worked for other architectures, so I decided to
> grep the Makefiles in the Linux tree and apparently for some
> architectures it's explicitly stated:
> ./arch/arm64/Makefile:53:KBUILD_CFLAGS    += $(call cc-option,-mabi=lp64)
> ./arch/riscv/Makefile:33:    KBUILD_CFLAGS += -mabi=lp64
> 
> What I found in kernelnewbies: https://kernelnewbies.org/InternalKernelDataTypes
> "One thing that has caused a lot of problems, as 64-bit machines are
> getting more popular, is the fact that the size of a pointer is not
> the same as the size of an unsigned integer. The size of a pointer is
> equal to the size of an unsigned long."
> 
> I think there should be an explanation both on kernel.org and
> kernelnewbies what determines the sizes, so that people can have a
> better idea of what's going on. It should be something that is easy to
> find and part of "introductions" to kernel development, because it's
> not obvious at all how all of these things are setup. To me it seems
> fundamental, to be able to quickly find easy to digest information
> regarding the data types you're working with.


Sotir, great research!

Sadly, https://kernelnewbies.org is giving a "ConfigurationError".  :(  So I'm not sure if the reference to https://www.kernel.org/doc/ is already in place, or not. Something to check when KN is back up.

I'd think pointing to good documents is better than replicating them and risk staleness, isn't it?

Leam


Linux Software Engineer   (reuel.net/career)
Scribe: The Domici War    (domiciwar.net)
Coding Ne'er-do-well      (github.com/LeamHall)

Between "can" and "can't" is a gap of "I don't know", a place of discovery. For the passionate, much of "can't" falls into "yet". -- lh

Practice allows options and foresight. -- lh

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies