3 ms·

In an ELF binary the exception tables are not intermingled with executable code but are coalesced into the .eh_frame section loaded in a separate read-only non-

by bregma 4y ago

In an ELF binary the exception tables are not intermingled with executable code but are coalesced into the .eh_frame section loaded in a separate read-only non-executable segment. The happy path is truly just the happy path standing alone.

saurik 4y ago
Sorry, I don't know all of the correct terminology. Is it the "landing pads"? Here is the code that is generated for main (after removing that constructor so it ends up without he extra call), and this is all in the text segment... and this definitely isn't "the happy path standing alone". 0000000000401160 <main>: 401160: 53 push %rbx 401161: e8 8a 00 00 00 callq 4011f0 <construct> 401166: e8 85 00 00 00 callq 4011f0 <construct> 40116b: e8 80 00 00 00 callq 4011f0 <construct> 401170: e8 8b 00 00 00 callq 401200 <destruct> 401175: e8 86 00 00 00 callq 401200 <destruct> 40117a: e8 81 00 00 00 callq 401200 <destruct> 40117f: b8 08 00 00 00 mov $0x8,%eax 401184: 5b pop %rbx 401185: c3 retq 401186: 48 89 c7 mov %rax,%rdi 401189: e8 52 00 00 00 callq 4011e0 <__clang_call_terminate> 40118e: 48 89 c7 mov %rax,%rdi 401191: e8 4a 00 00 00 callq 4011e0 <__clang_call_terminate> 401196: 48 89 c7 mov %rax,%rdi 401199: e8 42 00 00 00 callq 4011e0 <__clang_call_terminate> 40119e: 48 89 c3 mov %rax,%rbx 4011a1: e8 5a 00 00 00 callq 401200 <destruct> 4011a6: e8 55 00 00 00 callq 401200 <destruct> 4011ab: eb 18 jmp 4011c5 <main+0x65> 4011ad: 48 89 c7 mov %rax,%rdi 4011b0: e8 2b 00 00 00 callq 4011e0 <__clang_call_terminate> 4011b5: 48 89 c7 mov %rax,%rdi 4011b8: e8 23 00 00 00 callq 4011e0 <__clang_call_terminate> 4011bd: 48 89 c3 mov %rax,%rbx 4011c0: e8 3b 00 00 00 callq 401200 <destruct> 4011c5: 48 89 df mov %rbx,%rdi 4011c8: e8 93 fe ff ff callq 401060 <_Unwind_Resume@plt> 4011cd: 48 89 c7 mov %rax,%rdi 4011d0: e8 0b 00 00 00 callq 4011e0 <__clang_call_terminate> 4011d5: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 4011dc: 00 00 00 4011df: 90 The issue isn't the non-executable code: it is that it generates a lot more executable code that it intermixes with all of the rest of the code next to the code that relies on it, which is great for the performance of quickly being able to jump into the exceptional case but heavily dilutes the code cache and implies many more page faults and TLB misses.
- bregma 4y ago
  The happy path is 401160 through 401185. The unwinding code no more dilutes the code cache than any other subsequent and possibly unrelated functions in memory. The unwinding code is not there to make it faster since it's generally reached after walking the stack twice. It's moved out of the happy path to make the happy path faster since it doesn't dilute the instruction cache and doesn't hit the pipeline.

by bregma 4y ago

saurik 4y ago

Sorry, I don't know all of the correct terminology. Is it the "landing pads"? Here is the code that is generated for main (after removing that constructor so it ends up without he extra call), and this is all in the text segment... and this definitely isn't "the happy path standing alone". 0000000000401160 <main>: 401160: 53 push %rbx 401161: e8 8a 00 00 00 callq 4011f0 <construct> 401166: e8 85 00 00 00 callq 4011f0 <construct> 40116b: e8 80 00 00 00 callq 4011f0 <construct> 401170: e8 8b 00 00 00 callq 401200 <destruct> 401175: e8 86 00 00 00 callq 401200 <destruct> 40117a: e8 81 00 00 00 callq 401200 <destruct> 40117f: b8 08 00 00 00 mov $0x8,%eax 401184: 5b pop %rbx 401185: c3 retq 401186: 48 89 c7 mov %rax,%rdi 401189: e8 52 00 00 00 callq 4011e0 <__clang_call_terminate> 40118e: 48 89 c7 mov %rax,%rdi 401191: e8 4a 00 00 00 callq 4011e0 <__clang_call_terminate> 401196: 48 89 c7 mov %rax,%rdi 401199: e8 42 00 00 00 callq 4011e0 <__clang_call_terminate> 40119e: 48 89 c3 mov %rax,%rbx 4011a1: e8 5a 00 00 00 callq 401200 <destruct> 4011a6: e8 55 00 00 00 callq 401200 <destruct> 4011ab: eb 18 jmp 4011c5 <main+0x65> 4011ad: 48 89 c7 mov %rax,%rdi 4011b0: e8 2b 00 00 00 callq 4011e0 <__clang_call_terminate> 4011b5: 48 89 c7 mov %rax,%rdi 4011b8: e8 23 00 00 00 callq 4011e0 <__clang_call_terminate> 4011bd: 48 89 c3 mov %rax,%rbx 4011c0: e8 3b 00 00 00 callq 401200 <destruct> 4011c5: 48 89 df mov %rbx,%rdi 4011c8: e8 93 fe ff ff callq 401060 <_Unwind_Resume@plt> 4011cd: 48 89 c7 mov %rax,%rdi 4011d0: e8 0b 00 00 00 callq 4011e0 <__clang_call_terminate> 4011d5: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 4011dc: 00 00 00 4011df: 90 The issue isn't the non-executable code: it is that it generates a lot more executable code that it intermixes with all of the rest of the code next to the code that relies on it, which is great for the performance of quickly being able to jump into the exceptional case but heavily dilutes the code cache and implies many more page faults and TLB misses.

bregma 4y ago
The happy path is 401160 through 401185. The unwinding code no more dilutes the code cache than any other subsequent and possibly unrelated functions in memory. The unwinding code is not there to make it faster since it's generally reached after walking the stack twice. It's moved out of the happy path to make the happy path faster since it doesn't dilute the instruction cache and doesn't hit the pipeline.