Re: unbound error: Undefined symbol "sldns_key_EVP_load_gost_id"
On Sun, 04 Nov 2018 20:07:39 +0100, "Michael W. Lucas" wrote: > > Hi, > > Haven't seen this reported yet, so here it is. Found on last week's > world, rebuild last night and still there. Worth filing a bug? > > storm~;uname -a > FreeBSD storm 13.0-CURRENT FreeBSD 13.0-CURRENT r339863 GENERIC amd64 > > Trying to run unbound, and: > > storm~;sudo unbound -dd > ld-elf.so.1: /usr/sbin/unbound: Undefined symbol "sldns_key_EVP_load_gost_id" > > The voices in my head mutter it's something about OpenSSL. But they're > usually wrong. > > Here's my unbound.conf, just in case: > > --- > root-hints: "named.cache" > access-control: 0.0.0.0/0 allow > --- You are obviously running an old unbound binary. Did you forget to run 'make delete-old(-libs)'? Try /usr/sbin/local-unbound. --- r333573 | des | 2018-05-12 19:10:36 +0200 (Sat, 12 May 2018) | 4 lines Rename all Unbound binaries and man pages from unbound* to local-unbound*. PR: 222902 --- -- Herbert ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD/powerpc64 (POWER9) with ZFS on /
On Mon, Nov 5, 2018, 3:45 AM Piotr Kubaj via freebsd-ppc > ZFS is by default not available for partitioning in bsdinstall. We can, > however, use manual partitioning in shell to make ZFS partitions. > > But what if we want to do ZFS on /? This is currently not supported > out-of-the-box. The reason is that Petitboot, used on POWER9 to boot kernel, > doesn't support loading modules (at least when booting FreeBSD). ZFS is by > default distributed only as a module, to overcome licensing issues. > > There are two ways to boot ZFS on root with Petitboot: > 1. We can use initramfs, which will load necessary modules. It's said to be > supported on FreeBSD/powerpc64, but no one knows how to create one for > FreeBSD :) > 2. We can actually compile a custom kernel with ZFS in it (not as a module). > This the approach that I use. Unfortunately, I can't redistribute this > kernel, because of ZFS's license. I created a custom installation iso, which > uses my kernel with ZFS included. > > Here are the steps to do it (on an installed powerpc64 system, but should be > possible on other architectures after redefining TARGET and TARGET_ARCH): > 1. cd /usr/src/sys/powerpc/conf > 2. cat << EOF > ZFS > include GENERIC64 > options ZFS > EOF > 3. cd ../../../ > 3. make buildworld buildkernel KERNCONF=ZFS > 4. cd release > 5. make release > > When it's done, there will be iso files in > /usr/obj/usr/src/powerpc.powerpc64/release. > > You can use it to install ZFS on root. > > Note that you need a FAT32 partition to mount on /boot. > This partition needs to have /boot/etc/kboot.conf file, with a line like: > FreeBSD='/kernel/kernel kernelname=/boot/kernel/kernel > vfs.root.mountfrom=zfs:zroot/ROOT/default' > > You also need the appriopriate /etc/fstab: > /dev/nda0p1 /boot msdosfs rw 2 2 > > Other than that, howto at > https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot#Create_Partitions (from point > 2., omit 1.) is totally ok to follow. > > Thanks to mmacy for informing me about this little trick with including ZFS > to kernel. > > -- > _ > / It has been said that man is a rational \ > | animal. All my life I have been | > | searching for evidence which could | > | support this. | > | | > \ -- Bertrand Russell / > - > \ ^__^ > \ (oo)\___ > (__)\ )\/\ > ||w | > || || I don't think there are any license issues distributing a FreeBSD kernel with ZFS statically linked like there are with Linux. For a long time it wasn't supported and ZFS will probably never be in GENERIC but a custom kernel with ZFS built in should be freely redistributable. I don't claim to be an expert on the license issues so if someone else has better information feel free correct me. -Bill Sorenson ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD/powerpc64 (POWER9) with ZFS on /
ZFS is by default not available for partitioning in bsdinstall. We can, however, use manual partitioning in shell to make ZFS partitions. But what if we want to do ZFS on /? This is currently not supported out-of-the-box. The reason is that Petitboot, used on POWER9 to boot kernel, doesn't support loading modules (at least when booting FreeBSD). ZFS is by default distributed only as a module, to overcome licensing issues. There are two ways to boot ZFS on root with Petitboot: 1. We can use initramfs, which will load necessary modules. It's said to be supported on FreeBSD/powerpc64, but no one knows how to create one for FreeBSD :) 2. We can actually compile a custom kernel with ZFS in it (not as a module). This the approach that I use. Unfortunately, I can't redistribute this kernel, because of ZFS's license. I created a custom installation iso, which uses my kernel with ZFS included. Here are the steps to do it (on an installed powerpc64 system, but should be possible on other architectures after redefining TARGET and TARGET_ARCH): 1. cd /usr/src/sys/powerpc/conf 2. cat << EOF > ZFS include GENERIC64 options ZFS EOF 3. cd ../../../ 3. make buildworld buildkernel KERNCONF=ZFS 4. cd release 5. make release When it's done, there will be iso files in /usr/obj/usr/src/powerpc.powerpc64/release. You can use it to install ZFS on root. Note that you need a FAT32 partition to mount on /boot. This partition needs to have /boot/etc/kboot.conf file, with a line like: FreeBSD='/kernel/kernel kernelname=/boot/kernel/kernel vfs.root.mountfrom=zfs:zroot/ROOT/default' You also need the appriopriate /etc/fstab: /dev/nda0p1 /boot msdosfs rw 2 2 Other than that, howto at https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot#Create_Partitions (from point 2., omit 1.) is totally ok to follow. Thanks to mmacy for informing me about this little trick with including ZFS to kernel. -- _ / It has been said that man is a rational \ | animal. All my life I have been | | searching for evidence which could | | support this. | | | \ -- Bertrand Russell / - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: PGP signature
Re: drm changes and updating to 12.0
On Sun, Nov 4, 2018 at 10:52 PM Kevin Oberman wrote: > On Sun, Nov 4, 2018 at 12:15 PM Niclas Zeising > wrote: > > > On 11/4/18 8:29 PM, Robert Huff wrote: > > > > > > I have a set of older machines (e.g. AMD Phenom II, Radeon HD3300 > > > gpu) which will be updated from 11. to 12.0 once 12 is out > > > and the initial round of bugs are squashed. > > > One system is being done now, to allow time to catch any major > > > problems and then plan the update process. > > > Looking at src/UPDATING, the only thing I don't understand is the > > > whole drm-kmod change. Is there an authoritative write-up on what's > > > going on, how to choose the right drivers for my hardware, and how to > > > do this from source without forcing a fresh install? > > > > > > > We are working on better documentation for this, but the main highlights > > are: In most cases graphics/drm-kmod should suffice, especially on > > somewhat modern hardware. You can also install any of the drm-*-kmod > > ports directly, if you want a specific version. In general graphics > > hardware older than from 2013 requires drm-legacy-kmod instead. > > drm-kmod will also install drm-legacy-kmod on i386. > > > > The same drivers in drm-legacy-kmod is also available in base on 12, so > > you can use the base drivers. This is deprecated however, and not the > > case for 13-CURRENT. > > > > You can install the drivers either from pkg, if you are using the > > GENERIC kernel, or build from ports if you have a customized kernel or > > if you are tracking for instance 12-STABLE or 13-CURRENT. > > > > If you are using drm-legacy-kmod or the base driver with AMD graphics > > cards you might also need to install xf86-video-ati-legacy rather than > > xf86-video-ati. > > > > Regards > > -- > > Niclas Zeising > > > I'm curious where 2013 comes from. I know that Intel Sandy Bridge graphics > is supported with VAAPI acceleration by drm-stable-kmod, since it i working > on the system I am using to send this message. I bought it in 2011, the > year Sandy Bridge was introduced to production products. > > In general, when in doubt, I'd try drm-stable-kmod for questionable devices > and fall back to drm-legacy-kmod it it fails. If y0ou use ports, I'd build > both paskages to make it easier to recover if drm-stable-kmod fails. Also, > be sure to make the proper adjustments to /etc/rc.conf as per the package > message. > 2013 is "five year old hardware or newer". It's a number I pulled out of the air when trying to nail down the group in describing who should use what. Giving code names would also work. Sandy Bridge and newer, though, is confusing to people. I'd use 2011 as the release date for Sandy Bridge, but then what about the AMD other GPUs? If there's a better way to message what's supported, I'm all ears. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm changes and updating to 12.0
Warner Losh writes: > I'm curious where 2013 comes from. I know that Intel Sandy Bridge > graphics > is supported with VAAPI acceleration by drm-stable-kmod, since it i > working > on the system I am using to send this message. I bought it in 2011, the > year Sandy Bridge was introduced to production products. > > 2013 is "five year old hardware or newer". It's a number I pulled out of the > air when trying to nail down the group in describing who should use what. > Giving code names would also work. Sandy Bridge and newer, though, is > confusing > to people. I'd use 2011 as the release date for Sandy Bridge, but then what > about the AMD other GPUs? > > If there's a better way to message what's supported, I'm all ears. Lacking a better plan: is there a list of which card/gpu is currently known to work with which drm(-kmod) version, perhaps gathered from those involved with development? (Is this based on work from Linux? If so, do they have a list?) Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm changes and updating to 12.0
On Mon, Nov 5, 2018 at 10:23 AM Robert Huff wrote: > > Warner Losh writes: > > > I'm curious where 2013 comes from. I know that Intel Sandy Bridge > graphics > > is supported with VAAPI acceleration by drm-stable-kmod, since it i > working > > on the system I am using to send this message. I bought it in 2011, > the > > year Sandy Bridge was introduced to production products. > > > > 2013 is "five year old hardware or newer". It's a number I pulled out > of the > > air when trying to nail down the group in describing who should use > what. > > Giving code names would also work. Sandy Bridge and newer, though, is > confusing > > to people. I'd use 2011 as the release date for Sandy Bridge, but then > what > > about the AMD other GPUs? > > > > If there's a better way to message what's supported, I'm all ears. > > Lacking a better plan: is there a list of which card/gpu is > currently known to work with which drm(-kmod) version, perhaps > gathered from those involved with development? (Is this based on work > from Linux? If so, do they have a list?) > I believe that list would be hundreds of entries long. That's not exactly useful to put in release notes except as an appendix. I agree having the list somewhere would be good, but having it in a short statement wouldn't be possible. Even just summarizing the major generations would be too long a list, I'd think. Also, we have no clue which GPUs actually work on FreeBSD and which ones should work. With so many graphics GPUs out there, it's impossible for us to test and keep current on all the reports for all of them. There's no infrastructure to do that that would scale to the size of this problem. While most of them should work, we still need fallback instructions for those people who tried it and it didn't work. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm changes and updating to 12.0
On Mon, Nov 5, 2018 at 5:27 PM Robert Huff wrote: > > Warner Losh writes: > > > I'm curious where 2013 comes from. I know that Intel Sandy Bridge > graphics > > is supported with VAAPI acceleration by drm-stable-kmod, since it i > working > > on the system I am using to send this message. I bought it in 2011, > the > > year Sandy Bridge was introduced to production products. > > > > 2013 is "five year old hardware or newer". It's a number I pulled out > of the > > air when trying to nail down the group in describing who should use > what. > > Giving code names would also work. Sandy Bridge and newer, though, is > confusing > > to people. I'd use 2011 as the release date for Sandy Bridge, but then > what > > about the AMD other GPUs? > > > > If there's a better way to message what's supported, I'm all ears. > > Lacking a better plan: is there a list of which card/gpu is > currently known to work with which drm(-kmod) version, perhaps > gathered from those involved with development? (Is this based on work > from Linux? If so, do they have a list?) > Hi Updating the wiki graphics pages is long overdue and we hope to have it refreshed before the 12.0 release. Everything will be explained there in detail together with some compatibility matrix. This has probably been said many times on the mailing list but I feel obligated to try to inform the best I can until we have updated the wiki. The short version is that drm2 in base (/sys/dev/drm2/) have support for hw up to 2013 (maybe 2014), that's why drm-legacy-kmod is said to support hw up to that year. Now, the linuxkpi based ones, drm-stable-kmod and drm-devel-kmod (I'm not including drm-next-kmod because that will go away), potentially could work on hw older than 2013. Initially they didn't but they have been patched to potentially work on same hw as base drm2 but this is barely tested yet. Recently, drm-devel-kmod was patched to work on i386 but this is also not fully tested yet. So, theoretically, if you're running current, drm-devel-kmod could run your 10 years old 32 bit computer's gpu but it's too early to make any guarantees. Please feel free to test. Usually the meta-port, drm-kmod, will choose the best (safest bet) for your system. Which Linux version is tracked is listed in the port info. drm-stable-kmod is currently at Linux 4.9 drm-devel-kmod is currently at Linux 4.16 The best way is lookup what is supported by the Linux version (if anyone know a good site, please share the link). If the hw is supported there, and it's driven by i915, amdgpu or radeon, it should work on FreeBSD as well. If you have any of the _really_ old cards supported by drm1 (what's in /sys/dev/drm/), you'll always need drm-legacy-kmod. We know this transition has been messy and confusing but we're working hard to improve this. /Johannes > > > Respectfully, > > > Robert Huff > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm changes and updating to 12.0
On Mon, Nov 05, 2018 at 06:56:57PM +, Johannes Lundberg wrote: > The short version is that drm2 in base (/sys/dev/drm2/) have support for hw > up to 2013 (maybe 2014), that's why drm-legacy-kmod is said to support hw > up to that year. drm2 in base supports everything from gen3 to gen6 and did some entrance into gen7 for Intel. Practically it means that the list is G33 chipset graphics (gen3) G45 (gen4), both cover everything that has chipset graphics for Core2, core i5 6xx AKA desktop Westmere (gen5) Sandy/Ivy Bridge (gen6) unstable Haswell (gen7) (I dropped it when upstream had still major stability issues) Broadwell does not work at all, and I am not sure about Atoms even when the same generation of graphics was used by the north bridge. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm changes and updating to 12.0
On Mon, Nov 5, 2018 at 7:00 PM Johannes Lundberg wrote: > Which Linux version is tracked is listed in the port info. > drm-stable-kmod is currently at Linux 4.9 > drm-devel-kmod is currently at Linux 4.16 This is very useful to know. I can't find the Linux kernel version in drm-legacy-kmod metadata. Is it a mix of different kernel releases? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm changes and updating to 12.0
On Mon, Nov 5, 2018 at 10:05 PM Carsten Mattner wrote: > On Mon, Nov 5, 2018 at 7:00 PM Johannes Lundberg > wrote: > > > Which Linux version is tracked is listed in the port info. > > drm-stable-kmod is currently at Linux 4.9 > > drm-devel-kmod is currently at Linux 4.16 > > This is very useful to know. I can't find the Linux kernel version in > drm-legacy-kmod metadata. Is it a mix of different kernel releases? > According to the old, abandoned wiki page it seems to be Linux 3.8. (zeising: we should add this info to drm-legacy) https://wiki.freebsd.org/Graphics That was developed by the previous graphics team with all different members (for the kernel drivers) so to be honest I don't know much details about the old drm code. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
svn commit: r339898 - head/lib/libc/amd64/sys
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: 0x0024ab06 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: 0x00255e60 make`_set_tp(tp=0x0008002f7830) 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: 0x00255e64 make`_set_tp(tp=0x0008002f7830) 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: 0x00256580
make`amd64_set_fsbase(addr=0x0008002f7830) at amd64_set_fsbase.c:43
40 #include
41 #include
42 #include
-> 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: 0x00247c96 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: 0x00252eb0 make`_set_tp(tp=0x0008002ed830) 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: 0x00252eb4 make`_set_tp(tp=0x0008002ed830) 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: 0x00252eb5 make`_set_tp(tp=0x0008002ed830) 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: 0x002ebdb0 make
-> 0x2ebdb0: movq 0x3ce9(%rip), %r11
0x2ebdb7: callq 0x2ebda0 ; _fini
0x2ebdbc: jmp0x2ebd92 ; _init + 6
0x2ebdc1: pushq $0x0
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = instruction step over
frame #0: 0x002ebdb7 make
-> 0x2ebdb7: callq 0x2ebda0 ; _fini
0x2ebdbc: jmp0x2ebd92 ; _init + 6
0x2ebdc1: pushq $0x0
0x2ebdc6: jmp0x2ebd80 ; __do_global_ctors_aux + 48
(lldb) n
Process 22663 stopped
* thread #1, name = 'make', stop reason = instruction step over
frame #0: 0x002ebda0 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: 0x002ebda4 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: 0x002ebda9 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: 0x002ebdad make`_fini at crtn.S:35
32
33 .section .fini,"ax",@progbits
Re: svn commit: r339898 - head/lib/libc/amd64/sys
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: 0x0024ab06 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: 0x00255e60 make`_set_tp(tp=0x0008002f7830) 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: 0x00255e64 make`_set_tp(tp=0x0008002f7830) 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: 0x00256580
> make`amd64_set_fsbase(addr=0x0008002f7830) at amd64_set_fsbase.c:43
>40 #include
>41 #include
>42 #include
> -> 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: 0x00247c96 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: 0x00252eb0 make`_set_tp(tp=0x0008002ed830) 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: 0x00252eb4 make`_set_tp(tp=0x0008002ed830) 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: 0x00252eb5 make`_set_tp(tp=0x0008002ed830) 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: 0x002ebdb0 make
> -> 0x2ebdb0: movq 0x3ce9(%rip), %r11
> 0x2ebdb7: callq 0x2ebda0 ; _fini
> 0x2ebdbc: jmp0x2ebd92 ; _init + 6
> 0x2ebdc1: pushq $0x0
> (lldb) n
> Process 22663 stopped
> * thread #1, name = 'make', stop reason = instruction step over
> frame #0: 0x002ebdb7 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
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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
