I'm starting to wonder if the problem is not in this code, but rather in
one of the called routines. Perhaps the rbp register is getting clobbered
on one of the calls resulting in the trap immediately after the return.
Rici
On Mon, Jul 11, 2016 at 8:13 AM, René Jansen <rvjan...@xs4all.nl> wrote:
>
> On 10 jul. 2016, at 23:45, Rick McGuire <object.r...@gmail.com> wrote:
>
> It might be useful to compare the code generated by the non-optimized
> version to the optimized code. It might also be useful to compare the
> optimized code from a earlier compiler version.
>
>
> Eric, thanks for showing me how to set a breakpoint using
> mangling/signatures. In the meantime, I found out that objdump -d
> librexx.so gives a nice disassembly including object code.
>
> This is a working optimized GCC 5.3.1 method:
>
> 0000000000170110 <_ZN17MemorySegmentPool10newSegmentEm>:
> 170110: 41 55 push %r13
> 170112: 41 54 push %r12
> 170114: 4c 8d a6 ff 0f 00 00 lea 0xfff(%rsi),%r12
> 17011b: 55 push %rbp
> 17011c: 53 push %rbx
> 17011d: 48 89 fd mov %rdi,%rbp
> 170120: 49 89 f5 mov %rsi,%r13
> 170123: 49 81 e4 00 f0 ff ff and $0xfffffffffffff000,%r12
> 17012a: 48 83 ec 08 sub $0x8,%rsp
> 17012e: eb 37 jmp
> 170167 <_ZN17MemorySegmentPool10newSegmentEm+0x57>
> 170130: 48 8b 55 20 mov 0x20(%rbp),%rdx
> 170134: 4c 39 e2 cmp %r12,%rdx
> 170137: 73 57 jae
> 170190 <_ZN17MemorySegmentPool10newSegmentEm+0x80>
> 170139: 4c 89 ee mov %r13,%rsi
> 17013c: bf 38 00 00 00 mov $0x38,%edi
> 170141: e8 4a 3f f5 ff callq c4090
> <_ZN17MemorySegmentPoolnwEmm@plt>
> 170146: 48 89 c7 mov %rax,%rdi
> 170149: 48 89 c3 mov %rax,%rbx
> 17014c: e8 ef 6d f5 ff callq c6f40
> <_ZN17MemorySegmentPoolC1Ev@plt>
> 170151: 48 8b 3d d0 85 26 00 mov 0x2685d0(%rip),%rdi #
> 3d8728 <_DYNAMIC+0x1c10>
> 170158: 48 89 5d 00 mov %rbx,0x0(%rbp)
> 17015c: 48 89 de mov %rbx,%rsi
> 17015f: 48 89 dd mov %rbx,%rbp
> 170162: e8 59 b6 f5 ff
> callq cb7c0 <_ZN12MemoryObject15memoryPoolAddedEP17MemorySegmentPool@plt>
> 170167: 48 8b 45 08 mov 0x8(%rbp),%rax
> 17016b: 48 85 c0 test %rax,%rax
> 17016e: 74 c0 je
> 170130 <_ZN17MemorySegmentPool10newSegmentEm+0x20>
> 170170: 4c 3b 28 cmp (%rax),%r13
> 170173: 77 bb ja
> 170130 <_ZN17MemorySegmentPool10newSegmentEm+0x20>
> 170175: 48 c7 45 08 00 00 00 movq $0x0,0x8(%rbp)
> 17017c: 00
> 17017d: 48 83 c4 08 add $0x8,%rsp
> 170181: 5b pop %rbx
> 170182: 5d pop %rbp
> 170183: 41 5c pop %r12
> 170185: 41 5d pop %r13
> 170187: c3 retq
> 170188: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
> 17018f: 00
> 170190: 48 8b 45 10 mov 0x10(%rbp),%rax
> 170194: 48 85 c0 test %rax,%rax
> 170197: 74 08 je
> 1701a1 <_ZN17MemorySegmentPool10newSegmentEm+0x91>
> 170199: 49 8d 4c 24 e0 lea -0x20(%r12),%rcx
> 17019e: 48 89 08 mov %rcx,(%rax)
> 1701a1: 4c 29 e2 sub %r12,%rdx
> 1701a4: 49 01 c4 add %rax,%r12
> 1701a7: 48 89 55 20 mov %rdx,0x20(%rbp)
> 1701ab: 4c 89 65 10 mov %r12,0x10(%rbp)
> 1701af: 48 83 c4 08 add $0x8,%rsp
> 1701b3: 5b pop %rbx
> 1701b4: 5d pop %rbp
> 1701b5: 41 5c pop %r12
> 1701b7: 41 5d pop %r13
> 1701b9: c3 retq
> 1701ba: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
>
> This is the not-working GCC 6.1.1. method:
>
> 000000000016f500 <_ZN17MemorySegmentPool10newSegmentEm>:
> 16f500: 41 55 push %r13
> 16f502: 41 54 push %r12
> 16f504: 4c 8d a6 ff 0f 00 00 lea 0xfff(%rsi),%r12
> 16f50b: 55 push %rbp
> 16f50c: 53 push %rbx
> 16f50d: 48 89 fd mov %rdi,%rbp
> 16f510: 49 89 f5 mov %rsi,%r13
> 16f513: 49 81 e4 00 f0 ff ff and $0xfffffffffffff000,%r12
> 16f51a: 48 83 ec 08 sub $0x8,%rsp
> 16f51e: eb 37 jmp
> 16f557 <_ZN17MemorySegmentPool10newSegmentEm+0x57>
> 16f520: 48 8b 55 20 mov 0x20(%rbp),%rdx
> 16f524: 49 39 d4 cmp %rdx,%r12
> 16f527: 76 57 jbe
> 16f580 <_ZN17MemorySegmentPool10newSegmentEm+0x80>
> 16f529: 4c 89 ee mov %r13,%rsi
> 16f52c: bf 38 00 00 00 mov $0x38,%edi
> 16f531: e8 fa 0f f5 ff callq c0530
> <_ZN17MemorySegmentPoolnwEmm@plt>
> 16f536: 48 89 c7 mov %rax,%rdi
> 16f539: 48 89 c3 mov %rax,%rbx
> 16f53c: e8 5f 3e f5 ff callq c33a0
> <_ZN17MemorySegmentPoolC1Ev@plt>
> 16f541: 48 8b 3d 78 71 26 00 mov 0x267178(%rip),%rdi #
> 3d66c0 <_DYNAMIC+0x1d28>
> 16f548: 48 89 5d 00 mov %rbx,0x0(%rbp)
> 16f54c: 48 89 de mov %rbx,%rsi
> 16f54f: 48 89 dd mov %rbx,%rbp
> 16f552: e8 b9 86 f5 ff
> callq c7c10 <_ZN12MemoryObject15memoryPoolAddedEP17MemorySegmentPool@plt>
> 16f557: 48 8b 45 08 mov 0x8(%rbp),%rax
> 16f55b: 48 85 c0 test %rax,%rax
> 16f55e: 74 c0 je
> 16f520 <_ZN17MemorySegmentPool10newSegmentEm+0x20>
> 16f560: 4c 3b 28 cmp (%rax),%r13
> 16f563: 77 bb ja
> 16f520 <_ZN17MemorySegmentPool10newSegmentEm+0x20>
> 16f565: 48 c7 45 08 00 00 00 movq $0x0,0x8(%rbp)
> 16f56c: 00
> 16f56d: 48 83 c4 08 add $0x8,%rsp
> 16f571: 5b pop %rbx
> 16f572: 5d pop %rbp
> 16f573: 41 5c pop %r12
> 16f575: 41 5d pop %r13
> 16f577: c3 retq
> 16f578: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
> 16f57f: 00
> 16f580: 48 8b 45 10 mov 0x10(%rbp),%rax
> 16f584: 48 85 c0 test %rax,%rax
> 16f587: 74 08 je
> 16f591 <_ZN17MemorySegmentPool10newSegmentEm+0x91>
> 16f589: 49 8d 4c 24 e0 lea -0x20(%r12),%rcx
> 16f58e: 48 89 08 mov %rcx,(%rax)
> 16f591: 4c 29 e2 sub %r12,%rdx
> 16f594: 49 01 c4 add %rax,%r12
> 16f597: 48 89 55 20 mov %rdx,0x20(%rbp)
> 16f59b: 4c 89 65 10 mov %r12,0x10(%rbp)
> 16f59f: 48 83 c4 08 add $0x8,%rsp
> 16f5a3: 5b pop %rbx
> 16f5a4: 5d pop %rbp
> 16f5a5: 41 5c pop %r12
> 16f5a7: 41 5d pop %r13
> 16f5a9: c3 retq
> 16f5aa: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
>
> The first difference is the comparison %rdx,%r12 and the inverse jump
> instruction, jbe versus jae. By itself, this is harmless. The routines
> jumped to, resp. at 170190 (old) and 16f580 (new) are identical, as are the
> fragments that are executed if the jump falls through. From a quick
> inspection the generated code is identical - maybe someone else can spot a
> difference.
>
> So more debugging would be needed to see what is actually rbp and rax at
> the point that it segfaults.
>
>
> best regards,
>
> René.
>
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
