Re: svn commit: r339898 - head/lib/libc/amd64/sys

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Charlie Li
On 29/10/2018 20:11, Konstantin Belousov wrote:

> Author: kib
> Date: Tue Oct 30 00:11:30 2018
> New Revision: 339898
> URL: https://svnweb.freebsd.org/changeset/base/339898
>
> Log:
>   Convert amd64_get/set_fs/gsbase to ifunc.
>  
>   Note that this is the first use of ifuncs in our userspace.
>  
>   Sponsored by: The FreeBSD Foundation
>   MFC after: 1 month
>
> Deleted:
>   head/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.c
>   head/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.h
> Modified:
>   head/lib/libc/amd64/sys/Makefile.inc
>   head/lib/libc/amd64/sys/amd64_get_fsbase.c
>   head/lib/libc/amd64/sys/amd64_get_gsbase.c
>   head/lib/libc/amd64/sys/amd64_set_fsbase.c
>   head/lib/libc/amd64/sys/amd64_set_gsbase.c
>
Using LLVM 7 to build world, fails:

--- amd64_get_fsbase.o ---
/usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c:60:1: error: ifunc
resolver function must have no parameters
--- amd64_get_gsbase.o ---
/usr/src/lib/libc/amd64/sys/amd64_get_gsbase.c:60:1: error: ifunc
resolver function must have no parameters
DEFINE_UIFUNC(, int, amd64_get_gsbase, (void **), static)
^
/usr/local/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44:
note: expanded from macro 'DEFINE_UIFUNC'
--- amd64_get_fsbase.o ---
DEFINE_UIFUNC(, int, amd64_get_fsbase, (void **), static)
^
/usr/local/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44:
note: expanded from macro 'DEFINE_UIFUNC'
--- amd64_get_gsbase.o ---
    qual ret_type name args __attribute__((ifunc(#name "_resolver")));  \
                                           ^
--- amd64_get_fsbase.o ---
    qual ret_type name args __attribute__((ifunc(#name "_resolver")));  \
                                           ^
1 error generated.
--- amd64_get_gsbase.o ---
1 error generated.
*** [amd64_get_gsbase.o] Error code 1

make[4]: stopped in /usr/src/lib/libc

CI appears green after this commit, so I'm inclined to pin this on yet
another instance of LLVM 7 being stricter than LLVM 6. Backing out this
revision allows the build to continue (successfully).

--
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Charlie Li
On 01/11/2018 15:43, Charlie Li wrote:
> On 01/11/2018 12:04, Brooks Davis wrote:
>> Is this failure with devel/llvm70?  It's currently missing the patch
>> required to make this work.  https://reviews.freebsd.org/D17709 contains
>> this patch among others.  I'll see about getting it applied.
>>
> Yes, devel/llvm70. Will build with your port commit at my next opportunity.
>
After building world and kernel r340097, kernel runs fine, but every
userspace program in world crashes with Illegal instruction. They all
crash in exactly the same way. Example backtrace from bmake, running
from objdir (first discovered after updating a poudriere jail and
attempting to even start it):

Reading symbols from
/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from
/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done.
done.
[New LWP 100097]
Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make
--help'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x00000000002f5664 in _init ()
(gdb) bt
#0  0x00000000002f5664 in _init ()
#1  0x00000000002290fe in _start (ap=<optimized out>, cleanup=<optimized
out>) at /usr/src/lib/csu/amd64/crt1.c:66

Given the line number referenced in crt1.c, I'm guessing this condition
may have existed since at least r339351.

--
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Konstantin Belousov
On Sat, Nov 03, 2018 at 08:52:16AM -0400, Charlie Li wrote:

> On 01/11/2018 15:43, Charlie Li wrote:
> > On 01/11/2018 12:04, Brooks Davis wrote:
> >> Is this failure with devel/llvm70?  It's currently missing the patch
> >> required to make this work.  https://reviews.freebsd.org/D17709 contains
> >> this patch among others.  I'll see about getting it applied.
> >>
> > Yes, devel/llvm70. Will build with your port commit at my next opportunity.
> >
> After building world and kernel r340097, kernel runs fine, but every
> userspace program in world crashes with Illegal instruction. They all
> crash in exactly the same way. Example backtrace from bmake, running
> from objdir (first discovered after updating a poudriere jail and
> attempting to even start it):
>
> Reading symbols from
> /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from
> /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done.
> done.
> [New LWP 100097]
> Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make
> --help'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  0x00000000002f5664 in _init ()
> (gdb) bt
> #0  0x00000000002f5664 in _init ()
> #1  0x00000000002290fe in _start (ap=<optimized out>, cleanup=<optimized
> out>) at /usr/src/lib/csu/amd64/crt1.c:66
>
> Given the line number referenced in crt1.c, I'm guessing this condition
> may have existed since at least r339351.

Some minimal amount of facts instead of guesses would be much more useful.

What is the instruction which faulted ?  Disassemble the text at 0x2f5664.
Regardless of what is the instruction, show either the output from
'x86info -f' on the machine, or cpu identification lines from the
_verbose_ boot dmesg.

make is statically linked, do dynamically linked program fault ?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Charlie Li
On 03/11/2018 11:29, Konstantin Belousov wrote:
> Some minimal amount of facts instead of guesses would be much more useful.
>
Yeah, being sleep deprived and hurried (on my end) certainly doesn't help.
> What is the instruction which faulted ?  Disassemble the text at 0x2f5664.
> Regardless of what is the instruction, show either the output from
> 'x86info -f' on the machine, or cpu identification lines from the
> _verbose_ boot dmesg.
>
It appears that 0x2f5664 does not exist:

Disassembly of section .init:

00000000002f565c <_init>:
  2f565c:       48 83 ec 08             sub    $0x8,%rsp
  2f5660:       e8 fb 3c f3 ff          callq  229360 <frame_dummy>
  2f5665:       e8 b6 ff ff ff          callq  2f5620
<__do_global_ctors_aux>
  2f566a:       48 83 c4 08             add    $0x8,%rsp
  2f566e:       c3                      retq

CPU ident:

CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306d4  Family=0x6  Model=0x3d  Stepping=4

Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>

Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended
Features=0x21c27ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,RDSEED,ADX,SMAP,PROCTRACE>
  Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0x1<XSAVEOPT>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
> make is statically linked, do dynamically linked program fault ?
>
After some more checks, only the statically linked programs crash.

--
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Konstantin Belousov
On Sat, Nov 03, 2018 at 06:59:02PM -0400, Charlie Li wrote:

> On 03/11/2018 11:29, Konstantin Belousov wrote:
> > Some minimal amount of facts instead of guesses would be much more useful.
> >
> Yeah, being sleep deprived and hurried (on my end) certainly doesn't help.
> > What is the instruction which faulted ?  Disassemble the text at 0x2f5664.
> > Regardless of what is the instruction, show either the output from
> > 'x86info -f' on the machine, or cpu identification lines from the
> > _verbose_ boot dmesg.
> >
> It appears that 0x2f5664 does not exist:
Or rather, it is a middle of the valid instruction.
Next frame looks like it is process_irelocs(), if trusting the line
numbers.  So most likely it is something related to calling wrong
relocator function, if anything.

Perhaps you could try to trace the things manually, doing
single-stepping of the startup code in debugger. There should be very
modest amount of the irelocs, perhaps only one, and see where things go
off the way.

Might be try to vary the clang version, we know that this work with
6.0.1, and according to your report, breaks with 7.0.  Try clang trunk ?

>
> Disassembly of section .init:
>
> 00000000002f565c <_init>:
>   2f565c:       48 83 ec 08             sub    $0x8,%rsp
>   2f5660:       e8 fb 3c f3 ff          callq  229360 <frame_dummy>
>   2f5665:       e8 b6 ff ff ff          callq  2f5620
> <__do_global_ctors_aux>
>   2f566a:       48 83 c4 08             add    $0x8,%rsp
>   2f566e:       c3                      retq
>
> CPU ident:
>
> CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306d4  Family=0x6  Model=0x3d  Stepping=4
>
> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>
> Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
>   AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
>   AMD Features2=0x121<LAHF,ABM,Prefetch>
>   Structured Extended
> Features=0x21c27ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,RDSEED,ADX,SMAP,PROCTRACE>
>   Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
>   XSAVE Features=0x1<XSAVEOPT>
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> > make is statically linked, do dynamically linked program fault ?
> >
> After some more checks, only the statically linked programs crash.
>
> --
> Charlie Li
> Can't think of a witty .sigline today…
>
> (This email address is for mailing list use only; replace local-part
> with vishwin for off-list communication)
>



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Julian Elischer-5
In reply to this post by Charlie Li
what's an ifunc?


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Dimitry Andric-4
On 4 Nov 2018, at 08:43, Julian Elischer <[hidden email]> wrote:
>
> what's an ifunc?

This is a GNU extension, an "indirect function".  It allows you to
provide multiple different implementations of the same function, for
instance optimized for specific CPU types, and choose between them at
dynamic link time (e.g. at run time).

See the following for more information:

https://sourceware.org/glibc/wiki/GNU_IFUNC
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute

-Dimitry


signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Konstantin Belousov
In reply to this post by Julian Elischer-5
On Sun, Nov 04, 2018 at 12:43:34AM -0700, Julian Elischer wrote:
> what's an ifunc?
>
A special kind of relocation, controlled by the user code.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

svn commit: r339898 - head/lib/libc/amd64/sys

Charlie Li
In reply to this post by Konstantin Belousov
On 03/11/2018 19:45, Konstantin Belousov wrote:

> Or rather, it is a middle of the valid instruction.
> Next frame looks like it is process_irelocs(), if trusting the line
> numbers.  So most likely it is something related to calling wrong
> relocator function, if anything.
>
> Perhaps you could try to trace the things manually, doing
> single-stepping of the startup code in debugger. There should be very
> modest amount of the irelocs, perhaps only one, and see where things go
> off the way.
>
After a few more complete buildworlds, including one with all
bootstrapping enabled, this doesn't look compiler-specific. Static
binaries built with the in-tree base LLVM (6.0.1) also crash.

I stepped through bmake with base lldb, comparing the working copy in my
system from circa r339990 with r340173 built with bootstrapped
toolchain. Only the differing parts are shown for conciseness.

Circa r339990:
Process 82271 stopped
* thread #1, name = 'make', stop reason = step over
    frame #0: 0x000000000024ab06 make`_init_tls at tls.c:471
   468          }
   469          tls = _rtld_allocate_tls(NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN);
   470
-> 471          _set_tp(tls);
   472  #endif
   473  }
(lldb) n
Process 82271 stopped
* thread #1, name = 'make', stop reason = step over
    frame #0: 0x0000000000255e60 make`_set_tp(tp=0x00000008002f7830) at
_set_tp.c:38
   35
   36   void
   37   _set_tp(void *tp)
-> 38   {
   39
   40           amd64_set_fsbase(tp);
   41   }
(lldb) s
Process 82271 stopped
* thread #1, name = 'make', stop reason = step in
    frame #0: 0x0000000000255e64 make`_set_tp(tp=0x00000008002f7830) at
_set_tp.c:40
   37   _set_tp(void *tp)
   38   {
   39
-> 40           amd64_set_fsbase(tp);
   41   }
(lldb) s
Process 82271 stopped
* thread #1, name = 'make', stop reason = step in
    frame #0: 0x0000000000256580
make`amd64_set_fsbase(addr=0x00000008002f7830) at amd64_set_fsbase.c:43
   40   #include <machine/specialreg.h>
   41   #include <machine/sysarch.h>
   42   #include <x86/ifunc.h>
-> 43   #include "libc_private.h"
   44
   45   static int
   46   amd64_set_fsbase_cpu(void *addr)
(lldb)

r340173:
Process 22663 stopped
* thread #1, name = 'make', stop reason = step over
    frame #0: 0x0000000000247c96 make`_init_tls at tls.c:471
   468          }
   469          tls = _rtld_allocate_tls(NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN);
   470
-> 471          _set_tp(tls);
   472  #endif
   473  }
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = step over
    frame #0: 0x0000000000252eb0 make`_set_tp(tp=0x00000008002ed830) at
_set_tp.c:38
   35
   36   void
   37   _set_tp(void *tp)
-> 38   {
   39
   40           amd64_set_fsbase(tp);
   41   }
(lldb) s
Process 22663 stopped
* thread #1, name = 'make', stop reason = step in
    frame #0: 0x0000000000252eb4 make`_set_tp(tp=0x00000008002ed830) at
_set_tp.c:40
   37   _set_tp(void *tp)
   38   {
   39
-> 40           amd64_set_fsbase(tp);
   41   }
(lldb) s
Process 22663 stopped
* thread #1, name = 'make', stop reason = step in
    frame #0: 0x0000000000252eb5 make`_set_tp(tp=0x00000008002ed830) at
_set_tp.c:40
   37   _set_tp(void *tp)
   38   {
   39
-> 40           amd64_set_fsbase(tp);
   41   }
(lldb) s
Process 22663 stopped
* thread #1, name = 'make', stop reason = step in
    frame #0: 0x00000000002ebdb0 make
->  0x2ebdb0: movq   0x3ce9(%rip), %r11
    0x2ebdb7: callq  0x2ebda0                  ; _fini
    0x2ebdbc: jmp    0x2ebd92                  ; _init + 6
    0x2ebdc1: pushq  $0x0
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = instruction step over
    frame #0: 0x00000000002ebdb7 make
->  0x2ebdb7: callq  0x2ebda0                  ; _fini
    0x2ebdbc: jmp    0x2ebd92                  ; _init + 6
    0x2ebdc1: pushq  $0x0
    0x2ebdc6: jmp    0x2ebd80                  ; __do_global_ctors_aux + 48
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = instruction step over
    frame #0: 0x00000000002ebda0 make`_fini at crti.S:41
   38           .globl  _fini
   39           .type   _fini,@function
   40   _fini:
-> 41           subq    $8,%rsp
   42
   43           .section .note.GNU-stack,"",%progbits
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = step over
    frame #0: 0x00000000002ebda4 make`_fini + 4
make`_fini:
->  0x2ebda4 <+4>:  callq  0x226310                  ; __do_global_dtors_aux
    0x2ebda9 <+9>:  addq   $0x8, %rsp
    0x2ebdad <+13>: retq
    0x2ebdae:       addb   %al, (%rax)
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = instruction step over
    frame #0: 0x00000000002ebda9 make`_fini at crtn.S:34
   31           ret
   32
   33           .section .fini,"ax",@progbits
-> 34           addq    $8,%rsp
   35           ret
   36
   37           .section .note.GNU-stack,"",%progbits
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = step over
    frame #0: 0x00000000002ebdad make`_fini at crtn.S:35
   32
   33           .section .fini,"ax",@progbits
   34           addq    $8,%rsp
-> 35           ret
   36
   37           .section .note.GNU-stack,"",%progbits
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = step over
    frame #0: 0x00000000002ebdbc make
->  0x2ebdbc: jmp    0x2ebd92                  ; _init + 6
    0x2ebdc1: pushq  $0x0
    0x2ebdc6: jmp    0x2ebd80                  ; __do_global_ctors_aux + 48
    0x2ebdcb: int3
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = instruction step over
    frame #0: 0x00000000002ebd92 make`_init + 6
make`_init:
->  0x2ebd92 <+6>: movsl  (%rsi), %es:(%rdi)
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = signal SIGSEGV: invalid
address (fault address: 0x0)
    frame #0: 0x00000000002ebd92 make`_init + 6
make`_init:
->  0x2ebd92 <+6>: movsl  (%rsi), %es:(%rdi)
(lldb) n
Process 22663 exited with status = -1 (0xffffffff)
(lldb)

--
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)




signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Konstantin Belousov
On Mon, Nov 05, 2018 at 09:10:13PM -0500, Charlie Li wrote:

> On 03/11/2018 19:45, Konstantin Belousov wrote:
> > Or rather, it is a middle of the valid instruction.
> > Next frame looks like it is process_irelocs(), if trusting the line
> > numbers.  So most likely it is something related to calling wrong
> > relocator function, if anything.
> >
> > Perhaps you could try to trace the things manually, doing
> > single-stepping of the startup code in debugger. There should be very
> > modest amount of the irelocs, perhaps only one, and see where things go
> > off the way.
> >
> After a few more complete buildworlds, including one with all
> bootstrapping enabled, this doesn't look compiler-specific. Static
> binaries built with the in-tree base LLVM (6.0.1) also crash.
For you, but not for me.

>
> I stepped through bmake with base lldb, comparing the working copy in my
> system from circa r339990 with r340173 built with bootstrapped
> toolchain. Only the differing parts are shown for conciseness.
>
> Circa r339990:
> Process 82271 stopped
> * thread #1, name = 'make', stop reason = step over
>     frame #0: 0x000000000024ab06 make`_init_tls at tls.c:471
>    468          }
>    469          tls = _rtld_allocate_tls(NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN);
>    470
> -> 471          _set_tp(tls);
>    472  #endif
>    473  }
> (lldb) n
> Process 82271 stopped
> * thread #1, name = 'make', stop reason = step over
>     frame #0: 0x0000000000255e60 make`_set_tp(tp=0x00000008002f7830) at
> _set_tp.c:38
>    35
>    36   void
>    37   _set_tp(void *tp)
> -> 38   {
>    39
>    40           amd64_set_fsbase(tp);
>    41   }
> (lldb) s
> Process 82271 stopped
> * thread #1, name = 'make', stop reason = step in
>     frame #0: 0x0000000000255e64 make`_set_tp(tp=0x00000008002f7830) at
> _set_tp.c:40
>    37   _set_tp(void *tp)
>    38   {
>    39
> -> 40           amd64_set_fsbase(tp);
>    41   }
> (lldb) s
> Process 82271 stopped
> * thread #1, name = 'make', stop reason = step in
>     frame #0: 0x0000000000256580
> make`amd64_set_fsbase(addr=0x00000008002f7830) at amd64_set_fsbase.c:43
>    40   #include <machine/specialreg.h>
>    41   #include <machine/sysarch.h>
>    42   #include <x86/ifunc.h>
> -> 43   #include "libc_private.h"
>    44
>    45   static int
>    46   amd64_set_fsbase_cpu(void *addr)
> (lldb)
>
> r340173:
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step over
>     frame #0: 0x0000000000247c96 make`_init_tls at tls.c:471
>    468          }
>    469          tls = _rtld_allocate_tls(NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN);
>    470
> -> 471          _set_tp(tls);
>    472  #endif
>    473  }
> (lldb) n
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step over
>     frame #0: 0x0000000000252eb0 make`_set_tp(tp=0x00000008002ed830) at
> _set_tp.c:38
>    35
>    36   void
>    37   _set_tp(void *tp)
> -> 38   {
>    39
>    40           amd64_set_fsbase(tp);
>    41   }
> (lldb) s
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step in
>     frame #0: 0x0000000000252eb4 make`_set_tp(tp=0x00000008002ed830) at
> _set_tp.c:40
>    37   _set_tp(void *tp)
>    38   {
>    39
> -> 40           amd64_set_fsbase(tp);
>    41   }
> (lldb) s
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step in
>     frame #0: 0x0000000000252eb5 make`_set_tp(tp=0x00000008002ed830) at
> _set_tp.c:40
>    37   _set_tp(void *tp)
>    38   {
>    39
> -> 40           amd64_set_fsbase(tp);
>    41   }
> (lldb) s
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = step in
>     frame #0: 0x00000000002ebdb0 make
> ->  0x2ebdb0: movq   0x3ce9(%rip), %r11
>     0x2ebdb7: callq  0x2ebda0                  ; _fini
>     0x2ebdbc: jmp    0x2ebd92                  ; _init + 6
>     0x2ebdc1: pushq  $0x0
> (lldb) n
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = instruction step over
>     frame #0: 0x00000000002ebdb7 make
> ->  0x2ebdb7: callq  0x2ebda0                  ; _fini
I guess this is where things go off for you, but I may be wrong.
After ifuncification, 'amd64_set_fsbase()' line should be represented
by the asm as either
        call <somewhere in plt>
and the place in plt is just
        jmp *(rip-based offset to GOT)(%rip)
In fact the call to amd64_set_fsbase() in the tail-call position, so
the first call is jmp.

For me, everything works.  If for you it does not you should look at the
instructions and see which values went off.  You completely omitted that
details from your trace, so I cannot even guess which part was corrupted.
Again, for me it works with the in-tree toolchain, so I am quite sure that
you have trouble with the toolchain.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r339898 - head/lib/libc/amd64/sys

Charlie Li
On 05/11/2018 21:51, Konstantin Belousov wrote:
> For you, but not for me.
>
Turns out I omitted the fact that I have WITH_RETPOLINE enabled, which
caused all this. emaste@ reported in PR 233336 and committed r340650.

--
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)


signature.asc (849 bytes) Download Attachment