[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|SUSPENDED --- Comment #21 from Eric Botcazou --- Probably too late to be changed now.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.5 |---
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.4 |8.5 --- Comment #20 from Jakub Jelinek --- GCC 8.4.0 has been released, adjusting target milestone.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #19 from Jean-Christophe Dubois --- (In reply to Andrew Pinski from comment #16) > (In reply to Jean-Christophe Dubois from comment #15) > > Am I missing something? > > YES. Most likely it will not be loaded in the instruction cache as it is > larger than the cache line size. Maybe this is not a big issue but couldn't the end of the jump table be loaded in instruction cache (depending on function alignment) with the beginning of the function it will be used with (when code is compiled with -Os functions don't seem to be aligned on cache line size) Or the beginning of the jump table with the end of the previous function. This might be only few bytes of instruction cache each time and maybe it is not an issue overall. And when you mix data and code there will also be some instruction that will enter the data cache if things are not aligned on cache line size. Maybe this is not an issue performance wise either.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #18 from Jean-Christophe Dubois --- (In reply to Mikael Pettersson from comment #17) > My though reading this is that most RICSs have problems synthesizing large > literals, so putting a jump table in .text might increase the likelihood of > its address being synthesizable with a PC + offset addressing mode. Putting > it in .rodata would almost certainly require you to indirect through the GOT > to address it. That said, if the user wants .text to be execute-only, then > the jump table ought to land in .rodata. As far as I can say with the assembly code generated today for SPARC32, the jump tables could be anywhere in memory (4GB address space) with the exact same code. I don't think it would trigger additional indirection. It might be different for other architecture.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #17 from Mikael Pettersson --- My though reading this is that most RICSs have problems synthesizing large literals, so putting a jump table in .text might increase the likelihood of its address being synthesizable with a PC + offset addressing mode. Putting it in .rodata would almost certainly require you to indirect through the GOT to address it. That said, if the user wants .text to be execute-only, then the jump table ought to land in .rodata.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #16 from Andrew Pinski --- (In reply to Jean-Christophe Dubois from comment #15) > Am I missing something? YES. Most likely it will not be loaded in the instruction cache as it is larger than the cache line size.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #15 from Jean-Christophe Dubois --- Thanks for the feedback and the support. Now maybe this is not the good place to ask question but I am wondering: Most of today's processors have separate data and instruction cache. Isn't it sub optimal performance wise to load the instruction cache with jump tables (just data consuming precious cache resource) and then having to load these same jump tables again in the data cache to use them (jump tables might then be loaded twice and eat instruction cache for no reason). If there were only processors with unified cache this would not be an issue but this is not the most common case in today's processors. Am I missing something? Shouldn't most architecture put jump tables in rodata section. Thanks JC
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #14 from Richard Henderson --- The only reason I can think for jump tables to be put into the text section is the old aout format, which didn't have a separate read only data section. There should be no reason to do that these days.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #13 from Eric Botcazou --- > I think that case vector stuff was written by Richard Henderson FWIW. Richard, do you have any recollection of this?
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #12 from davem at gcc dot gnu.org --- I think that case vector stuff was written by Richard Henderson FWIW.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #11 from Eric Botcazou --- Created attachment 47476 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47476=edit Tentative fix
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #10 from Eric Botcazou --- The SPARC port even has a specific implementation here: /* This is how we hook in and defer the case-vector until the end of the function. */ #define ASM_OUTPUT_ADDR_VEC(LAB,VEC) \ sparc_defer_case_vector ((LAB),(VEC), 0) #define ASM_OUTPUT_ADDR_DIFF_VEC(LAB,VEC) \ sparc_defer_case_vector ((LAB),(VEC), 1)
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added Summary|jump tables are put in the |jump tables are put into |.text section |the text section --- Comment #9 from Eric Botcazou --- > I cannot think of any specific reason why the jump tables were put into the > text section. I even tried to consider relocation ramifications. Yes, relocation considerations quickly come to mind. Thanks in any case. > Maybe this makes GOT OP linker optimizations more likely when -fPIC? I wonder whether this wouldn't stem from limitations of the Sun assembler or somesuch: in PIC mode, this would generate differences between labels from different sections, so relocations need to be generated by the assembler.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #8 from davem at gcc dot gnu.org --- I cannot think of any specific reason why the jump tables were put into the text section. I even tried to consider relocation ramifications. Maybe this makes GOT OP linker optimizations more likely when -fPIC?
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added CC||davem at gcc dot gnu.org --- Comment #7 from Eric Botcazou --- DaveM, any recollection about the rationale for the decision?
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #6 from Eric Botcazou --- > So assuming the intend is to put the jump table in the rodata section, > something seems to be broken in the build then. No, see my earlier remark, this was intended.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #5 from Jean-Christophe Dubois --- I guess JUMP_TABLES_IN_TEXT_SECTION is supposed to mean that the "jump tables" should not be put in the text section. However something is wrong then because gcc 9 (and maybe previous) is putting the jump table as a "subsection" of the text section in the generated assembly code (therefore it is part of the text section). I am attaching a generated assembly file where "jump tables" are generated and declared as subsection of the text section. In this file you can for example look at the L87 jump table which is used by the tfp_format function (this is the first jump table that triggered an exception in my test case). So assuming the intend is to put the jump table in the rodata section, something seems to be broken in the build then.
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #4 from Jean-Christophe Dubois --- Created attachment 47475 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47475=edit assembly file with jump tables in the text section
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #3 from Eric Botcazou --- The decision dates back to the rewrite of the SPARC port in 1998: 21652 davem /* Align to cache line in the function's code section. */ 21652 davem function_section (current_function_decl);
[Bug target/92902] jump tables are put in the .text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-11 CC||ebotcazou at gcc dot gnu.org Target Milestone|--- |8.4 Summary|gcc 9.2 puts "jump tables" |jump tables are put in the |in the .text section|.text section Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- Nothing has changed in GCC 9.x and this is also visible with GCC 7 & 8, although the SPARC port is configured with JUMP_TABLES_IN_TEXT_SECTION set to 0.
