Re: Has anyone successfully bootstrapped gcc-4.6.3 on m68k?

[Vaugha Brewchuk <vaugha_brewchuk@yahoo.ca>]

I finally have some good news and good progress with gcc-4.2.4.  I was able to identify the issue, and it was a combination of finger trouble and the make process.  I spent some time with gdb and eventually realised that while my changes were propagating to the libraries (such as libiberty), the tools in gcc/build were not being recompiled with the modified stage1 xgcc.  So the jump tables were fixed, but the build kept crashing with bus errors because of switch statements in the tools themselves.  I am a bit mad at myself for not catching this earlier.

I will double-check gcc-4.6 once the 4.2 build is finished (if it finishes, of course), but I have a feeling that it will continue to break.  More on this below.

On 2012-05-30, at 4:19 AM, Vincent Rivière wrote:

> On 30/05/2012 02:58, t-rexky wrote:
>> The NEXTSTEP assembler is a very heavily modified gas-1.38 and the
>> .const directive indeed changes the output section.
> 
> Ok, it is unlikely that the .text and .const sections have a fixed distance, so PC-relative jump tables can't work.
> 
> ASM_OUTPUT_ADDR_VEC_ELT may be for you:
> http://gcc.gnu.org/onlinedocs/gccint/Dispatch-Tables.html#index-ASM_005fOUTPUT_005fADDR_005fVEC_005fELT-4612

I looked at ASM_OUTPUT_ADDR_VEC_ELT and was able to determine that all the NeXT target configuration files always relied on the definition provided in m68k.h.

Based on what I have seen, I believe that the NeXT is / was the only m68k target that used absolute jump tables so that specific configuration has likely not been exercised in over 10 years (since gcc-2.95.3 in fact).  So I think I am exploring a bit of a new ground here.

> As I suggested previously, alternatively the following should do the trick:
> #define JUMP_TABLES_IN_TEXT_SECTION 1
> 
> But this is not the right solution, because the jump tables will stay in the .text segment instead of going to the .const segment as expected.

Per your suggestions, I also tried getting to the bottom of the JUMP_TABLES_IN_TEXT_SECTION macro.  I compiled various combinations of switch statements with the original NeXT cc, with gcc-3.2.3 and with gcc-4.2.4.  It is very interesting that the NeXT "factory" configuration for cc (gcc-2.5) sets JUMP_TABLES_IN_TEXT_SECTION 1, while all FSF configurations set JUMP_TABLES_IN_TEXT_SECTION 0.  Both seem to work, but I settled on JUMP_TABLES_IN_TEXT_SECTION 1 per your suggestion and per the NeXT configuration.

>> I am trying to figure out exactly what has changed in gcc, since the
>> jump tables  worked just fine with gcc-3.4.6 and the exact same
>> target configuration I am using.
> 
> Look at the assembly output from gcc-3.4.6 and see the difference in the generated jump table code.
> 
> Since .const is a nonstandard keyword, it may not be used in many places in your gcc-4.6 source tree. Try to grep for it, and you will find where it has specifically be patched. There are probably other useful macros there.

I spent a substantial amount of time reviewing the changes made to the m68k target configuration files since gcc-3.2.3 and suspect that I might have found the culprit.  The NeXT configuration uses the following override:

/* Don't treat addresses involving labels differently from symbol names.
 Previously, references to labels generated pc-relative addressing modes
 while references to symbol names generated absolute addressing modes.  */

#undef	GO_IF_INDEXABLE_BASE
#define GO_IF_INDEXABLE_BASE(X, ADDR)                                       \
{ if (LEGITIMATE_BASE_REG_P (X)) goto ADDR; }

As of gcc-4.3 the m68k addressing modes have undergone substantial revision and GO_IF_INDEXABLE_BASE is no longer used.  I did not have a chance yet to verify this theory, since I am too excited about finally being able to proceed with stage2 of gcc-4.2.4.  I am planning on further experimenting with this a bit later.

On a related note, the difference between assembly code generated by my NeXT ports of gcc-3.2.3 and 4.6.3 for jump tables is as follows (I changed the label numbers for clarity):

gcc-3.2.3 (works fine):

	movel a6@(-4),d0
	lsll #2,d0
	movel #L9,a0
	movel a0@(d0:l),a0
	jmp a0@
	.const
	.align 1
L9:
	.long L8
	.long L3
	.long L4
	.long L5
	.long L6
	.long L7

gcc-4.6.3 (bus errors):

	movel pc@(L9,d0:l),d0
	movel d0,a0
	jmp a0@
	.const
	.align 1
L9:
	.long L8
	.long L3
	.long L4
	.long L5
	.long L6
	.long L7

Thank you all,
t-rexky

> -- 
> Vincent Rivière
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-68k-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/4FC5D807.4070204@freesbee.fr
>