0

I can't compile this piece of assembler code under Mac OS using this:

.text
    .global _start
_start:
    . = _start + 510
    .byte 0x55
    .byte 0xaa
ld –Ttext 0x7c00 --oformat=binary test.o –o test.bin

instruction in a result terminal:

ld: file not found: –Ttext

Could you tell me why this doesn't work, but also if there is an alternative to this instruction to compile in the desired format. Thank you all in advance.

melpomene
  • 84,125
  • 8
  • 85
  • 148
sambia39
  • 35
  • 9
  • Are you using gnu ld or the one that comes with OSX? – ivo Sep 01 '17 at 15:36
  • I'm not sure, but on my machine I installed GNU and by default there was already Clang so I would bet on the GNU one, but apparently it doesn't work on Mac. `gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.1.0 (clang-802.0.42) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` – sambia39 Sep 01 '17 at 15:44
  • What does `ld -v` show? If I were you I'd compile it in a linux VM. It will save you a lot of time and grief. – ivo Sep 01 '17 at 15:55
  • This gives me the following result: `ld -v @(#)PROGRAM:ld PROJECT:ld64-278.4 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS) LTO support using: LLVM version 8.1.0, (clang-802.0.42) TAPI support using: Apple TAPI version 1.33.11` honestly I would still be dependent on VM I prefer to do it under Mac... but I would consider this option if there is no other choice. – sambia39 Sep 01 '17 at 16:01
  • OK I will test and I will give you the result if I encounter difficulties thank you – sambia39 Sep 01 '17 at 16:26
  • Maybe this is helpful https://stackoverflow.com/questions/25634708/gnu-linker-equivalent-command-in-os-x – ivo Sep 01 '17 at 16:44
  • Did you install gcc with homebrew? If so you should be able to use `/usr/local/i386elfgcc/bin/i386-elf-ld` with your original commandline args. – ivo Sep 01 '17 at 16:50
  • 1
    Thanks to you I was able to find an alternative solution thanks to your link `gobjcopy -j .text --set-start 0x7c00 -O binary source.o boot.bin` – sambia39 Sep 01 '17 at 19:09

2 Answers2

3

The first character in –Ttext is U+2013 (EN DASH).

You need to use - U+002D (HYPHEN-MINUS) instead.

melpomene
  • 84,125
  • 8
  • 85
  • 148
0

I found this relevant question GNU Linker equivalent command in OS X

and the OP did the heavy lifting to find the solution:

gobjcopy -j .text --set-start 0x7c00 -O binary source.o boot.bin

--

UPDATE: See comments below.

TLDR: Do not use the above. Instead, build (or acquire) a generic ELF binutils which will give you access to a version of LD that is based on GNU's tool chain. That version of LD supports proper linker scripts and is far more easy to do OS development with.

ivo
  • 1,103
  • 10
  • 13
  • This is a terrible idea. You will have serious problems since you are converting an unlinked `.o` (object) file to a binary. As the person points out that it causes problems for label offsets. the real solution is to acquire or build an i686 (or x86-64) binutils and GCC cross compiler – Michael Petch Sep 02 '17 at 02:19
  • @MichaelPetch OK I will delete this answer. But before I do, why would it require a cross compiler? – ivo Sep 02 '17 at 14:12
  • If you build (or acquire) a generic ELF binutils it will give you access to a version of _LD_ that is based on GNU's tool chain. That version of _LD_ supports proper linker scripts and is far more easy to do OS development with. The _LD_ available on OS/X is limited in comparison. – Michael Petch Sep 02 '17 at 14:16
  • All right, I'm trying to understand. Outside the link provided with the provided solution which according to your statements is not correct. A simple `nasm -f bin bootloader.asm -o boot.bin followed by a simple 'cat boot.bin /dev/zero | dd of=floppyA bs=512 count=2880 ` still allows you to get an **boot loader** The previous step was another approach to design **boot loader** so what do you propose as an alternative or suitable tool for building an operating system under Mac OS ? thanks – sambia39 Sep 02 '17 at 14:30