Tango 0.96 beta2 released

[Frits van Bommel]

Sean Kelly wrote:
> Frits van Bommel wrote:
>> Sean Kelly wrote:
>>
>>  > That said, if someone wants to
>>> pass on the relevant setjmp headers for a 64-bit glibc then I'll see 
>>> about expanding support.
>>
>> You mean the ones attached? Or do you need any others?
> 
> That should do it.  Though if there are any related comments on what 
> registers are stored in __jmp_buf, that would come in handy.  The ones I 
> have for Linux contain this in bits/setjmp.h:
> 
> #if defined __USE_MISC || defined _ASM
> # define JB_BX    0
> # define JB_SI    1
> # define JB_DI    2
> # define JB_BP    3
> # define JB_SP    4
> # define JB_PC    5
> # define JB_SIZE 24
> #endif
> 
> Your headers don't contain that however, so I'm not entirely sure how to 
> slice & dice jmp_buf to inject the proper information.  I'll google a 
> bit and try to find out as well.

Sorry, a "grep JB_ * -rn" didn't find anything...

[some time later]

I disassembled libc, this is the result:
0x00 rbx
0x08 rbp XOR POINTER_GUARD
0x10 r12
0x18 r13
0x20 r14
0x28 r15
0x30 (rsp before function call) XOR POINTER_GUARD
0x38 (return address) XOR POINTER_GUARD

Where POINTER_GUARD is the 8-byte value at fs:0x30.
Not sure why this is done, perhaps to avoid accidental dereferences?

later verified by apt-getting the source:
// from glibc-2.4/sysdeps/x86_64/jmpbuf-offsets.h
#define JB_RBX	0
#define JB_RBP	1
#define JB_R12	2
#define JB_R13	3
#define JB_R14	4
#define JB_R15	5
#define JB_RSP	6
#define JB_PC	7
#define JB_SIZE (8*8)

>>  > With this in mind, I don't suppose GDC yet
>>> supports inline ASM for the new 64-bit registers, etc?
>>
>> Not using the regular DMD-style with Intel syntax, IIRC. But the 
>> "extended asm" (using at&t syntax in strings) supports them, I think. 
>> Actually, if it's anything like regular GCC then it's almost literally 
>> dumped into the input sent to gas (the gnu assembler).
> 
> Oh, I didn't know GDC supported this the at&t string syntax.  Interesting.

I think I tried it a while back because I remembered that GCC passes the 
string along almost literally to the assembler, after failing to get the 
extended names to work in "regular" asm{} blocks.