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

Reply via email to