Re: [Patch, Darwin, ppc] constrain processor usage for m32.
Assembler could be fixed easily (I'll contribute the patch to MacPorts cctools port) and the library is loading and working now. So I suggest disabling the use of 64 bit instructions and registers when targetting PowerPC Darwin 32 bit ABI can be considered working and a patch to gcc shouldn't be necessary. Am 04.01.2013 um 01:02 schrieb Tobias Netzel: Found the problem: The assembler generates a relocation of type LO14, meaning 14 bits that represent bits 2 - 15 of the effective address (lowest two bits are forced to zero), which is used for some types of 64 bit loads and stores. Unfortunately the OS X dynamic linker doesn't support that relocation type any more beginning with 10.4. After looking at the dyld sources It seems LO16 should be used instead. I'll see if I can fix the assembler. Am 01.01.2013 um 22:06 schrieb Mike Stump: On Jan 1, 2013, at 10:03 AM, Tobias Netzel tobias.net...@googlemail.com wrote: Or do you have any other ideas? I don't. I'd grab the .s files (compile with -save-temps) and start stripping things out til it loads, then then last thing stripped was the thing that broke it.
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
Found the problem: The assembler generates a relocation of type LO14, meaning 14 bits that represent bits 2 - 15 of the effective address (lowest two bits are forced to zero), which is used for some types of 64 bit loads and stores. Unfortunately the OS X dynamic linker doesn't support that relocation type any more beginning with 10.4. After looking at the dyld sources It seems LO16 should be used instead. I'll see if I can fix the assembler. Am 01.01.2013 um 22:06 schrieb Mike Stump: On Jan 1, 2013, at 10:03 AM, Tobias Netzel tobias.net...@googlemail.com wrote: Or do you have any other ideas? I don't. I'd grab the .s files (compile with -save-temps) and start stripping things out til it loads, then then last thing stripped was the thing that broke it.
[Patch, Darwin, ppc] constrain processor usage for m32.
Hi Iain, Mike and Andrew, I have been having issues compiling WebKit with mcpu=970 (or mcpu=G5) without afterwards passing mno-powerpc64 or m32 in to explicitly turn 64 bit instructions off. That was using Apple gcc 5666.3, which is Apples last published version and based on 4.2.1 . I also had another issue with ftree-vrp and found that in some later 4.2.x release a bug related to that was fixed, so I went ahead and merged 4.2.2 - 4.2.4 into Apple's gcc 4.2.1 sources. After that both issues are now gone! So, in gcc 4.2.4 I don't have anymore issues with usage of 64 bit instructions, hence this wasn't broken at that point point in time. Related bug report following: However I also tried to build the mozilla JavaScript library using gcc 4.7.2 as shared library optimized for the G5 explicitly. That works well and neither linker (ld64 97.17), nor mach-o binary tools nor compiler complain about anything. But OS X dyld throws an error complaining about unknown local relocation type when trying to load that library using dlopen(). Examining the library using otool does not show any incorrect local relocation, so I don't know what's going wrong. Might be a dyld bug but when I build with optimization turned off (- O0) the library loads and works fine. I tried to switch off as much optimizations turned on by -O1 as possible (building with -O1 does also cause the problem) but I can't get it working. I even explicitely disabled as much optimization passes as possible (using -fdisable-*) but to no avail. I could try debugging using gdb in order to find out the code that causes the problem. Or do you have any other ideas? Tobias
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
On Jan 1, 2013, at 10:03 AM, Tobias Netzel tobias.net...@googlemail.com wrote: Or do you have any other ideas? I don't. I'd grab the .s files (compile with -save-temps) and start stripping things out til it loads, then then last thing stripped was the thing that broke it.
[Patch, Darwin, ppc] constrain processor usage for m32.
Hi, At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug. OK for trunk all open branches? Iain gcc/ * config/rs6000/darwin.h (OS_MISSING_POWERPC64): New. Index: gcc/config/rs6000/darwin.h === --- gcc/config/rs6000/darwin.h (revision 189712) +++ gcc/config/rs6000/darwin.h (working copy) @@ -398,6 +398,9 @@ extern int darwin_emit_branch_islands; default, as kernel code doesn't save/restore those registers. */ #define OS_MISSING_ALTIVEC (flag_mkernel || flag_apple_kext) +/* When building m32 code, we cannot use POWERPC64. */ +#define OS_MISSING_POWERPC64 !TARGET_64BIT + /* Darwin has support for section anchors on powerpc*. It is disabled for any section containing a zero-sized item (because these are re-written as size=1 to be compatible with the OSX ld64).
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote: At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug. Hum, do you have an example of something that fails? I ask, cause I think the if you say that you have a 64-bit processor, then, generating code for a 64-bit processor isn't necessarily wrong. If you say you have a 64-bit processor, then you likely have an OS that runs on that processor, and that OS I'm thinking will save and restore the full 64-bit registers. If not, do you have a pointer to documentation that says this won't work?
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
On Sat, Jul 21, 2012 at 10:27 AM, Mike Stump mikest...@comcast.net wrote: On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote: At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug. Hum, do you have an example of something that fails? I ask, cause I think the if you say that you have a 64-bit processor, then, generating code for a 64-bit processor isn't necessarily wrong. If you say you have a 64-bit processor, then you likely have an OS that runs on that processor, and that OS I'm thinking will save and restore the full 64-bit registers. If not, do you have a pointer to documentation that says this won't work? In fact OS_MISSING_POWERPC64 was added because GNU/Linux does not have support but Darwin has the support in the OS. The whole point of -mpu=G5 means generate G5 code which includes generating PowerPC64 code. This was added explicitly to speed up code like crafty in SPEC. Do you have any data that says it should be disabled? If you don't want to generate powerpc64 code then use -mno-powerpc64. Thanks, Andrew Pinski
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
Hi Mike, On 21 Jul 2012, at 18:27, Mike Stump wrote: On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote: At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug. Hum, do you have an example of something that fails? I can look for something, if necessary. I ask, cause I think the if you say that you have a 64-bit processor, then, generating code for a 64-bit processor isn't necessarily wrong. indeed, highly desirable to make use of any improvements available. If you say you have a 64-bit processor, then you likely have an OS that runs on that processor, and that OS I'm thinking will save and restore the full 64-bit registers. If not, do you have a pointer to documentation that says this won't work? Mac_OS_X_ABI_Function_Calls.pdf pp 19 para 2 (box). This stipulates that even on a 64 bit processor, only the lower 32 bits of nonvolatile registers are saved/restored. All 64 bits are saved across context switches/asynchronous events. That is to quote the doc: one can *only* use the full 64 bits 'between function calls' safely. If there's a different mechanism for enforcing what's implied above, then we could use that. cheers Iain
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
On Sat, Jul 21, 2012 at 10:56 AM, Iain Sandoe i...@codesourcery.com wrote: Hi Mike, On 21 Jul 2012, at 18:27, Mike Stump wrote: On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote: At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) generate 64 bit register usage for m32 code. This appears to be a long-standing bug. Hum, do you have an example of something that fails? I can look for something, if necessary. I ask, cause I think the if you say that you have a 64-bit processor, then, generating code for a 64-bit processor isn't necessarily wrong. indeed, highly desirable to make use of any improvements available. If you say you have a 64-bit processor, then you likely have an OS that runs on that processor, and that OS I'm thinking will save and restore the full 64-bit registers. If not, do you have a pointer to documentation that says this won't work? Mac_OS_X_ABI_Function_Calls.pdf pp 19 para 2 (box). This stipulates that even on a 64 bit processor, only the lower 32 bits of nonvolatile registers are saved/restored. All 64 bits are saved across context switches/asynchronous events. That is to quote the doc: one can *only* use the full 64 bits 'between function calls' safely. If there's a different mechanism for enforcing what's implied above, then we could use Yes HARD_REGNO_CALL_PART_CLOBBERED should work. If that is not working there is a bug somewhere else in the compiler. Thanks, Andrew Pinski
Re: [Patch, Darwin, ppc] constrain processor usage for m32.
On 21 Jul 2012, at 19:02, Andrew Pinski wrote: If there's a different mechanism for enforcing what's implied above, then we could use Yes HARD_REGNO_CALL_PART_CLOBBERED should work. If that is not working there is a bug somewhere else in the compiler. thanks, that looks solid enough, will have to delve a bit deeper, re the original issue. Iain
