HEADS UP: clang/llvm/lldb/compiler-rt 3.8.0 imported

Nikolai Lifanov lifanov at mail.lifanov.com
Sun Mar 6 14:40:04 UTC 2016


On 2016-03-06 09:28, Larry Rosenman wrote:
> On 2016-03-06 08:20, Larry Rosenman wrote:
>> On Sun, Mar 06, 2016 at 03:15:10PM +0100, Dimitry Andric wrote:
>>> On 06 Mar 2016, at 06:20, Larry Rosenman <ler at lerctr.org> wrote:
>>> >
>>> > On 2016-03-05 18:46, Dimitry Andric wrote:
>>> >> On 06 Mar 2016, at 00:30, Dimitry Andric <dim at FreeBSD.org> wrote:
>>> >>> On 05 Mar 2016, at 22:32, Dimitry Andric <dim at FreeBSD.org> wrote:
>>> >>>> I imported the (tentative) 3.8.0 release of clang, llvm, lldb and
>>> >>>> compiler-rt into head, in r296417.  The upstream release is going to be
>>> >>>> very soon now, but I do not expect any changes anymore.
>>> >>>> This was tested with make universe, and a few exp-runs, but there is
>>> >>>> always a chance that you might run into something unexpected, either
>>> >>>> with the base system or ports.  In such cases, please file bugs, and
>>> >>>> make sure you note somewhere in the description that it is related to
>>> >>>> this import.
>>> >>> Please hold off upgrading for now, if you are on amd64, and loading the
>>> >>> aesni.ko module.  It appears that loading this module can cause the
>>> >>> kernel ELF linker to panic, but it is not yet clear why.  This is being
>>> >>> tracked in PR207729 [1].
>>> >> It should be safe again after r296419.  Thanks to Kostik Belousov for
>>> >> the quick fix.  (Clang 3.8.0 generates a different type for unwind
>>> >> sections on amd64, and this was unexpected in the kernel linker.)
>>> >> -Dimitry
>>> >> [1] https://svnweb.freebsd.org/changeset/base/296419
>>> > I'm getting a crash at startup (mi_startup) with a clang 3.8.0 kernel.
>>> >
>>> > Picture at:
>>> > http://www.lerctr.org/~ler/FreeBSD/20160305_225532.jpg
>>> 
>>> It's pretty hard to make out, but it looks like it is panic'ing in
>>> link_elf_reloc_local().  That should have been fixed with r296419, 
>>> but
>>> maybe there is yet another edge case that wasn't fixed.  Do you have 
>>> a
>>> crash dump and/or a backtrace?  Which modules are you preloading?
>>> 
>>> -Dimitry
>>> 
>> 
>> loader,conf:
>> 
>> kern.msgbuf_clear="1"
>> kern.geom.label.disk_ident.enable="0"
>> kern.geom.label.gptid.enable="0"
>> zfs_load="YES"
>> ichsmb_load="YES"
>> hwpmc_load="YES"
>> aesni_load="YES"
>> cryptodev_load="YES"
>> dtraceall_load="YES"
>> cpuctl_load="YES"
>> cuse_load="YES"
>> coretemp_load="YES"
>> #hw.usb.quirk.0="0x0bda 0x0129 0x3960 0x3960
>> UQ_MSC_FORCE_WIRE_BBB,UQ_MSC_FORCE_PROTO_SCSI"
>> #hw.usb.umass.debug="-1"
>> 
>> I'll see if I can get a better  pic with a backtrace.  This crash is
>> WAY early, so no dump :(
>> 
>> 
>> 
>> acpi_dsdt_load="YES"		# DSDT Overriding
>> acpi_dsdt_name="/boot/dsdt.aml"
>> #hw.psm.synaptics_support="1"
> 
> new pic: http://www.lerctr.org/~ler/FreeBSD/20160306_082426.jpg

I loaded everything in this list other than acpi_dsdt override.

- Nikolai Lifanov


More information about the freebsd-current mailing list