fix alignment for new-style ctors when using riscv64

Recently uClibc-ng enabled UCLIBC_CTOR_DTOR for riscv64, so
that f.e. C++ applications are running fine. As a side effect
this breaks noMMU support. The problem is the alignment for
the ctors in elf2flt. This patch fixes it.

Tested with Qemu for ARM, M68k and Xtensa with no regressions.

elf2flt: add RISC-V 32-bit support

Allow elf2flt to work with RISC-V 32-bit targets. With these changes, the
uclibc toolchain and busybox can work fine for rv32 no MMU systems with
no noticable problem.

Signed-off-by: Charles Lohr <lohr85@gmail.com>
[Rebased onto latest tree for upstreaming]
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
[Add more ELF relco types and edit commit message]
Signed-off-by: Yimin Gu <ustcymgu@gmail.com>

elf2flt.ld: reinstate 32 byte alignment for .data section

Commit 8a3e744 ("allow to build arm flat binaries") moved the
following commands:
	. = ALIGN(0x20) ;
	@SYMBOL_PREFIX@_etext = . ;
from the .text section to the top level in the SECTIONS node.

The .text output section is being directed to a memory region using the
"> flatmem :text" output section attribute. Commands in the top level in
the SECTIONS node are not.

This means that the ALIGN() command is no longer being appended to the
flatmem memory region, it will simply update the Location Counter.

The heuristic for placing an output section is described here:
https://sourceware.org/binutils/docs-2.38/ld.html#Output-Section-Address

"If an output memory region is set for the section then it is added to this
region and its address will be the next free address in that region."

Since the .data section is being directed to the same memory region as the
.text section, this means that the Location Counter is not used when
assigning an address to the .data output section, it will simply use the
next free address.

No longer directing these commands to the flatmem memory region means that
the .data output section is no longer aligned to a 32 byte boundary.

Before commit 8a3e744 ("allow to build arm flat binaries"):
$ readelf -S busybox_unstripped.gdb | grep data
  [ 3] .data             PROGBITS         0000000000035ac0  00036ac0
$ readelf -s busybox_unstripped.gdb | grep _etext
 19286: 0000000000035ac0     0 NOTYPE  GLOBAL DEFAULT    1 _etext

After commit 8a3e744 ("allow to build arm flat binaries"):
$ readelf -S busybox_unstripped.gdb | grep data
  [ 3] .data             PROGBITS         0000000000035ab0  00036ab0
$ readelf -s busybox_unstripped.gdb | grep _etext
 19287: 0000000000035ac0     0 NOTYPE  GLOBAL DEFAULT    3 _etext

The .data output section has to be aligned to a 32 byte boundary, see the
FLAT_DATA_ALIGN 0x20 macro and its usage in fs/binfmt_flat.c:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/binfmt_flat.c?h=v5.17#n59

Readd an explicit ALIGN attribute on the .data section itself, since the
linker will obey this attribute regardless if being directed to a memory
region or not. Also remove the ALIGN() command before the .data section,
since this misleads the reader to think that the Location Counter is used
when assigning an address to the .data section, when it actually is not.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>

As Niklas points out this patch is no longer strictly necessary.

That being said, having the ALIGN attribute on the output of the data
section declaration itself is safer, as it means that the output section
will be aligned regardless if it is redirected or not.

Signed-off-by: Greg Ungerer <gerg@kernel.org>

elf2flt: check for presence of libzstd

Binutils-2.40 introduced support for libzstd compressed bfd sections.
By default binutils configure will check for and use the system libzstd
library if it is present.

Now when compiling elf2flt using the bfd library from a
binutils-2.40 and a system present libzstd you will get link errors:

    /usr/bin/ld: ..//binutils-2.40/bfd/libbfd.a(compress.o): in function `decompress_contents':
    ../binutils-2.40/bfd/compress.c:517: undefined reference to `ZSTD_decompress'
    /usr/bin/ld: ../binutils-2.40/bfd/compress.c:519: undefined reference to `ZSTD_isError'
    /usr/bin/ld: ../binutils-2.40/bfd/libbfd.a(compress.o): in function `bfd_compress_section_contents':
    ../binutils-2.40/bfd/compress.c:656: undefined reference to `ZSTD_compress'
    /usr/bin/ld: ../binutils-2.40/bfd/compress.c:661: undefined reference to `ZSTD_isError'

Add a library check to the elf2flt configure for libzstd presence.
When present link using it.

There is no real problem when linking with -lzstd if compiling with
bfd libraries from older binutils, it just won't be needed. So there
is no need to make this check selective on binutils version.

Signed-off-by: Greg Ungerer <gerg@kernel.org>

elf2flt.ld: add more documentation

Help out people who like to dive into the source directly.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

configure: deprecate --disable-ld-elf2flt-binary

We've been defaulting to the compiled linker for years now and no one
has complained.  Lets deprecate the old shell script so we don't have
to maintain two large tools doing the same thing.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

elf2flt.c: add support for SOURCE_DATE_EPOCH

The bFLT header has a "build_date" field which contains the date/time
at which the bFLT file was created. Unfortunately, this breaks
reproducible builds as two identical builds done at different times
will produce different results.

For example, on a bFLT binary, diffoscope reports the following
change:

  00000000: 6246 4c54 0000 0004 0000 0045 0001 48d4  bFLT.......E..H.
  00000010: 0002 85a0 0002 fe50 0000 1000 0002 85a0  .......P........
 -00000020: 0000 0757 0000 0001 5e05 742e 0000 0000  ...W....^.t.....
 +00000020: 0000 0757 0000 0001 5e05 a5c2 0000 0000  ...W....^.......

In order to address this, this commit adds support for the
SOURCE_DATE_EPOCH environment variable, which is standardized by the
reproducible-builds.org group at
https://reproducible-builds.org/specs/source-date-epoch/.

We simply use the time from the SOURCE_DATE_EPOCH variable (which
contains the number of seconds since Epoch) when SOURCE_DATE_EPOCH is
available in the environment, and otherwise fallback to the existing
logic that takes the current time using time().

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

Merge pull request #7 from stilor/fix-cygwin-build-2

Fix cygwin and macos builds

elf2flt: fix unused warning for e1/bfin targets

The one call site for this func is inside of an e1/bfin ifdef check,
so add the same logic to the definition to fix a build error:
elf2flt.c:212:1: error: ‘get_symbol_offset’ defined but not used [-Werror=unused-function]

Signed-off-by: Mike Frysinger <vapier@gentoo.org>