[PATCH] D85086: [ELF] --oformat=binary: use LMA to compute file offsets

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 3 09:02:41 PDT 2020


MaskRay added a comment.

In D85086#2190130 <https://reviews.llvm.org/D85086#2190130>, @grimar wrote:

> There is a GNU ld bug about `--oformat=binary` "Linking with --oformat=binary discards non-static global variables" (https://sourceware.org/bugzilla/show_bug.cgi?id=12524).
> The last 2 comments are saying:
>
> 1. //"ld --oformat is a misfeature.  Don't use it.  As you have found, it doesn't work except for the simplest of object files, and only then on a very limited set of targets.  You are much better off linking to your usual target, then converting the file with objcopy.",//
> 2. //"I only added support for --oformat=binary to gold because the Linux kernel build uses it.".//
>
> So I am not sure that we want to add more complication for the existent logic of `--oformat binary` implemented in LLD?

I think the complexity is acceptable: 7 lines of code + 2 lines of comments + 1 blank line. For a misfeature, we either not implement it, approximate it, or fully implement it, but should not leave it in a known broken state if a reasonable fix is available. For this case I consider we have a perfect emulation. We cannot simply drop the feature because there are still use cases (in latest Linux kernel it appears to only exist in documentation; in FreeBSD it is still used).

I also question Alan's conclusion that "--oformat=binary is a misfeature". We can say it is redundant, because "objcopy -O binary" performs the task, but I can't find evidence that this feature was misdesigned.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85086/new/

https://reviews.llvm.org/D85086



More information about the llvm-commits mailing list