openslx-ng/ipxe.git/src/arch/i386, branch openslx

[build] Allow for the existence of small-data sections

2025-06-24T13:40:57+00:00

Signed-off-by: Michael Brown

[build] Allow for 32-bit and 64-bit versions of util/zbin

2025-05-06T11:11:02+00:00

Parsing ELF data is simpler if we don't have to build a single binary to handle both 32-bit and 64-bit ELF formats. Allow for separate 32-bit and 64-bit binaries built from util/zbin.c (as is already done for util/elf2efi.c). Signed-off-by: Michael Brown

[profile] Standardise return type of profile_timestamp()

2024-09-24T14:40:45+00:00

All consumers of profile_timestamp() currently treat the value as an unsigned long. Only the elapsed number of ticks is ever relevant: the absolute value of the timestamp is not used. Profiling is used to measure short durations that are generally fewer than a million CPU cycles, for which an unsigned long is easily large enough. Standardise the return type of profile_timestamp() as unsigned long across all CPU architectures. This allows 32-bit architectures such as i386 and riscv32 to omit all logic associated with retrieving the upper 32 bits of the 64-bit hardware counter, which simplifies the code and allows riscv32 and riscv64 to share the same implementation. Signed-off-by: Michael Brown

[efi] Remove redundant EFI_BOOT_FILE definitions

2024-09-16T10:04:52+00:00

As of commit 79c0173 ("[build] Create util/genfsimg for building filesystem-based images"), the EFI boot file name for each CPU architecture is defined within the genfsimg script itself, rather than being passed in as a Makefile parameter. Remove the now-redundant Makefile definitions for EFI_BOOT_FILE. Reported-by: Christian I. Nilsson Signed-off-by: Michael Brown

[libc] Centralise architecture-independent portions of setjmp.h

2024-09-12T14:01:04+00:00

The definitions of the setjmp() and longjmp() functions are common to all architectures, with only the definition of the jump buffer structure being architecture-specific. Move the architecture-specific portions to bits/setjmp.h and provide a common setjmp.h for the function definitions. Signed-off-by: Michael Brown

[gdb] Allow CPU architectures to omit support for GDB

2024-09-05T12:00:39+00:00

Move the file to , and provide a common dummy implementation for all architectures that have not yet implemented support for GDB. Signed-off-by: Michael Brown

[build] Fix building with newer binutils

2024-01-14T12:16:02+00:00

Newer versions of the GNU assembler (observed with binutils 2.41) will complain about the ".arch i386" in files assembled with "as --64", with the message "Error: 64bit mode not supported on 'i386'". In files such as stack.S that contain no instructions to be assembled, the ".arch i386" is redundant and may be removed entirely. In the remaining files, fix by moving ".arch i386" below the relevant ".code16" or ".code32" directive, so that the assembler is no longer expecting 64-bit instructions to be used by the time that the ".arch i386" directive is encountered. Reported-by: Ali Mustakim Signed-off-by: Michael Brown

[build] Inhibit linker warnings about an implied executable stack

2023-06-30T10:05:37+00:00

Signed-off-by: Geert Stappers Modified-by: Michael Brown Signed-off-by: Michael Brown

[build] Allow for per-architecture unprefixed constant operand modifier

2023-02-05T23:55:14+00:00

Over the years, the undocumented operand modifier used to produce the unprefixed constant values in __einfo_error() has varied from "%c0" to "%a0" in commit 1a77466 ("[build] Fix use of inline assembly on GCC 4.8 ARM64 builds") and back to "%c0" in commit 3fb3ffc ("[build] Fix use of inline assembly on GCC 8 ARM64 builds"), according to the evolving demands of the toolchain. LoongArch64 suffers from a similar issue: GCC 13 will allow either, but the currently released GCC 12 allows only the "%a0" form. Introduce a macro ASM_NO_PREFIX, defined in bits/compiler.h, to abstract away this difference and allow different architectures to use different operand modifiers. Signed-off-by: Michael Brown

[dhcp] Simplify platform-specific client architecture definitions

2023-01-22T17:45:34+00:00

Move the platform-specific DHCP client architecture definitions to header files of the form . This simplifies the directory structure and allows the otherwise unused arch/$(ARCH)/include/$(PLATFORM) to be removed from the include directory search path, which avoids the confusing situation in which a header file may potentially be accessed through more than one path. For Linux userspace binaries on any architecture, use the EFI values for that architecture by delegating to the EFI header file. This avoids the need to explicitly select values for Linux userspace binaries for each architecture. Signed-off-by: Michael Brown