| Summary: | Please enable AS and LD in configure.ac for OS X | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Jeffrey Walton <noloader> |
| Component: | admin | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | gingold, noloader |
| Priority: | P2 | ||
| Version: | 2.26 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
as and ld haven't been ported to mac os x (as native tools). Not sure wether it is worth given there are already open source (but non-free) tools. (In reply to gingold@adacore.com from comment #1) > as and ld haven't been ported to mac os x (as native tools). > Not sure wether it is worth given there are already open source (but > non-free) tools. I believe AS is a required tool in the suite because of the way inline assembly is handled by the compiler. LD is probably going to be a stretch (but I'm only guessing). To ensure I'm not missing something obvious, what other non-free tools did you have in mind, and how would they be used? Is it a non-free compiler that can consume the inline assembly? Or is it a different assembler that GCC can use when processing the inline assembly? > On 27 Sep 2015, at 00:54, noloader at gmail dot com <sourceware-bugzilla@sourceware.org> wrote: > > https://sourceware.org/bugzilla/show_bug.cgi?id=18997 > > --- Comment #2 from Jeffrey Walton <noloader at gmail dot com> --- > (In reply to gingold@adacore.com from comment #1) >> as and ld haven't been ported to mac os x (as native tools). >> Not sure wether it is worth given there are already open source (but >> non-free) tools. > > I believe AS is a required tool in the suite because of the way inline assembly > is handled by the compiler. LD is probably going to be a stretch (but I'm only > guessing). Ok, I think you are asking for the support of .intel_syntax. > > To ensure I'm not missing something obvious, what other non-free tools did you > have in mind, and how would they be used? Is it a non-free compiler that can > consume the inline assembly? Or is it a different assembler that GCC can use > when processing the inline assembly? The sources of apple assembler, based on a very old version of gas are available from opensource.apple.com. But it is deprecated. Xcode is now based on clang, which has its own assembler. Likewise for the linker. |
According to a checkout of the latest binutil sources from Git: $ grep -n "noconfigdirs" configure.ac | grep "ld gas" 1015: noconfigdirs="$noconfigdirs ld gas gdb gprof" 1023: noconfigdirs="$noconfigdirs ld gas gprof" 1027: noconfigdirs="$noconfigdirs ld gas gdb gprof" 1245: noconfigdirs="$noconfigdirs ld gas gprof target-libgloss" 1251: noconfigdirs="$noconfigdirs ld gas gprof" And from the cluster at 1015/1023/1027: i[[3456789]]86-*-darwin*) noconfigdirs="$noconfigdirs ld gprof" noconfigdirs="$noconfigdirs sim target-rda" ;; x86_64-*-darwin[[912]]*) noconfigdirs="$noconfigdirs ld gas gprof" noconfigdirs="$noconfigdirs sim target-rda" ;; *-*-darwin*) noconfigdirs="$noconfigdirs ld gas gdb gprof" noconfigdirs="$noconfigdirs sim target-rda" ;; From above, notice GAS is enabled for i386|i686, but not x86_64. Downstream providers, like Macports, do not provide them stating its an upstream problem. Confer, "Where is AS located after Binutils is installed?", https://lists.macosforge.org/pipermail/macports-users/2015-April/038397.html. I would like to ask that Binutils provide both LD and AS for OS X. Enabling LD and AS will benefit users, and get downstream providers like Macports involved in enhancing the utilities. *********** Here's some related information. Our project provides both C/C++ code and alternate inline assembly (both one-liners and blocks). The ASM code is never used on OS X because of OS X's down-level assembler, even when contemporary gear (like a modern GCC via Macports) is available. Clang is not always an alternative for OS X. For example, Clang and its integrated assembler cannot consume some basic ASM statements, like a negate. Confer, https://llvm.org/bugs/show_bug.cgi?id=24232. GCC manages to work around many|most issues with Apple platforms. For example, init_priorty is not available on OS X. GCC chooses to make init_priorty an compiler error rather than not providing the compiler on OS X.