Clean up size symbols

Tells ld to define them after their markers

Signed-off-by: Callum Farmer <gmbr3@opensuse.org>

Merge /u/gmbr3/gnu-efi/ branch ia32 into master

https://sourceforge.net/p/gnu-efi/code/merge-requests/51/

Align all ctors/dtors start to 16

Signed-off-by: Callum Farmer <gmbr3@opensuse.org>

Copy marker names from binutils for init/fini

Signed-off-by: Callum Farmer <gmbr3@opensuse.org>

lds: Support ctors/dtors with a priority

Signed-off-by: Callum Farmer <gmbr3@opensuse.org>

Merge ctors/dtors rela sections

Signed-off-by: Callum Farmer <gmbr3@opensuse.org>

Make ELF constructors and destructors work

This makes setup and teardown functions defined with
__attribute__((__constructor__) and __attribute__((__destructor__)) work
in normal circumstances in EF

Make ELF constructors and destructors work

This makes setup and teardown functions defined with
__attribute__((__constructor__) and __attribute__((__destructor__)) work
in normal circumstances in EFI binaries.

A couple of notes:
- it implements both the old-style .ctors/.dtors methods and the newer
style .init_array/.fini_array ELF constructor and destructor arrays,
processed in the order:
.init_array[]
.ctors[]
efi_main()
.dtors[]
.fini_array[]
- Destructors will only be called if efi_main() exits using "return";
any call to Exit() will still longjmp() past them.
- InitializeLib() has already been called before constructors run, so
they don't need to call it (and neither does anything else.) For
compatibility, it has been altered so calling it more than once is
safe.
- No attempt is made to handle any constructor or destructor with a
prototype other than "void func(void);", but note that InitializeLib
has been called, so LibImageHandle, ST, BS, and RT are set.
- The init_array/ctor/dtor/fini_array lists aren't the using the GNU
"CONSTRUCTOR" output section command, so they don't start with a size.
- The lists are individually sorted during the link stage via
SORT_BY_NAME() in the linker script.
- The default (empty) init_array/ctor/dtor/fini_array lists are padded
out to 8-byte alignment with ".p2align 3, 0", and each list always has
at least one ".long 0" at the end of it (even if it's completely
empty). As a result, they can have NULLs that need to be skipped.
The sections they're in are mergeable, so the NULLs don't have to be
exclusively at the end.
- The ia64 and mips64el arches have not been tested.

Signed-off-by: Peter Jones <pjones@redhat.com>

show more ...

gnuefi: preserve .gnu.hash sections (unbreaks elilo on IA-64)

Gentoo has slightly modified linker defaults: --hash-style=gnu
This means all ELF files in system have '.gnu.hash' section
but no '.hash

gnuefi: preserve .gnu.hash sections (unbreaks elilo on IA-64)

Gentoo has slightly modified linker defaults: --hash-style=gnu
This means all ELF files in system have '.gnu.hash' section
but no '.hash' section.

gnuefi's ldscript did not account for it and as a result
one symbol 'ImageBase' did not resolve locally for elilo.so
and caused 'elilo' to fail to load by ia64 EFI:
Loading.: Gentoo (try new elilo)
ImageAddress: pointer is outside of image
ImageAddress: pointer is outside of image

Those two relocations come from crt0-efi-ia64.S PE32 entry point
fdescr:

```
#define IMAGE_REL_BASED_DIR64<->10
.section .reloc, "a"
data4 _start_plabel // Page RVA
data4 12 // Block Size (2*4+2*2)
data2 (IMAGE_REL_BASED_DIR64<<12) + 0 // reloc for plabel's entry point
data2 (IMAGE_REL_BASED_DIR64<<12) + 8 // reloc for plabel's global pointer
```

These refer ImageBase.

The change adds '.gnu.hash' collection (follows existing '.hash'
collection).

Tested on IA-64 by successfully booting elilo-3.16.

Bug: https://bugs.gentoo.org/575300
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

show more ...

Apparently some linkers will just throw caution to the wind and
decide to stick stuff we don't explicitly mention at 0,
no matter what else has already explicitly been located there.
A debian/ubuntu

Apparently some linkers will just throw caution to the wind and
decide to stick stuff we don't explicitly mention at 0,
no matter what else has already explicitly been located there.
A debian/ubuntu builder noted:

gcc -O0 -g3 -fpic -Wall -fshort-wchar -fno-strict-aliasing \
-fno-merge-constants -ffreestanding -fno-stack-protector \
-fno-stack-check --std=c11 -DCONFIG_aarch64 -D__KERNEL__ \
-I/usr/include/efi/ -I/usr/include/efi/aarch64/ \
-iquote/«PKGBUILDDIR»/include "-DDEBUGDIR=L\"/\"" \
-ffreestanding -I/usr/lib/gcc/aarch64-linux-gnu/4.9/include \
-c -o fakeesrt2.o fakeesrt2.c
ld -nostdlib --warn-common --no-undefined --fatal-warnings -shared \
-Bsymbolic -L/usr/lib -L/usr/lib --build-id=sha1 \
/usr/lib/crt0-efi-aarch64.o --defsym=EFI_SUBSYSTEM=0xa \
-o fakeesrt2.so fakeesrt2.o -lefi -lgnuefi \
/usr/lib/gcc/aarch64-linux-gnu/4.9/libgcc.a \
-T elf_aarch64_efi.lds
ld: section .note.gnu.build-id loaded at [00000000,00000023] overlaps section .text loaded at [00000000,0000668f]

This shouldn't be a problem if we explicitly tell it where to put them.

Ard added a patch to do this on Arm and aarch64 targets in 16409cad4cb,
but it needs to be everywhere.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...

This patch makes the following symbols (relatively) consistent between
all of our linker scripts:

_text
_etext
_text_size
_data
_edata
_data_size

There are various things that are slightly differen

This patch makes the following symbols (relatively) consistent between
all of our linker scripts:

_text
_etext
_text_size
_data
_edata
_data_size

There are various things that are slightly different (positions of
.rela*, .dynamic, and similar in relation to .data), but _text and _data
are now always at the beginning of their respective sections with regard
to how a debuger would reference the debug info, and _etext and _edata
are now always extant and guaranteed to be after any of the respective
kind of data the debugger would look for in that section.

This also adds an application example of how it might be used, and a
makefile target for %.efi.debug which will generate a separate debuginfo
file for that example.

This also enables debugging by default (i.e. -g is in CFLAGS) and adds
.note.gnu.build-id sections to our .so files (i.e. --build-id=sha1 is in
LDFLAGS).

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hp.com>

show more ...

The gnu-efi-3.0 toplevel subdirectory is really annoying. Kill it.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hp.com>