[plt-scheme] Re: oracle driver for PLT?
Hi Noel, hi Thomas,
thanks for the great help! I will certainly have a look at the reverse
engineered protocol because that's fascinating (also I didn't know
wireshark, sounds very interesting to try out!), but binding to the C
library will surely be the simpler way then...
And thank you too for the concrete explanations regarding the 32 v. 64
bit issue!
Interestingly, file doesn't give such a detailed output on my Mac, and
as I'm taking off this week I cannot check on Ubuntu at my workplace
(I have been using file there and the output was also quite short, but
I think I will mostly have used it for non-executables there, e.g. to
find out whether something's a symlink or not, so I don't know).
On my Mac I have e.g.
$ file '/usr/bin/file'
/usr/bin/file: Mach-O universal binary with 2 architectures
/usr/bin/file (for architecture i386): Mach-O executable i386
/usr/bin/file (for architecture ppc7400): Mach-O executable ppc
Regarding objdump, this I do not have in Leopard, but I found out that
the Mac equivalent is otool, and from a blog post (http://paulbeachsblog.blogspot.com/2007/12/32bit-or-64bit-binaries-on-macos.html
) I found how to use it:
$ otool -h /usr/bin/file
/usr/bin/file:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedface 7 3 0x00 2 14 1296
0x00000085
And in usr/include/mach-o/loader.h I have:
/* Constant for the magic field of the mach_header (32-bit
architectures) */
#define MH_MAGIC 0xfeedface /* the mach magic number */
Ciao,
Sigrid
Am 23.09.2009 um 10:45 schrieb Noel Welsh:
> On Wed, Sep 23, 2009 at 9:21 AM, Sigrid <keydana at gmx.de> wrote:
>> As for the network vs. FFI approach, I was searching the Oracle
>> documentation for it and it seems to me that the network approach is
>> impossible, as it uses a proprietary network protocol (called TTC)
>> from Oracle.
>
> AFAIK, you're largely correct but some people have reverse engineered
> the protocol:
>
> http://www.oracle-internals.com/?p=22
>
> Probably simpler to just bind the C library.
>
>> may I ask a very stupid question: I don't really know how to find out
>> whether a library uses 32bit or 64bit (even I don't know, is this a
>> feature of a single library, or of the system)?
>
> Both :) The OS generally has to support 64-bit (like Snow Leopard) but
> then individual libraries may be 64-bit or 32-bit (if the OS supports
> this kind of "mixed mode" code, which Snow Leopard does).
>
>> Could you tell me how
>> to find out such things on a Mac? (For this, as the concept itself is
>> not too clear for me I would not even know how to find out on Linux,
>> but I must admit that even if I know something on Linux I sometimes
>> have problems when things are different on the Mac...)
>
> file, objdump, or readelf (last is probably Linux specific).
> Examples on Linux:
>
>
> ~> objdump -f /bham/ums/linux/pd/packages/plt-scheme/bin/mzscheme
>
> /bham/ums/linux/pd/packages/plt-scheme/bin/mzscheme: file format
> elf32-i386
> architecture: i386, flags 0x00000112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0x0805e570
>
>
> ~> readelf -h /bham/ums/linux/pd/packages/plt-scheme/bin/mzscheme
> ELF Header:
> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: EXEC (Executable file)
> Machine: Intel 80386
> Version: 0x1
> Entry point address: 0x805e570
> Start of program headers: 52 (bytes into file)
> Start of section headers: 4806288 (bytes into file)
> Flags: 0x0
> Size of this header: 52 (bytes)
> Size of program headers: 32 (bytes)
> Number of program headers: 8
> Size of section headers: 40 (bytes)
> Number of section headers: 38
> Section header string table index: 35
>
>
>
> ~> file /bham/ums/linux/pd/packages/plt-scheme/bin/mzscheme
> /bham/ums/linux/pd/packages/plt-scheme/bin/mzscheme: ELF 32-bit LSB
> executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9,
> dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not
> stripped
>
>
>
> HTH,
> N.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090923/c7422f95/attachment.html>