macOS Assembly Language Troubles :(

[Cresselia]

Hi so I have to write an asm program with some C embedded in it for my Assembly Language class and I just do not know how to do this on my MBP. so far I got my .s file to produce a .o file using the command
"as -o Lab_3.o Lab_3.s"
and when I try to execute the .o file it says
"Permission Denied".
I figured I had more in between steps so I try to build/link it (I don't know if there is a difference) using the commands
"ld -o Lab_3 Lab_3.s",
"ld -lcrt1.o -lSystem -o Lab_3 Lab_3.s",
"ld /Developer/usr/lib/libgmalloc.B.dylib -o Lab_3 Lab_3.s",
"ld /usr/lib/libgmalloc.B.dylib -o Lab_3 Lab_3.s".
They all produce the same error message
"ld: warning: -arch not specified
ld: warning: -macosx_version_min not specified, assuming 10.7
ld: warning: ignoring file Lab_3.s, file was built for unsupported file format ( 0x a 0x a 0x2e 0x73 0x65 0x63 0x74 0x69 0x6f 0x6e 0x20 0x2e 0x64 0x61 0x74 0x61 ) which is not the architecture being linked (x86_64): Lab_3.s
Undefined symbols for architecture x86_64:
"start", referenced from:
-u command line option
ld: symbol(s) not found for inferred architecture x86_64"

Please help me fix this. I have this due by Saturday morning and I am just so lost. Also if I need to link any libraries please explain to me how to do this in excruciating detail.

 

[ConCat]

Did you enable execute permissions?

chmod +x /path/to/executable

 

[ghellquist]

Hi so I have to write an asm program with some C embedded in it for my Assembly Language class ...

Hi!
I think you are in for quite a bit of work and investigations.

1) When you combine C and ASM you need to make sure that all conventions are fulfilled. This includes (but is not limited to) setting up all the necessary registers and initiating everything to the correct state before running any c code. The least difficult (not necessarily simple) is to have a c main program and calling assembly language subrutines from c. Calling c from asm has many more pitfalls. Beware that what register you can use, how parameters and return values are passed (registers or stack) and so on may differ between different systems.

2) The assembler and linker on Macintosh has quite a few extra parameters, and these are different from other platforms. You need to tell the assembler what architecture you are programming for, the -arch argument needs to have a value. This is all documented, try man as in a terminal window (and keep on scrolling). The linker also needs extra information specific to Mac OSX in order to create an executable image, examples include the -mac_osx_min_version which you need to give a value.

3) On the macintosh the starting point is start, not _start as in some other systems.

4) and yes, the file needs execute permissions, after all OSX is a Unix system, not the unsafe windows.

Hopefully this will help you getting started, it is not impossible, only a bit difficult.

// gunnar

 

[chown33]

Hi so I have to write an asm program with some C embedded in it for my Assembly Language class and I just do not know how to do this on my MBP. so far I got my .s file to produce a .o file using the command
"as -o Lab_3.o Lab_3.s"
and when I try to execute the .o file it says
"Permission Denied".

The problem with that command-line is the .o file isn't an executable. It's only a linkable object-file, which must still be processed by ld in order to become an actual executable.
http://en.wikipedia.org/wiki/Object_file

I figured I had more in between steps so I try to build/link it (I don't know if there is a difference) using the commands
"ld -o Lab_3 Lab_3.s",
"ld -lcrt1.o -lSystem -o Lab_3 Lab_3.s",
"ld /Developer/usr/lib/libgmalloc.B.dylib -o Lab_3 Lab_3.s",
"ld /usr/lib/libgmalloc.B.dylib -o Lab_3 Lab_3.s".
They all produce the same error message
"ld: warning: -arch not specified
ld: warning: -macosx_version_min not specified, assuming 10.7
ld: warning: ignoring file Lab_3.s, file was built for unsupported file format ( 0x a 0x a 0x2e 0x73 0x65 0x63 0x74 0x69 0x6f 0x6e 0x20 0x2e 0x64 0x61 0x74 0x61 ) which is not the architecture being linked (x86_64): Lab_3.s
Undefined symbols for architecture x86_64:
"start", referenced from:
-u command line option
ld: symbol(s) not found for inferred architecture x86_64"

Please explain how you came up with those commands. If it's from an example, please provide the exact URL of the example.

All those commands have the same problem: you're passing the Lab_3.s file instead of the Lab_3.o file. The linker is not an assembler, so when you tell it to use Lab_3.s, it interprets it as an object file, which it's not. Thus, 'ld' can't link a .s file, and it fails.

And as you've also discovered, the assembler does not run the linker.


You should probably learn to use make:
http://en.wikipedia.org/wiki/Make_(software)

To summarize, make is a program for building programs. It has a bunch of built-in rules, which it uses to transform one type of file (say .s) into another type of file (say .o), and it applies these rules until it runs out of transformations.

So just using its builtin rules, it transforms a .s into a .o by running the assembler, and then it transforms a .o into an executable by running the linker. Actually, it doesn't do any of those, instead 'make' lets the 'cc' command do it all.

Because make has builtin rules, if you run it without a makefile, it can still do a lot of the work automatically. So this command:

make Lab_3

would run make, which then runs 'cc' with correct arguments to build the executable from either .c files or .s files.

The make command also has an option that tells it "don't run any commands, but show me what would be run". This can be useful for seeing the correct command-line to use. That option is -n . Example:

make -n Lab_3

You can read the man page for make in Terminal, or in your web browser with the Bwana utility:
http://bruji.com/bwana/index.html

There are also numerous online references, as well as books.

 

[subsonix]

Just use gcc instead of as, that will give you an executable file directly. If your class is on 64 bit x86 assembler which I doubt.