https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221288
--- Comment #9 from Mark Millard <mar...@dsl-only.net> ---
(In reply to Mark Millard from comment #6)
Returning to a g++6 based a.out back trace
for the C++ threading to show some
infrastructure usage involved:
Thread 12 received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100277 of process 18243]
uw_frame_state_for (context=context@entry=0x7fffdfbfbe20,
fs=fs@entry=0x7fffdfbfbb70) at
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
1249 return MD_FALLBACK_FRAME_STATE_FOR (context, fs);
(gdb) disass
Dump of assembler code for function uw_frame_state_for:
. . .
0x0000000800e14a6e <+94>: callq 0x800e08870 <_Unwind_Find_FDE@plt>
0x0000000800e14a73 <+99>: test %rax,%rax
0x0000000800e14a76 <+102>: mov %rax,%r12
0x0000000800e14a79 <+105>: je 0x800e14bd8 <uw_frame_state_for+456>
. . .
0x0000000800e14bd8 <+456>: mov 0x98(%r15),%rax
=> 0x0000000800e14bdf <+463>: cmpl $0x247c8d48,(%rax)
0x0000000800e14be5 <+469>: je 0x800e14e62 <uw_frame_state_for+1106>
0x0000000800e14beb <+475>: nopl 0x0(%rax,%rax,1)
0x0000000800e14bf0 <+480>: mov $0x5,%eax
0x0000000800e14bf5 <+485>: add $0x38,%rsp
0x0000000800e14bf9 <+489>: pop %rbx
0x0000000800e14bfa <+490>: pop %rbp
0x0000000800e14bfb <+491>: pop %r12
0x0000000800e14bfd <+493>: pop %r13
0x0000000800e14bff <+495>: pop %r14
0x0000000800e14c01 <+497>: pop %r15
0x0000000800e14c03 <+499>: retq
. . .
which matches up with the 0x247c8d48 comparison code
in:
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/config/i386/freebsd-unwind.h
in the source:
. . .
#ifdef __x86_64__
#define MD_FALLBACK_FRAME_STATE_FOR x86_64_freebsd_fallback_frame_state
static _Unwind_Reason_Code
x86_64_freebsd_fallback_frame_state
(struct _Unwind_Context *context, _Unwind_FrameState *fs)
{
struct sigframe *sf;
long new_cfa;
/* Prior to FreeBSD 9, the signal trampoline was located immediately
before the ps_strings. To support non-executable stacks on AMD64,
the sigtramp was moved to a shared page for FreeBSD 9. Unfortunately
this means looking frame patterns again (sys/amd64/amd64/sigtramp.S)
rather than using the robust and convenient KERN_PS_STRINGS trick.
<pc + 00>: lea 0x10(%rsp),%rdi
<pc + 05>: pushq $0x0
<pc + 17>: mov $0x1a1,%rax
<pc + 14>: syscall
If we can't find this pattern, we're at the end of the stack.
*/
if (!( *(unsigned int *)(context->ra) == 0x247c8d48
&& *(unsigned int *)(context->ra + 4) == 0x48006a10
&& *(unsigned int *)(context->ra + 8) == 0x01a1c0c7
&& *(unsigned int *)(context->ra + 12) == 0x050f0000 ))
return _URC_END_OF_STACK;
. . .
where:
(gdb) print context->ra
$2 = (void *) 0x7fffdf7fb000
(gdb) print *(unsigned*)(context->ra)
Cannot access memory at address 0x7fffdf7fb000
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
