Search notes:

arch/x86/boot/header.S

arch/x86/boot/header.S defines a _start symbol.
Does a bootloader like GRUB jump to this location when it has loaded the kernel image?

Optional Header

AddressOfEntryPoint

The value of AddressOfEntryPoint is filled by arch/x86/boot/tools/build so that it points to efi_pe_entry (defined in drivers/firmware/efi/libstub/x86-stub.c and located in the .text section), see source code.

Global symbol hdr

The linker script arch/x86/boot/setup.ld puts the .header section to offset 495.
Because the .header section has a sentinel of two bytes and is then followed by hdr, the offset of hdr is 497.
The . = ASSERT(hdr = 0x1f1, …) in the arch/x86/boot/setup.ld makes sure that hdr starts at the offset 497.
hdr seems to correspond to the member hdr (whose type is struct setup_header) of struct boot_params.
The binary file for this header is compiled into arch/x86/boot/setup.bin.

TODO

The file contains the following comments
Documentation/admin-guide/efi-stub.rst contains this quote:
On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade as a PE/COFF image, thereby convincing EFI firmware loaders to load it as an EFI executable. The code that modifies the bzImage header, along with the EFI-specific entry point that the firmware loader jumps to are collectively known as the "EFI boot stub", and live in arch/x86/boot/header.S and drivers/firmware/efi/libstub/x86-stub.c, respectively.
The file contains the following code which I assume to jump to the main function defined in arch/x86/boot/main.c: 
# Jump to C code (should not return)
  calll   main
CONFIG_EFI_STUB
header.S includes arch/x86/boot/zoffset.h.

See also

It seems that the compressed output of header.S is decompressed with functionality defined in arch/x86/boot/compressed/misc.c.

Index