Robert Spykerman <robert.spykerman@[EMAIL PROTECTED]
> wrote:
> On Apr 11, 2:33 am, Josh Grams <josh@[EMAIL PROTECTED]
> wrote:
>
>> I'm still not quite clear whether you're having trouble getting Apple's
>> toolchain to assemble and link a working lina binary, or if you need to
>> learn the internals of ELF/Mach-O so you can port SAVE-SYSTEM, or both.
>
> Both ultimately, I have managed to coax nasm and ld to produce a
> mach-o but whether it's true to form of Albert's original I am unsure.
I've looked at both and I think yours is reasonable...
> Albert sections his code very nicely into 2 user defined sections,
> forth and dictionary - dictionary being unitialized for further
> additions, with the exec flag on.
>
> This appears to build without a fuss on linux. On OSX, the tools give
> out big stink about there not being a .text, data,
That's BSD for you. You are required to have .text and .data, so you
might as well use them. The other thing you could do (which might save
a bit of space in the executable is to put everything in .text, have an
empty .data, and then immediately mprotect() everything to rwx. But
your way seems fine to me.
> So I cheated and created an empty .text. Put the initial start
> executable code / prebuilt dictionary in a .data - this is because I
> realized forth needs to write back to the dictonary.
>
> What is surprising is that it worked - there is executable code in the
> dictionary after all. The start: is in the .data section.....
I believe (someone please correct me if I'm wrong) that x86 processors
don't distinguish between readable and executable, so if you can read
it, you can execute it.
> So that bit was done but the unitialized space remained a problem.
> ... So I had a look at what was available by default and .bss looked
> possibly like my best option, tried it, and it seemed to assemble and
> link, and run.
..bss stands (I believe) for Blank Space Section. It's usually just a
shortcut for the longer form with the 'nobits' attribute written out and
all that.
> How to build custom sections I do not yet know for the mach-o tools.
> (or segments I still do not understand fully the difference - nasm
> documentation is currently confusing me - I thought they were the
> same).
Oh, that is confusing. nasm apparently has a SEGMENT directive which is
"an exactly equivalent synonym" for SECTION. So in the nasm docs they
*do* mean the same thing.
> Now this assembles to something reasonable and runs, but I don't
> completely understand what it's done to it's allotted virtual space of
> memory.
If you haven't looked at Apple's Mach-O File Format Reference, you
should; they have a nice little diagram.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
Also I'm appending a marked-up hex dump of the first bit of your binary
from CVS (xina-generic/forth) which may help. But look at Apple's
diagram first. Really. :)
Unfortunately for easy implementation of SAVE-SYSTEM, it looks like the
linker puts stuff at the end of the file, and I'm not sure if it's
important. Is that a stripped binary? If not, maybe you could e-mail
me one? If the stuff at the end isn't important, then you just need to
zero out a few header fields, set the new size, and write it to a file,
just like with ELF.
> And although it seems to work, I am not sure if there are any
> conditions that will break it. So far, I've not had the kernel
> complain about memory issues, ie bad writes but who knows.
There shouldn't be any problems as far as I know...
> It's also the case I am not fully aware on how to fully wield the
> tools. I think I have a rough idea of what should be done as above,
> but whether I am doing it the right way... ie You mention linker
> scripts, they seem pretty arcane at the moment
And BSDs pretty much require the standard layout, so there's probably no
reason to get into linker scripts.
> If you have a mac/OSX, take a look and see, given your experience and
> expertise you may be able to tell almost immediately what the best way
> should be.
Yeah, I don't have OSX, that's the problem. :) I'm just going from
documentation, and code that csourcesearch.net turns up.
--Josh
=======================================================================
0000000: cefa edfe # magic number
0000004: 0700 0000 # cpu type (CPU_TYPE_I386)
0000008: 0300 0000 # cpu subtype (CPU_SUBTYPE_I386_ALL)
000000c: 0200 0000 # file type (MH_EXECUTE)
0000010: 0800 0000 3c02 0000 # 8 load commands for a total of 0x23c bytes
0000018: 8500 0000 # MH_TWOLEVEL, MH_DYLDLINK, MH_NOUNDEFS; probably
normal for an executable.
000001c: 0100 0000 3800 0000 # load segment (command takes 0x38 bytes)
0000024: 5f5f 5041 4745 5a45 524f 0000 0000 0000 # __PAGEZERO
0000034: 0000 0000 0010 0000 # virtual address 0, length 4096 bytes
000003c: 0000 0000 0000 0000 # file offset/length 0/0.
0000044: 0000 0000 0000 0000 # no permissions (maximum or initial)
000004c: 0000 0000 0000 0000 # contains no sections, no flags set
0000054: 0100 0000 3800 0000 # load segment (command takes 0x38 bytes)
000005c: 5f5f 5445 5854 0000 0000 0000 0000 0000 # __TEXT
000006c: 0010 0000 0010 0000 # virtual address 0x00001000, length 0x1000
0000074: 0000 0000 0010 0000 # file offset 0, length 0x1000.
000007c: 0700 0000 0500 0000 # rwx max permissions, rx initial
permissions
0000084: 0000 0000 0000 0000 # contains no sections, no flags set
000008C: 0100 0000 c000 0000 # load segment (command takes 0xc0 bytes)
0000094: 5f5f 4441 5441 0000 0000 0000 0000 0000 # __DATA
00000a4: 0020 0000 0000 0004 # virtual address 0x00002000, length 64 MB
00000ac: 0010 0000 0070 0000 # file offset 0x1000, length 0x7000
00000b4: 0700 0000 0300 0000 # rwx max permissions, rw initial
permissions
00000bc: 0200 0000 0000 0000 # contains two sections, no flags set.
00000c4: 5f5f 6461 7461 0000 0000 0000 0000 0000 # section named __data
00000d4: 5f5f 4441 5441 0000 0000 0000 0000 0000 # in segment named
__DATA
00000e4: 0020 0000 b86e 0000 # at address 0x00002000, length 0x6eb8
00000ec: 0010 0000 0000 0000 # offset 0x1000 in file, no alignment
00000f4: 0000 0000 0000 0000 # no relocations (offset 0, count 0)
00000fc: 0000 0000 0000 0000 0000 0000 # no flags set
0000108: 5f5f 6273 7300 0000 0000 0000 0000 0000 # section named __bss
0000118: 5f5f 4441 5441 0000 0000 0000 0000 0000 # in segment named
__DATA
0000128: b88e 0000 d490 ff03 # at address 0x00008eb8, length 64 MB -
0x6eb8 - 0x74 (?)
0000130: 0000 0000 0000 0000 # file offset 0, no alignment
0000138: 0000 0000 0000 0000 # no relocations (offset 0, count 0)
0000140: 0100 0000 0000 0000 0000 0000 # zero fill on demand section
# command 4
000014c: 0100 0000 3800 0000 # load segment (command takes 0x38 bytes)
0000154: 5f5f 4c49 4e4b 4544 4954 0000 0000 0000 # __LINKEDIT
0000164: 0020 0004 0050 0000 # virtual address 0x04002000, length 0x5000
000016c: 0080 0000 5446 0000 # file offset 0x8000, length 0x4654
0000174: 0700 0000 0100 0000 # rwx max permissions, read-only initially.
000017c: 0000 0000 0000 0000 # contains no sections, no flags set
# command 5
0000184: 0200 0000 1800 0000 # symbol table (0x18 bytes)
000018c: 0080 0000 c303 0000 # offset 0x8000, 0x3c3 symbol entries
0000194: 24ad 0000 3019 0000 # string table offset 0xad24, 0x1930 bytes
# command 6
000019c: 0b00 0000 5000 0000 # dysymtab (0x50 bytes)
00001a4: 0000 0000 c103 0000 # 0x3c1 local symbols starting at symbol 0
00001ac: c103 0000 0200 0000 # 2 externally defined symbols starting at
symbol 0x3c1
00001b4: c303 0000 0000 0000 # 0 undefined symbols starting at symbol
0x3c3
00001bc: 0000 0000 0000 0000 # no table of contents
00001c4: 0000 0000 0000 0000 # no module table
00001cc: 0000 0000 0000 0000 # no externally referenced symbols
00001d4: 24ad 0000 0000 0000 # indirect symbol table (0 entries at offset
0xad24)
00001dc: 0000 0000 0000 0000 # no external relocations
00001e4: 0000 0000 0000 0000 # no local relocations
# command 7
00001ec: 0e00 0000 1c00 0000 # dynamic linker to use (0x1c bytes)
00001f4: 0c00 0000 # string at offset 0xc from start of this command
00001f8: 2f75 7372 2f6c 6962 2f64 796c 6400 0000 # "/usr/lib/dyld"
# command 8
0000208: 0500 0000 5000 0000 # unix thread (0x50 bytes)
0000210: 0100 0000 1000 0000 0000 0000 0000 0000 ................
0000220: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000230: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000240: 0020 0000 0000 0000 0000 0000 0000 0000 . ..............
0000250: 0000 0000 0000 0000
0000258: # end of load commands, pad __TEXT segment out to 4096 bytes
0001000: # start of __DATA segment (__data and __bss sections)
# other stuff at the end...bleh.
|
