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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

  Powered by Linux