tag:github.com,2008:https://github.com/uclinux-dev/elf2flt/releasesRelease notes from elf2flt2024-03-26T13:30:54Ztag:github.com,2008:Repository/48087712/v2024.052024-03-26T13:30:54Zv2024.05: fix alignment for new-style ctors when using riscv64<p>Recently uClibc-ng enabled UCLIBC_CTOR_DTOR for riscv64, so<br>
that f.e. C++ applications are running fine. As a side effect<br>
this breaks noMMU support. The problem is the alignment for<br>
the ctors in elf2flt. This patch fixes it.</p>
<p>Tested with Qemu for ARM, M68k and Xtensa with no regressions.</p>wbx-githubtag:github.com,2008:Repository/48087712/v2024.022023-12-22T01:19:59Zv2024.02: elf2flt: add RISC-V 32-bit support<p>Allow elf2flt to work with RISC-V 32-bit targets. With these changes, the<br>
uclibc toolchain and busybox can work fine for rv32 no MMU systems with<br>
no noticable problem.</p>
<p>Signed-off-by: Charles Lohr <a href="mailto:lohr85@gmail.com">lohr85@gmail.com</a><br>
[Rebased onto latest tree for upstreaming]<br>
Signed-off-by: Jesse Taube <a href="mailto:Mr.Bossman075@gmail.com">Mr.Bossman075@gmail.com</a><br>
[Add more ELF relco types and edit commit message]<br>
Signed-off-by: Yimin Gu <a href="mailto:ustcymgu@gmail.com">ustcymgu@gmail.com</a></p>regymmtag:github.com,2008:Repository/48087712/v2023.092023-09-12T00:09:49Zv2023.09: elf2flt.ld: reinstate 32 byte alignment for .data section<p>Commit <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/uclinux-dev/elf2flt/commit/8a3e74446fe7d866f0517ee089a37f4bdf4bc9f7/hovercard" href="https://github.com/uclinux-dev/elf2flt/commit/8a3e74446fe7d866f0517ee089a37f4bdf4bc9f7"><tt>8a3e744</tt></a> ("allow to build arm flat binaries") moved the<br>
following commands:<br>
. = ALIGN(0x20) ;<br>
@SYMBOL_PREFIX@_etext = . ;<br>
from the .text section to the top level in the SECTIONS node.</p>
<p>The .text output section is being directed to a memory region using the<br>
"> flatmem :text" output section attribute. Commands in the top level in<br>
the SECTIONS node are not.</p>
<p>This means that the ALIGN() command is no longer being appended to the<br>
flatmem memory region, it will simply update the Location Counter.</p>
<p>The heuristic for placing an output section is described here:<br>
<a href="https://sourceware.org/binutils/docs-2.38/ld.html#Output-Section-Address" rel="nofollow">https://sourceware.org/binutils/docs-2.38/ld.html#Output-Section-Address</a></p>
<p>"If an output memory region is set for the section then it is added to this<br>
region and its address will be the next free address in that region."</p>
<p>Since the .data section is being directed to the same memory region as the<br>
.text section, this means that the Location Counter is not used when<br>
assigning an address to the .data output section, it will simply use the<br>
next free address.</p>
<p>No longer directing these commands to the flatmem memory region means that<br>
the .data output section is no longer aligned to a 32 byte boundary.</p>
<p>Before commit <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/uclinux-dev/elf2flt/commit/8a3e74446fe7d866f0517ee089a37f4bdf4bc9f7/hovercard" href="https://github.com/uclinux-dev/elf2flt/commit/8a3e74446fe7d866f0517ee089a37f4bdf4bc9f7"><tt>8a3e744</tt></a> ("allow to build arm flat binaries"):<br>
$ readelf -S busybox_unstripped.gdb | grep data<br>
[ 3] .data PROGBITS 0000000000035ac0 00036ac0<br>
$ readelf -s busybox_unstripped.gdb | grep _etext<br>
19286: 0000000000035ac0 0 NOTYPE GLOBAL DEFAULT 1 _etext</p>
<p>After commit <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/uclinux-dev/elf2flt/commit/8a3e74446fe7d866f0517ee089a37f4bdf4bc9f7/hovercard" href="https://github.com/uclinux-dev/elf2flt/commit/8a3e74446fe7d866f0517ee089a37f4bdf4bc9f7"><tt>8a3e744</tt></a> ("allow to build arm flat binaries"):<br>
$ readelf -S busybox_unstripped.gdb | grep data<br>
[ 3] .data PROGBITS 0000000000035ab0 00036ab0<br>
$ readelf -s busybox_unstripped.gdb | grep _etext<br>
19287: 0000000000035ac0 0 NOTYPE GLOBAL DEFAULT 3 _etext</p>
<p>The .data output section has to be aligned to a 32 byte boundary, see the<br>
FLAT_DATA_ALIGN 0x20 macro and its usage in fs/binfmt_flat.c:<br>
<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/binfmt_flat.c?h=v5.17#n59" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/binfmt_flat.c?h=v5.17#n59</a></p>
<p>Readd an explicit ALIGN attribute on the .data section itself, since the<br>
linker will obey this attribute regardless if being directed to a memory<br>
region or not. Also remove the ALIGN() command before the .data section,<br>
since this misleads the reader to think that the Location Counter is used<br>
when assigning an address to the .data section, when it actually is not.</p>
<p>Signed-off-by: Niklas Cassel <a href="mailto:niklas.cassel@wdc.com">niklas.cassel@wdc.com</a></p>
<p>As Niklas points out this patch is no longer strictly necessary.</p>
<p>That being said, having the ALIGN attribute on the output of the data<br>
section declaration itself is safer, as it means that the output section<br>
will be aligned regardless if it is redirected or not.</p>
<p>Signed-off-by: Greg Ungerer <a href="mailto:gerg@kernel.org">gerg@kernel.org</a></p>floatioustag:github.com,2008:Repository/48087712/v2023.042023-04-25T12:49:22Zv2023.04: elf2flt: check for presence of libzstd<p>Binutils-2.40 introduced support for libzstd compressed bfd sections.<br>
By default binutils configure will check for and use the system libzstd<br>
library if it is present.</p>
<p>Now when compiling elf2flt using the bfd library from a<br>
binutils-2.40 and a system present libzstd you will get link errors:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="/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'"><pre class="notranslate"><code>/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'
</code></pre></div>
<p>Add a library check to the elf2flt configure for libzstd presence.<br>
When present link using it.</p>
<p>There is no real problem when linking with -lzstd if compiling with<br>
bfd libraries from older binutils, it just won't be needed. So there<br>
is no need to make this check selective on binutils version.</p>
<p>Signed-off-by: Greg Ungerer <a href="mailto:gerg@kernel.org">gerg@kernel.org</a></p>vapiertag:github.com,2008:Repository/48087712/v2021.082021-08-20T07:21:32Zv2021.08: elf2flt.ld: add more documentation<p>Help out people who like to dive into the source directly.</p>
<p>Signed-off-by: Mike Frysinger <a href="mailto:vapier@gentoo.org">vapier@gentoo.org</a></p>vapiertag:github.com,2008:Repository/48087712/v2020.092020-09-09T09:22:41Zv2020.09: configure: deprecate --disable-ld-elf2flt-binary<p>We've been defaulting to the compiled linker for years now and no one<br>
has complained. Lets deprecate the old shell script so we don't have<br>
to maintain two large tools doing the same thing.</p>
<p>Signed-off-by: Mike Frysinger <a href="mailto:vapier@gentoo.org">vapier@gentoo.org</a></p>vapiertag:github.com,2008:Repository/48087712/v2019.122019-12-29T14:12:08Zv2019.12: elf2flt.c: add support for SOURCE_DATE_EPOCH<p>The bFLT header has a "build_date" field which contains the date/time<br>
at which the bFLT file was created. Unfortunately, this breaks<br>
reproducible builds as two identical builds done at different times<br>
will produce different results.</p>
<p>For example, on a bFLT binary, diffoscope reports the following<br>
change:</p>
<p>00000000: 6246 4c54 0000 0004 0000 0045 0001 48d4 bFLT.......E..H.<br>
00000010: 0002 85a0 0002 fe50 0000 1000 0002 85a0 .......P........<br>
-00000020: 0000 0757 0000 0001 5e05 742e 0000 0000 ...W....^.t.....<br>
+00000020: 0000 0757 0000 0001 5e05 a5c2 0000 0000 ...W....^.......</p>
<p>In order to address this, this commit adds support for the<br>
SOURCE_DATE_EPOCH environment variable, which is standardized by the<br>
reproducible-builds.org group at<br>
<a href="https://reproducible-builds.org/specs/source-date-epoch/" rel="nofollow">https://reproducible-builds.org/specs/source-date-epoch/</a>.</p>
<p>We simply use the time from the SOURCE_DATE_EPOCH variable (which<br>
contains the number of seconds since Epoch) when SOURCE_DATE_EPOCH is<br>
available in the environment, and otherwise fallback to the existing<br>
logic that takes the current time using time().</p>
<p>Signed-off-by: Thomas Petazzoni <a href="mailto:thomas.petazzoni@bootlin.com">thomas.petazzoni@bootlin.com</a></p>tpetazzonitag:github.com,2008:Repository/48087712/v2017.122017-03-20T04:04:18Zv2017.12: Merge pull request #7 from stilor/fix-cygwin-build-2<p>Fix cygwin and macos builds</p>vapiertag:github.com,2008:Repository/48087712/v2016.122016-12-12T05:35:04Zv2016.12: elf2flt: fix unused warning for e1/bfin targets<p>The one call site for this func is inside of an e1/bfin ifdef check,<br>
so add the same logic to the definition to fix a build error:<br>
elf2flt.c:212:1: error: ‘get_symbol_offset’ defined but not used [-Werror=unused-function]</p>
<p>Signed-off-by: Mike Frysinger <a href="mailto:vapier@gentoo.org">vapier@gentoo.org</a></p>vapier