Re: 64-bit problem on Mac
Hi Alex, Hi Jon, I now re-did everything from scratch, in a new clean ongoing test, and I think the results are now more what you had expected. The error messages were now just this: sed: 1: x86-64.darwin.base.s: extra characters at the end of x command Ah, OK, this makes sense. It seems that 'sed' behaves differently, depending on the system. The -i option (in-place editing) may take an argument for the extension. In GNU this is optional, but I suspect it is mandatory on the Mac. Please try sed -i'' 's/@plt//' x86-64.darwin.base.s (an empty argument immediately after the 'i') or some variations of it. In any case, the final result should be that the @plt items are deleted, similar to the examples I gave here on my system). Here on my system, line 1957 of x86-64.darwin.base.s changed 1957c1957 call allocC_A@plt --- call allocC_A 1970c1970 call getpid@plt --- call getpid Cheers, - Alex Using sed -i'' 's/@plt//' x86-64.darwin.base.s did not delete the @plt items on my (brand new) iMac. The sed command is (like a few others OSX commands) slightly vintage; the man page says May 10, 2005. If you like, you can have a look at the man page here: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/sed.1.html The 'make' ended the same way as last time: sed: 1: x86-64.darwin.base.s: extra characters at the end of x command Sorry ... /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Jon, Using sed -i'' 's/@plt//' x86-64.darwin.base.s did not delete the @plt Hmm, so let's give up inplace-editing with 'sed'. We can use three commands instead: Move the '*.s' file to some temporary file, and then 'sed' to remove the '@plt's: mv x86-64.darwin.base.s x86-64.darwin.base.tmp sed 's/@plt//' x86-64.darwin.base.tmp x86-64.darwin.base.s rm x86-64.darwin.base.tmp Tough life on a Mac ... I'm afraid the _real_ tough stuff is still to come ;-) Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Jon, I now re-did everything from scratch, in a new clean ongoing test, and I think the results are now more what you had expected. The error messages were now just this: sed: 1: x86-64.darwin.base.s: extra characters at the end of x command Ah, OK, this makes sense. It seems that 'sed' behaves differently, depending on the system. The -i option (in-place editing) may take an argument for the extension. In GNU this is optional, but I suspect it is mandatory on the Mac. Please try sed -i'' 's/@plt//' x86-64.darwin.base.s (an empty argument immediately after the 'i') or some variations of it. In any case, the final result should be that the @plt items are deleted, similar to the examples I gave here on my system). Here on my system, line 1957 of x86-64.darwin.base.s changed 1957c1957 call allocC_A@plt --- call allocC_A 1970c1970 call getpid@plt --- call getpid Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Jon, and send me the resulting main.s? ... See attached file. Thanks! Looking at it, it seems a long way to go ... Besides the @plt issue, there are other differences. For example, symbol names are prefixed with an additional underscore. But let's start with the first step, removing the @plt stuff. Last time you inserted these three clauses into src64/Makefile: x86-64.darwin.base.s: lib/asm.l arch/x86-64.l $(baseFiles) sys/x86-64.darwin.code.l ./mkAsm x86-64 darwin Darwin base $(lib)/tags -fpic $(baseFiles) sys/x86-64.darwin.code.l x86-64.darwin.ext.s: lib/asm.l arch/x86-64.l ext.l ./mkAsm x86-64 darwin Darwin ext -fpic ext.l x86-64.darwin.ht.s: lib/asm.l arch/x86-64.l ht.l ./mkAsm x86-64 darwin Darwin ht -fpic ht.l Please change them, by appending 'sed' calls: x86-64.darwin.base.s: lib/asm.l arch/x86-64.l $(baseFiles) sys/x86-64.darwin.code.l ./mkAsm x86-64 darwin Darwin base $(lib)/tags -fpic $(baseFiles) sys/x86-64.darwin.code.l sed -i 's/@plt//' x86-64.darwin.base.s x86-64.darwin.ext.s: lib/asm.l arch/x86-64.l ext.l ./mkAsm x86-64 darwin Darwin ext -fpic ext.l sed -i 's/@plt//' x86-64.darwin.ext.s x86-64.darwin.ht.s: lib/asm.l arch/x86-64.l ht.l ./mkAsm x86-64 darwin Darwin ht -fpic ht.l sed -i 's/@plt//' x86-64.darwin.ht.s Then let's see what errors we get ;-) Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Jon, Sorry for the delay, but here are the errors I got after I appended the 'sed' calls (see attachted file). I'm not shure if there's a big difference, but you may spot something ... Indeed. No difference at all ... x86-64.darwin.base.s:1957:junk `@plt' after expression x86-64.darwin.base.s:1988:junk `@plt' after expression ... This should not be. The 'sed' command removes the '@plt' stuff (at least here on my system). Here on my system, line 1957 of x86-64.darwin.base.s changed 1957c1957 call allocC_A@plt --- call allocC_A 1970c1970 call getpid@plt --- call getpid ... But if 'sed' didn't work, there should be some other error message. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Jon, I've now got an answer to my question at http://stackoverflow.com/questions/6384961/osx-gnu-assembler-problem-with-call-fooplt Nice. Matthew Slattery says: .. 1. PLT is an ELF concept, but OS X uses a completely different object / executable file format - Mach-O. 2. Apple's |as| appears to be derived from a fork of a much earlier version of the GNU assembler, and, in some places, the syntax .. It looks like there has been some work on i386 and x86-64 Mach-O support quite recently in binutils That's good to hear! investigating the most recent version (2.21). But if the generated assembly code is trying to do clever things which are ELF-specific, you're probably going to have some major problems anyway... I'm not sure if this is the case. That '@plt' stuff surely has to do with the way code relocation is handled in ELF. So it might not be helpful here. But, again, I'm not sure, it might be worth to try it. Perhaps we should better investigate the Mach-O format? With that I mean not actually analyzing the format, but the ways to generate it. What helps in such cases is usually writing code snippets in C, compile them to assembly code (the -S option to gcc), and study that. Then we might be able to write a different code-generator for Mac OS, or (perhaps. better) a post-processor. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Alex, Hi Jon, What helps in such cases is usually writing code snippets in C, compile them to assembly code (the -S option to gcc), and study that. .. I think this sounds like something to try. Do you have any suggestions for code snippets in C that can be useful? OK. Perhaps the most reasonable is to start with the corresponding C-sources. Can you do something like $ gcc -S -m64 src/main.c and send me the resulting main.s? Cheers, - Alex See attached file. /Jon main.s.tgz Description: GNU Zip compressed data
64-bit problem on Mac
Hi, I wanted to look at the old problem of building 64-bit PicoLisp on Mac OS X. Assemblers are far from what I usually play with, but at least I'd like to spend a few hours today on this problem. From what I've found on the net, I got the impression that the standard (?) assembler on OSX is nasm, and that the nasm versions found on Macs are often quite old (just do nasm -v, and you'll see). My idea then was that it might help to install an up-to-date version. Then I wanted to check which version I had on my Ubuntu, where I build 64-bit PicoLisp without problem, but on my Ubuntu I found no nasm; here as (2.20.1) seems to be the standard assembler. On Mac (OSX 10.6.7) even as is not very new, I found 1.38. Maybe I should try to upgrade as instead of nasm ... Any comments? /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
I thougt PicoLisp used its' own assembler? On Thu, Jun 16, 2011 at 11:24:05AM +0200, Jon Kleiser wrote: Hi, I wanted to look at the old problem of building 64-bit PicoLisp on Mac OS X. Assemblers are far from what I usually play with, but at least I'd like to spend a few hours today on this problem. From what I've found on the net, I got the impression that the standard (?) assembler on OSX is nasm, and that the nasm versions found on Macs are often quite old (just do nasm -v, and you'll see). My idea then was that it might help to install an up-to-date version. Then I wanted to check which version I had on my Ubuntu, where I build 64-bit PicoLisp without problem, but on my Ubuntu I found no nasm; here as (2.20.1) seems to be the standard assembler. On Mac (OSX 10.6.7) even as is not very new, I found 1.38. Maybe I should try to upgrade as instead of nasm ... Any comments? /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Alex, Hi Jon, I wanted to look at the old problem of building 64-bit PicoLisp on Mac OS Great! :) .. I hope this gives you some hints to get started. We can try to tackle this together once we find out what exactly goes wrong. Cheers, - Alex It's probably best to continue this on IRC. I have some other business for about one hour. I'll log in when I'm ready. /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Jon, It's probably best to continue this on IRC. I have some other business for about one hour. I'll log in when I'm ready. OK, fine. See you! Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
Hi Jakob, I thougt PicoLisp used its' own assembler? Well, yes and no. The assembly language PicoLisp is written in, is its' own. It is described in http://software-lab.de/doc64/asm; (language and virtual CPU architecture). The build procedure (triggered by the script src64/mkAsm) translates the sources in that assembly language to GNU's assembly language. The GNU 'as' in turn is very portable. This still implies, however, that for a new architecture some porting effort is necessary. Architecture dependent files must be written, residing in the src64/arch/ and src64/sys/ directories. In case of MacOS, we can use the existing src64/arch/x86-64.l, though. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: 64-bit problem on Mac
On Thu, Jun 16, 2011 at 12:02:23PM +0200, Alexander Burger wrote: As far as I remember, the only remaining problem was not that of the assembler, but of the linker, or, more correctly, the final output file format. The last time we discussed it here was: http://www.mail-archive.com/picolisp@software-lab.de/msg01522.html -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
