OSDev.org

bzt wrote:And since you were so consistent, I'd like to kindly ask you to show us one implementation that defines NULL other than 0.

Several compilers used nonzero values internally to represent the null pointer. You might find such a definition in the header files commonly used with these compilers. The C standard says the integer 0 converted to a pointer to void is a null pointer, so headers often define NULL as "((void*)0)" and let the compiler work out exactly which internal representation to use.

GCC explicitly states that any pointer-sized integer converted to a pointer will use the same internal representation, which means that a pointer to address 0 will be a null pointer in GCC. I seem to recall finding a patch for GCC that changed the internal null pointer representation to a different bit pattern, but I can't find it now. If I recall correctly, this patched version of GCC still used 0 converted to a pointer to represent null, and used a different nonzero integer when converting to or from a pointer to address 0.

bzt wrote:Without a header, there's no NULL, and without NULL there's no NULL dereference, period.

C99 draft WG14/N1256 section 6.3.2.3 paragraph 3 wrote:An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.

The standard does not require the NULL macro to be defined for there to be a null pointer.

bzt wrote:Is it really too hard to focus on POSIX-UEFI? Please keep on topic!

I thought we were talking about compiler bugs you uncovered while developing POSIX-UEFI? I don't have any particularly strong feelings about the POSIX-like interface, but I can see how it can be a useful abstraction. (Does its file handling also work with TFTP for PXE boot?)

bzt wrote:Which version are you using?

gcc (Debian 8.3.0-6) 8.3.0

Octocontrabass wrote:An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.

And where is the address 0 or a cast to void* in memmap.bda? Nowhere.

Octocontrabass wrote:Does its file handling also work with TFTP for PXE boot?

UEFI itself does not support TFTP any more, it moved on to HTTPS. I'm planing to add support for that.

Octocontrabass wrote:gcc (Debian 8.3.0-6) 8.3.0

Ok, I won't ask you nor accept any testing results from you. Good to know. Nothing personal, I just don't care about 2 years old compilers.

Cheers,
bzt

bzt wrote:And where is the address 0 or a cast to void* in memmap.bda? Nowhere.

What is a "var = memmap.bda"? I can't seem to find it anywhere in your source code. Google only finds this thread (no other hit).

kzinti wrote:What is a "var = memmap.bda"? I can't seem to find it anywhere in your source code. Google only finds this thread (no other hit).

So you actually admit that you haven't read my posts? That's just so sad, I really do feel sorry for you.

Cheers,
bzt

bzt wrote:So you actually admit that you haven't read my posts? That's just so sad, I really do feel sorry for you.

I am trying to understand what you are saying and re-reading the whole thread didn't allow me to understand what you mean by "var = memmap.bda".

Your reply is a good example of you being rude and arrogant.

bzt wrote:And where is the address 0 or a cast to void* in memmap.bda?

Isn't the address of memmap 0? That would make it a null pointer, so accessing any of its members is undefined behavior.

bzt wrote:UEFI itself does not support TFTP any more, it moved on to HTTPS.

Where can I find out more about the removal of TFTP support?

Octocontrabass wrote:

bzt wrote:UEFI itself does not support TFTP any more, it moved on to HTTPS.

Where can I find out more about the removal of TFTP support?

They made quite a big fuzz about it back in 2015. TFTP was obsoleted 6 years ago.

Version 2.5 of the UEFI specification introduces the UEFI HTTP Boot feature. You can use the basic UEFI HTTP Boot client to chainload iPXE from an HTTP server, eliminating the need for a separate TFTP server in your boot infrastructure.

Now 6 years later, manufacturers are widely supporting this, so it's just a matter of time when gets the PXE TFTP interface removed from firmware images.

https://uefi.org/sites/default/files/re ... ver1.2.pdf "Goodbye PXE and IPMI. Welcome HTTP Boot and Redfish"
https://ipxe.org/appnote/uefihttp
https://firmwaresecurity.com/tag/uefi-http-boot/
https://lenovopress.com/lp0736.pdf

Cheers,
bzt

Where do they say they're removing TFTP support? I checked all of those links, but I didn't see it anywhere.

Octocontrabass wrote:Where do they say they're removing TFTP support? I checked all of those links, but I didn't see it anywhere.

*Sigh* I've even quoted. Note "Goodbye PXE" and "eliminating the need for a separate TFTP server in your boot infrastructure". You can be sure that sooner or later the interface (and with it the theoretical possibility to support TFTP) will be gone too, just like legacy CSM died out. But that part isn't interesting, the point is, in practice UEFI is already using HTTP in its place, most server parks are not supporting TFTP any more, so POSIX_UEFI should support HTTP and not the obsoleted protocol.

Cheers,
bzt

bzt wrote:I've even quoted.

"Eliminating the need for TFTP" does not mean "eliminating support for TFTP".

bzt wrote:most server parks are not supporting TFTP any more,

One of my previous employers (one of the biggest cloud providers in the world) still uses the CSM to PXE boot most of their hardware. They've only started to support UEFI because the newest hardware no longer has CSM. Even with UEFI they still use PXE and TFTP, not HTTP.

They haven't switched from IPMI to Redfish either.

This is awesome. I hate the UEFI API. CamelCase, CAPITALIZATION and BIG_LONG_FUNCTIONS_AND_VARIABLES_THAT_DO_STUFF. For this reason I've keept using legacy BIOS but this library you've built might make me switch to UEFI soon

catOS wrote:This is awesome. I hate the UEFI API. CamelCase, CAPITALIZATION and BIG_LONG_FUNCTIONS_AND_VARIABLES_THAT_DO_STUFF. For this reason I've keept using legacy BIOS but this library you've built might make me switch to UEFI soon

You're welcome! Give a star to the repo if you like it! Feel free to use gitlab's issue tracker if you run into any trouble.

Cheers,
bzt

Hello!

Thanks for the neat build system. I had a moment of fun after reading about various UEFI build systems, picking POSIX-UEFI, reading information online and coming across this forum thread, and finally realizing its author is the same user who sent me a really nice message about a QEMU patch I submitted months ago =)

Hello again, I should say.

I've been playing around with the various wrappers POSIX-UEFI provides, and am hitting up against a bug(?). It seems using malloc() at all (including indirectly via fopen()), even when balanced by free(), causes exit_bs() to fail. In particular, I'm unable to do anything with visible effect after BS->FreePool() is invoked, and thus it seems as though that call never returns. However, my UEFI debugging skills are definitely not up to chops, so there could be something else going on.

I've just cracked open the source of the library to dig around, but thought I'd pop in here in case there's something standard I'm missing.

Are you seeing this behavior in a VM? (It'll be a lot easier to debug if so.)

Can you provide code and a compiled binary that demonstrates the problem?

Thanks for the reply, Octocontrabass.

In fact, I'm seeing this issue in QEMU (qemu-system-x86_64 with an OMVF-pure-efi.fd from August 2021), but not on my motherboard's UEFI firmware.

I've been mucking about with my build system a bit and am unable to reproduce exactly what I described above, but I've got a simpler failure case now:
In QEMU's "serial0" output, I see "#UD - Invalid Opcode". I saw a previous thread in which someone mentioned this could be due to the use of SSE instructions that are emitted when dealing with variadics, but neither the lack of any printf() usage, nor ensuring -mno-sse and -mno-sse2 were added, have resolved this issue. I do have hope, though, since it's only in QEMU, though admittedly I'm a bit confused.

Here's QEMU's exception output: https://ibb.co/z4rWtF9

Here's an affected binary built in my environment with code pasted above: https://ufile.io/fh0oiho0

Here's a sample compiler invocation when building POSIX-UEFI itself: Here's the invocation when building my subproject: Thanks once again for your time and input =)