basilisk-devel

[B2-devel] Inline Assembly Query

[Frank T. <fra...@gm...>]

Given the high level of interest in improving SheepShaver, it seems like it
might be good to get it to the point at which it compiles on newer versions
of Mac O.S., which probably means getting the code to compile in clang-llvm.

The code (or at least the first bit of it) that breaks llvm is on line 79
of SheepShaver/src/kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp. It calls a
number of macros from that file and from other files, which I have
consolidated here: {
#define OPPROTO

#if SIZEOF_VOID_P == 4
typedef uint32 uintptr;
typedef int32 intptr;
#elif SIZEOF_VOID_P == 8
typedef uint64 uintptr;
typedef int64 intptr;
#else
#error "Unsupported size of pointer"
#endif

#if defined(__APPLE__) && defined(__MACH__)
static int __op_PARAM1, __op_PARAM2, __op_PARAM3;
#else
extern int __op_PARAM1, __op_PARAM2, __op_PARAM3;
#endif
#define PARAM1 ((long)(&__op_PARAM1))
#define PARAM2 ((long)(&__op_PARAM2))
#define PARAM3 ((long)(&__op_PARAM3))

#define REG_CPU            AREG0
#define REG_CPU_ID        AREG0_ID
#define REG_T0            AREG1
#define REG_T0_ID        AREG1_ID
#define REG_T1            AREG2
#define REG_T1_ID        AREG2_ID
#define REG_T2            AREG3
#define REG_T2_ID        AREG3_ID
#ifdef  AREG4
#define REG_T3            AREG4
#define REG_T3_ID        AREG4_ID

// This is what gives us A0 and A1 and A2.
#define DYNGEN_DEFINE_GLOBAL_REGISTER(REG) \
register uintptr A##REG asm(REG_T##REG); \
register uint32  T##REG asm(REG_T##REG)
DYNGEN_DEFINE_GLOBAL_REGISTER(0);
DYNGEN_DEFINE_GLOBAL_REGISTER(1);
DYNGEN_DEFINE_GLOBAL_REGISTER(2);

#if defined __x86_64__
#define MOV_AD_REG(PARAM, REG) asm volatile ("movabsq $__op_" #PARAM ",%0"
: "=r" (REG))
#else
#define MOV_AD_REG(PARAM, REG) REG = PARAM
#endif

#define DEFINE_OP(REG)                            \
void OPPROTO op_mov_ad_##REG##_im(void)            \
{                                                \
    MOV_AD_REG(PARAM1, REG);                    \
}
}.

The problematic line is {
DEFINE_OP(A0);
} and seems to expand to {
void op_mov_ad_A0_im(void) {
asm volatile ("movabsq $__op_" ((long)(&__op_PARAM1)) ",%0" : "=r" (A0)) ;
}
}.

__op_PARAM1 is defined as a static or external and possibly signed integer
(depending upon platform) in dyngen-exec.h. The operation is apparently
(judging from the 32-bit branch) designed to stuff the value of __op_PARAM1
(which is normally 32 bits but could be shorter or longer) into A0 (which
is 64-bit on x86-64). I am not familiar with the __op_ token in asm and
cannot find any information on it. Does anybody know what is happening
here? Would it be unreasonable to allow the simple assignment if a long on
the platform in question is the same size as the target register?

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 7:27 PM, Frank Trampe wrote:

> __op_PARAM1 is defined as a static or external and possibly signed integer (depending upon platform) in dyngen-exec.h. The operation is apparently (judging from the 32-bit branch) designed to stuff the value of __op_PARAM1 (which is normally 32 bits but could be shorter or longer) into A0 (which is 64-bit on x86-64). I am not familiar with the __op_ token in asm and cannot find any information on it. Does anybody know what is happening here? Would it be unreasonable to allow the simple assignment if a long on the platform in question is the same size as the target register?

I think the problem might actually be the global register variables A0, A1, A2, T0, T1, T2. LLVM doesn’t like those. This is what clang complains about if you try to compile with it instead of LLVM-GCC, at least.

The easiest, if not the most satisfying, way to get BII/SS compiling on newer systems might be to get them to work with the various gcc ports available via MacPorts. I’ve been playing with that today, and getting sanity check errors in the configure script. Trying to figure out what’s going on there right now.

Charles

Re: [B2-devel] Inline Assembly Query

[Frank T. <fra...@gm...>]

Standard MacPorts gcc failed last time I tried, although I cannot remember
why.

On Mon, Jun 18, 2012 at 7:34 PM, Charles Srstka <
bas...@ch...> wrote:

> On Jun 18, 2012, at 7:27 PM, Frank Trampe wrote:
>
> __op_PARAM1 is defined as a static or external and possibly signed integer
> (depending upon platform) in dyngen-exec.h. The operation is apparently
> (judging from the 32-bit branch) designed to stuff the value of __op_PARAM1
> (which is normally 32 bits but could be shorter or longer) into A0 (which
> is 64-bit on x86-64). I am not familiar with the __op_ token in asm and
> cannot find any information on it. Does anybody know what is happening
> here? Would it be unreasonable to allow the simple assignment if a long on
> the platform in question is the same size as the target register?
>
>
> I think the problem might actually be the global register variables A0,
> A1, A2, T0, T1, T2. LLVM doesn’t like those. This is what clang complains
> about if you try to compile with it instead of LLVM-GCC, at least.
>
> The easiest, if not the most satisfying, way to get BII/SS compiling on
> newer systems might be to get them to work with the various gcc ports
> available via MacPorts. I’ve been playing with that today, and getting
> sanity check errors in the configure script. Trying to figure out what’s
> going on there right now.
>
> Charles
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 7:36 PM, Frank Trampe wrote:

> Standard MacPorts gcc failed last time I tried, although I cannot remember why.

The configure script fails when trying to figure out how to generate preprocessed output with GCC.

Charles

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 7:39 PM, Charles Srstka wrote:

> On Jun 18, 2012, at 7:36 PM, Frank Trampe wrote:
> 
>> Standard MacPorts gcc failed last time I tried, although I cannot remember why.
> 
> The configure script fails when trying to figure out how to generate preprocessed output with GCC.

... Never mind, the preprocessor failure was due to me being a moron.  The real problem here is that abi::__cxa_demangle() seems to be always failing with error -2 when attempting to demangle the symbol names in cxxdemangle.c. Not sure why that’s happening just yet.

Charles

Re: [B2-devel] Inline Assembly Query

[Gwenole B. <gb....@fr...>]

Hi,

Le 19 juin 2012 à 02:27, Frank Trampe a écrit :

> Given the high level of interest in improving SheepShaver, it seems like it might be good to get it to the point at which it compiles on newer versions of Mac O.S., which probably means getting the code to compile in clang-llvm.

The JIT based on dyngen needs to be built with GCC. You can select the GCC compiler to be used, see DYNGEN_CC variable.

Here are the solutions for the PPC emulator, in increasing order of complexity to implement:

1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes from that, or ship with pre-generated .{h,cpp} files that implement the opcodes for the supported target architectures (x86, x86_64, etc.)
3. Rework the JIT: migrate to TCG but VMX emulation performance will suffer, migrate to a full-blown DBT engine

I'd like to keep the dyngen-based generator for now as it would allow for easy update for AVX1/AVX2 support. At some point, I was also working on a mix of dyngen + something similar to what was implemented for QEMU (TCG).

Regards,
Gwenole.

Re: [B2-devel] Inline Assembly Query

[Alexei S. <ale...@gm...>]

>
> Here are the solutions for the PPC emulator, in increasing order of
> complexity to implement:
>
> 1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
> 2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes
> from that, or ship with pre-generated .{h,cpp} files that implement the
> opcodes for the supported target architectures (x86, x86_64, etc.)
> 3. Rework the JIT: migrate to TCG but VMX emulation performance will
> suffer, migrate to a full-blown DBT engine
>

4. Make clang/llvm support global registers ;)

-Alexei

Re: [B2-devel] Inline Assembly Query

[Frank T. <fra...@gm...>]

On Mon, Jun 18, 2012 at 11:18 PM, Gwenole Beauchesne <gb....@fr...>wrote:

> Hi,
>
> Le 19 juin 2012 à 02:27, Frank Trampe a écrit :
>
> > Given the high level of interest in improving SheepShaver, it seems like
> it might be good to get it to the point at which it compiles on newer
> versions of Mac O.S., which probably means getting the code to compile in
> clang-llvm.
>
> The JIT based on dyngen needs to be built with GCC. You can select the GCC
> compiler to be used, see DYNGEN_CC variable.
>
> Okay. For curiousity's sake, though, what is the meaning of the $__op_
prefix in the asm syntax?


> Here are the solutions for the PPC emulator, in increasing order of
> complexity to implement:
>
> 1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
> 2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes
> from that, or ship with pre-generated .{h,cpp} files that implement the
> opcodes for the supported target architectures (x86, x86_64, etc.)
> 3. Rework the JIT: migrate to TCG but VMX emulation performance will
> suffer, migrate to a full-blown DBT engine
>
> I'd like to keep the dyngen-based generator for now as it would allow for
> easy update for AVX1/AVX2 support. At some point, I was also working on a
> mix of dyngen + something similar to what was implemented for QEMU (TCG).
>
> Regards,
> Gwenole.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Inline Assembly Query

[Alexander v. G. <kal...@un...>]

On 18.06.2012 23:18, Gwenole Beauchesne wrote:
> Hi,
>
> Le 19 juin 2012 à 02:27, Frank Trampe a écrit :
>
>> Given the high level of interest in improving SheepShaver, it seems like 
>> it might be good to get it to the point at which it compiles on newer 
>> versions of Mac O.S., which probably means getting the code to compile in 
>> clang-llvm.
>
> The JIT based on dyngen needs to be built with GCC. You can select the GCC 
> compiler to be used, see DYNGEN_CC
> variable.
>
> Here are the solutions for the PPC emulator, in increasing order of 
> complexity to implement:
>
> 1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
> 2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes 
> from that, or ship with pre-generated
> .{h,cpp} files that implement the opcodes for the supported target 
> architectures (x86, x86_64, etc.)
> 3. Rework the JIT: migrate to TCG but VMX emulation performance will 
> suffer, migrate to a full-blown DBT engine
>
> I'd like to keep the dyngen-based generator for now as it would allow for 
> easy update for AVX1/AVX2 support. At some
> point, I was also working on a mix of dyngen + something similar to what 
> was implemented for QEMU (TCG).

I was actually looking into this for SheepShear... looks like a *big* 
undertaking though. qemu dropped the dyngen stuff
around 4 years ago.

At the moment i'm re-factoring all of the flat source files into classes (It 
should make moving to another emulation
core easier.)

https://github.com/kallisti5/sheepshear/commit/042f10a201a2dc3a17f52b3fa6144e03130552e2
https://github.com/kallisti5/sheepshear/blob/master/src/include/adb.h

https://github.com/kallisti5/sheepshear/commit/7af077b21e243b6f2ebc3b700d73e1b2c3af9674
https://github.com/kallisti5/sheepshear/blob/master/src/include/audio.h
https://github.com/kallisti5/sheepshear/blob/master/src/include/platform/Unix/platform_audio.h


  -- Alex

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 18, 2012, at 11:18 PM, Gwenole Beauchesne wrote:

> The JIT based on dyngen needs to be built with GCC. You can select the GCC compiler to be used, see DYNGEN_CC variable.

Unfortunately, the latest version of the dev tools no longer includes GCC. It does have LLVM-GCC, which is the GCC interface on the LLVM back-end, and this chokes on the global registers, same as Clang.

I’ve managed to get SheepShaver to compile using GCC 4.7 from MacPorts, but it’s currently quitting on launch — the shmat call at main_unix.cpp line 1172 is failing with ENOMEM.

Charles

Re: [B2-devel] Inline Assembly Query

[C.W. B. <com...@ho...>]

I think it chokes on another point of code, not the registers. Some type of cast, IIRC.

I don't know if this is relevant, but Lion's linker does position independent executable which I think messes up the pagezero test (when running configure, the pagezero test app crashes.)
On Jun 18, 2012, at 10:55 PM, Charles Srstka wrote:

> On Jun 18, 2012, at 11:18 PM, Gwenole Beauchesne wrote:
> 
>> The JIT based on dyngen needs to be built with GCC. You can select the GCC compiler to be used, see DYNGEN_CC variable.
> 
> Unfortunately, the latest version of the dev tools no longer includes GCC. It does have LLVM-GCC, which is the GCC interface on the LLVM back-end, and this chokes on the global registers, same as Clang.
> 
> I’ve managed to get SheepShaver to compile using GCC 4.7 from MacPorts, but it’s currently quitting on launch — the shmat call at main_unix.cpp line 1172 is failing with ENOMEM.
> 
> Charles
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

I actually got past that point since I wrote that, and I’ve incidentally managed to get SheepShaver to compile on Lion in a form that would run, although via a decidedly kludgey method. I was going to post on the list, but haven’t gotten around to it; sorry about that. Here’s what I've found:

1. As you surmised, the shmat problem is related to the pagezero test not working, which is indeed caused by changes in Lion. I was able to work around this by adding -mmacosx-version-min=10.6 to CFLAGS, CXXFLAGS, and LDFLAGS.

2. With the default settings you get from configure, dyngen will choke on a bunch of extra symbols from functions that are supposed to be inlined. This is fixed by adding -O2 to the flags; easy enough.

3. MacPorts contains port files for the latest stable version of GCC (gcc47), as well as the last version of GCC that Apple shipped with Xcode (apple-gcc42), so there’s no need to have an old version of the Apple dev tools around. However, each has its own problems:

3a. Vanilla gcc47 doesn’t have Apple’s non-standard blocks implementation, so all the code that imports, for example, <Foundation/Foundation.h> will choke on all the ^ characters. The workaround for this is to either create your own hacked Frameworks folder with the block-using APIs removed from the headers or to pull the Mac OS X 10.5 SDK from an earlier version of Xcode (as blocks weren’t introduced until 10.6), and then add '-iframework /path/to/my/Frameworks’ to CFLAGS and CXXFLAGS.

3b. Applying all the above results in a binary that compiles, and gets past the shmat stuff, but then spits out an "Invalid thread_state flavor = 0. Not forwarding” and promptly crashes. I never was able to figure out what was causing this.

4. Using apple-gcc42 from MacPorts solves the above problems, but it introduces a wrinkle of its own: api::__cxa_demangle doesn’t work, failing every time with status -2, even if the symbol name is valid, for no reason I can discover, which causes dyngen to choke with a bunch of “unexpected external symbol _ZL11foov” type errors. Libiberty’s demangling doesn’t seem to work either. This, also, I haven’t been able to figure out.

I kludged it into working by doing the follows:

1. I made a quick-and-dirty demangle app which takes a symbol name on the command line and outputs the demangled name. I compiled this with vanilla gcc 4.7 and put it in /usr/local/bin.

2. I hacked src/kpx_cpu/src/cpu/jit/cxxdemangle.cpp so that it would fork/exec my demangle tool and use the output from that instead of trying to call api::__cxa_demangle itself.

3. I compiled the rest of the project using these settings:

CC=/opt/local/bin/gcc-apple-4.2; export CC
CPP="$CC -E"; export CPP
CXX=/opt/local/bin/g++-apple-4.2; export CXX
CFLAGS="-O2 -mmacosx-version-min=10.6"; export CFLAGS
CXXFLAGS=$CFLAGS; export CXXFLAGS
LDFLAGS="-mmacosx-version-min=10.6"; export LDFLAGS
NO_CONFIGURE=1 ACLOCAL_FLAGS="-I m4" ./autogen.sh 
./configure --enable-sdl-framework --enable-sdl-audio --enable-sdl-video --disable-vosf
make

What do you know, it compiles, and it works. Not the most convenient thing in the world, but better than nothing.

Charles

On Jun 27, 2012, at 7:30 PM, C.W. Betts wrote:

> I think it chokes on another point of code, not the registers. Some type of cast, IIRC.
> 
> I don't know if this is relevant, but Lion's linker does position independent executable which I think messes up the pagezero test (when running configure, the pagezero test app crashes.)
> On Jun 18, 2012, at 10:55 PM, Charles Srstka wrote:
> 
>> On Jun 18, 2012, at 11:18 PM, Gwenole Beauchesne wrote:
>> 
>>> The JIT based on dyngen needs to be built with GCC. You can select the GCC compiler to be used, see DYNGEN_CC variable.
>> 
>> Unfortunately, the latest version of the dev tools no longer includes GCC. It does have LLVM-GCC, which is the GCC interface on the LLVM back-end, and this chokes on the global registers, same as Clang.
>> 
>> I’ve managed to get SheepShaver to compile using GCC 4.7 from MacPorts, but it’s currently quitting on launch — the shmat call at main_unix.cpp line 1172 is failing with ENOMEM.
>> 
>> Charles
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Inline Assembly Query

[C.W. B. <com...@ho...>]

If you are planning on using TCG from Qemu, you will have to use the TCG interpreter because otherwise clang will fail due to a global register variable. At least on the i386 code.
...
On further testing, it works fine on the PowerPC code; you don't need to use the TCG interpreter, just the regular TCG will work fine.
On Jun 18, 2012, at 10:18 PM, Gwenole Beauchesne wrote:

> Hi,
> 
> Le 19 juin 2012 à 02:27, Frank Trampe a écrit :
> 
>> Given the high level of interest in improving SheepShaver, it seems like it might be good to get it to the point at which it compiles on newer versions of Mac O.S., which probably means getting the code to compile in clang-llvm.
> 
> The JIT based on dyngen needs to be built with GCC. You can select the GCC compiler to be used, see DYNGEN_CC variable.
> 
> Here are the solutions for the PPC emulator, in increasing order of complexity to implement:
> 
> 1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
> 2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes from that, or ship with pre-generated .{h,cpp} files that implement the opcodes for the supported target architectures (x86, x86_64, etc.)
> 3. Rework the JIT: migrate to TCG but VMX emulation performance will suffer, migrate to a full-blown DBT engine
> 
> I'd like to keep the dyngen-based generator for now as it would allow for easy update for AVX1/AVX2 support. At some point, I was also working on a mix of dyngen + something similar to what was implemented for QEMU (TCG).
> 
> Regards,
> Gwenole.
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 

Re: [B2-devel] Inline Assembly Query

[Alexander v. G. <kal...@un...>]

Good morning,

I've actually got SheepShear compiling and running on 10.6 (minus jit)

http://pub.haikungfu.net/SheepShear-OSX.png

The trick is using an older Xcode (4.0.x) *or* using this:
https://github.com/kennethreitz/osx-gcc-installer

Right now i'm trying to figure out a build system outside of
Xcode for SheepShear on OS X as I *HATE* how messy Xcode is.
(to get the result above, I just used the autoconf stuff in src/Unix.

https://github.com/kallisti5/sheepshear/issues/11

Thanks!

  --Alex


On 27.06.2012 20:04, C.W. Betts wrote:
> If you are planning on using TCG from Qemu, you will have to use the TCG 
> interpreter because otherwise clang will
> fail due to a global register variable. At least on the i386 code.
> ...
> On further testing, it works fine on the PowerPC code; you don't need to 
> use the TCG interpreter, just the regular
> TCG will work fine.
> On Jun 18, 2012, at 10:18 PM, Gwenole Beauchesne wrote:
>
>> Hi,
>>
>> Le 19 juin 2012 à 02:27, Frank Trampe a écrit :
>>
>>> Given the high level of interest in improving SheepShaver, it seems like 
>>> it might be good to get it to the point at which it compiles on newer 
>>> versions of Mac O.S., which probably means getting the code to compile in 
>>> clang-llvm.
>>
>> The JIT based on dyngen needs to be built with GCC. You can select the 
>> GCC compiler to be used, see DYNGEN_CC variable.
>>
>> Here are the solutions for the PPC emulator, in increasing order of 
>> complexity to implement:
>>
>> 1. Always use GCC as it is intended, and set DYNGEN_CC accordingly.
>> 2. Ship with pre-compiled ELF binaries and regenerate synthetic opcodes 
>> from that, or ship with pre-generated .{h,cpp} files that implement the 
>> opcodes for the supported target architectures (x86, x86_64, etc.)
>> 3. Rework the JIT: migrate to TCG but VMX emulation performance will 
>> suffer, migrate to a full-blown DBT engine
>>
>> I'd like to keep the dyngen-based generator for now as it would allow for 
>> easy update for AVX1/AVX2 support. At some point, I was also working on a 
>> mix of dyngen + something similar to what was implemented for QEMU (TCG).
>>
>> Regards,
>> Gwenole.
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>
>
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Inline Assembly Query

[Charles S. <bas...@ch...>]

On Jun 28, 2012, at 7:42 AM, Alexander von Gluck wrote:

> The trick is using an older Xcode (4.0.x) *or* using this:
> https://github.com/kennethreitz/osx-gcc-installer

Ack, that installer puts stuff not only in /usr/bin, /usr/lib, etc. instead of /usr/local, but it even puts stuff in /System. That is very icky for a third-party installer, and it doesn’t seem to work any better than ‘port install apple-gcc42’ does, having the same problem with abi::__cxa_demangle() not working.

Charles