On 2012-05-28, at 2:52 PM, Andreas Schwab wrote: > I was telling rubbish, the code is actually ok. > > Andreas.
Thank you for your help sir. On 2012-05-28, at 4:15 PM, Richard wrote: > Hi, > > when you suspect the assembler look at the output of "objdump -S test.o" and > compare with assembler input. You can also try to singlestep the asm code, > (stepi, info registers) in gdb and perhaps you have "ddd" or similar > available? > > Richard Hi Richard. Unfortunately I do not have objdump on NEXTSTEP, but I think I have another tool that I can use to disassemble the object file with. Thank you very much for the suggestion on single-stepping the asm code with gdb. I have gdb 4.7 and also SuperDebugger, which is a NEXTSTEP native "equivalent" of DDD. I used them already to narrow the issue down to the jump tables, but have very limited experience with asm code debugging. I will explore this option a bit, since I am sinking deeper and deeper into the porting process :-) On 2012-05-28, at 5:50 PM, Vincent Rivière wrote: > On 28/05/2012 14:06, t-rexky wrote: >> lsll #2,d0 >> movel pc@(L8,d0:l),d0 >> movel d0,a0 >> jmp a0@ >> .const >> .align 1 >> L8: >> .long L2 >> .long L3 >> .long L4 >> .long L5 >> .long L6 >> .long L7 >> .text >> L3: > > On my m68k-atari-mint port, the code generated by GCC is a bit different. > Especially, I don't have those lines: > .const > .align 1 > ... > .text > > That's quite surprising because I can't find that ".const" directive in the > gas manual. I don't know what it does. But if the goal of that directive > would be to change the output section, the generated code may be wrong, due > to PC-relative addressing. > > I suspect you have that ".const" somewhere in your configuration file, maybe > in the ASM_OUTPUT_CASE_END macro. If this is the case, try to remove that. The NEXTSTEP assembler is a very heavily modified gas-1.38 and the .const directive indeed changes the output section. To quote the NeXT manual directly: "The compiler places all data declared const in this section and all jump tables it generates for switch statements." 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. And because of the significant NeXT modifications to gas-1.38, I will not be able to port a newer gas version. As a side note, I also tried to move my configuration over to gcc-4.2.4 and the build fails in a very similar way. It does seem, however, to be at least 3 times faster than 4.4 and 4.6 :-). > See the documentation there: > http://gcc.gnu.org/onlinedocs/gccint/Dispatch-Tables.html > > Also, the following define is probably mandatory if your target allows a > separate read-only data section : > > #define JUMP_TABLES_IN_TEXT_SECTION 1 > > See there: > http://gcc.gnu.org/onlinedocs/gccint/Sections.html#index-JUMP_005fTABLES_005fIN_005fTEXT_005fSECTION-4432 > > Good luck. > > NB: From the two macros above, JUMP_TABLES_IN_TEXT_SECTION is probably the > closest to your solution. Thank you very much for the references. Over the last week I tried all possible combinations of target configuration, including using PC relative jump table configuration from your mint port. So far I had no luck, unfortunately. I really do not understand what I am missing here, but I will spend some more time with this. I feel like I am almost there, and it would be a great step forward for the NeXT community. > -- > Vincent Rivière Thank you again to everyone for your help! t-rexky -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
