Typecasting a void pointer to unsigned long in zsmalloc.c
Sotir Danailov
sndanailov at gmail.com
Fri Jan 24 16:45:54 EST 2025
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.
More information about the Kernelnewbies
mailing list