| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <mcb30@ipxe.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The semantics of the assembler's .align directive vary by CPU
architecture. For the ARM builds, it specifies a power of two rather
than a number of bytes. This currently leads to the .einfo entries
(which do not appear in the final binary) having an alignment of 256
bytes for the ARM builds.
Fix by switching to the GNU-specific directive .balign, which is
consistent across architectures
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 1a7746603 ("[build] Fix use of inline assembly on GCC 4.8 ARM64
builds") switched from using "%c0" to "%a0" in order to avoid an
"invalid operand prefix" error on the ARM64 version of GCC 4.8.
It appears that the ARM64 version of GCC 8 now produces an "invalid
address mode" error for the "%a0" form, but is happy with the original
"%c0" form.
Switch back to using the "%c0" form, on the assumption that the
requirement for "%a0" was a temporary aberration.
Originally-fixed-by: John L. Jolly <jjolly@suse.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inline assembly used in include/errno.h to generate the einfo
blocks requires the ability to generate an immediate constant with no
immediate-value prefix (such as the dollar sign for x86 assembly).
We currently achieve this via the undocumented "%c0" form of operand.
This causes an "invalid operand prefix" error on GCC 4.8 for ARM64
builds.
Fix by switching to the equally undocumented "%a0" form of operand,
which appears to work correctly on all tested versions of GCC.
Reported-by: Benjamin S. Allen <bsallen@alcf.anl.gov>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some architectures (such as ARM) the "@" character is used as a
comment delimiter. A section type argument such as "@progbits"
therefore becomes "%progbits".
This is further complicated by the fact that the "%" character has
special meaning for inline assembly when input or output operands are
used, in which cases "@progbits" becomes "%%progbits".
Allow the section type character(s) to be defined via Makefile
variables.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
|
|
| |
Relicense files for which I am the sole author (as identified by
util/relicense.pl).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
|
|
|
|
|
| |
The low 8 bits of an iPXE error code are currently defined as the
closest equivalent PXE error code. Generalise this scheme to
platforms other than PC-BIOS by extending this definition to "closest
equivalent platform error code". This allows for the possibility of
returning meaningful errors via EFI APIs.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
| |
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
| |
Suggested-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
|
|
|
|
|
| |
Error numbers are signed ints. EUNIQ() should not allow implicit type
promotion based on the supplied error diambiguator, because this
causes problems with statements such as
rc = ( condition ? -EUNIQ ( EBASE, disambiguator ) : -EBASE );
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
|
|
| |
Add preprocessor magic to the error definitions to enable every error
usage to be tracked.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Access to the gpxe.org and etherboot.org domains and associated
resources has been revoked by the registrant of the domain. Work
around this problem by renaming project from gPXE to iPXE, and
updating URLs to match.
Also update README, LOG and COPYRIGHTS to remove obsolete information.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
|
|
|
|
|
| |
Add FILE_LICENCE declarations to almost all files that make up the
various standard builds of gPXE.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Change the PXE return code for EWOULDBLOCK from PXENV_STATUS_FAILURE
to PXENV_STATUS_TFTP_OPEN. This code is only used by the FILE_READ
PXEXT call, and is necessary to distinguish "error" from "no data" in
that call.
(The only other nonblocking call is UDP_READ, where the caller doesn't
care about the distinction, however, gPXE doesn't use EWOULDBLOCK
internally to represent this condition in that code.)
|
| |
|
|
|
|
| |
posix_io.c and this PXE error makes more sense in this context.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
will enable us to cascade async operations, which is necessary in order to
properly support DNS. (For example, an HTTP request may have to redirect
to a new location and will have to perform a new DNS lookup, so we can't
just rely on doing the name lookup at the time of parsing the initial
URL).
Anything other than HTTP is probably broken right now; I'll fix the others
up asap.
|
|
|
|
|
|
| |
as allocated by malloc()) versus all other errors, in particular
ENOBUFS (representing a lack of external buffer space, e.g. in a
device's TX queue or a user buffer).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
is a DHCP option" data structures.
We need this code in order to be able to return a DHCP packet to a PXE NBP
which reflects options from our multiple sources (e.g. NVS and DHCP
server). This is expensive, but necessary. Having paid this cost, we may
as well try to use the same code to generate our DHCP request packets,
since the process is similar.
|
| |
|
|
|
|
|
|
| |
of them in one go.
EBADIMG has been replaced by ENOEXEC, and EIMGRET by ECANCELED.
|
|
|
|
|
|
|
|
|
| |
I want to get to the point where any header in include/ reflects a
standard user-level header (e.g. a POSIX header), while everything that's
specific to gPXE lives in include/gpxe/. Headers that reflect a Linux
header (e.g. if_ether.h) should also be in include/gpxe/, with the same
name as the Linux header and, preferably, the same names used for the
definitions.
|
| |
|
| |
|
| |
|
| |
|
|
us to return proper PXE status codes, while simultaneously allowing for
more consistent error reporting (complete with verbose error messages as a
build-time option).
|