From owner-freebsd-arm@FreeBSD.ORG Sun Jan 18 06:41:48 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D01CFAC for ; Sun, 18 Jan 2015 06:41:48 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EAB81F6 for ; Sun, 18 Jan 2015 06:41:47 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 64F896811E for ; Sun, 18 Jan 2015 15:41:45 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 3741968118 for ; Sun, 18 Jan 2015 15:41:45 +0900 (JST) Message-ID: <8938766D727E4CD587AB34DB32A67916@ad.peach.ne.jp> From: "Daisuke Aoyama" To: Subject: C++ exception of RPi Date: Sun, 18 Jan 2015 15:41:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 06:41:48 -0000 Hi, It seems SDHCI_QUIRK_NO_HISPD_BIT is commited. http://svnweb.freebsd.org/base?view=revision&revision=277307 I write other problem in src-r277169-20150114.patch here. Current /lib/libcxxrt.so.1 can't handle exception table by clang (at leaset 3.5) clang++ generate EH like this: ---------------------------------------------------------------------- .handlerdata .align 2 GCC_except_table0: .Lexception0: .byte 255 @ @LPStart Encoding = omit .byte 0 @ @TType Encoding = absptr .byte 73 @ @TType base offset .byte 3 @ Call site Encoding = udata4 .byte 65 @ Call site table length .Lset0 = .Leh_func_begin0-.Leh_func_begin0 @ >> Call Site 1 << .long .Lset0 .Lset1 = .Ltmp0-.Leh_func_begin0 @ Call between .Leh_func_begin0 and .Ltmp0 .long .Lset1 .long 0 @ has no landing pad .byte 0 @ On action: cleanup .Lset2 = .Ltmp0-.Leh_func_begin0 @ >> Call Site 2 << .long .Lset2 .Lset3 = .Ltmp1-.Ltmp0 @ Call between .Ltmp0 and .Ltmp1 .long .Lset3 .Lset4 = .Ltmp2-.Leh_func_begin0 @ jumps to .Ltmp2 .long .Lset4 .byte 1 @ On action: 1 .Lset5 = .Ltmp1-.Leh_func_begin0 @ >> Call Site 3 << .long .Lset5 .Lset6 = .Ltmp3-.Ltmp1 @ Call between .Ltmp1 and .Ltmp3 .long .Lset6 .long 0 @ has no landing pad .byte 0 @ On action: cleanup .Lset7 = .Ltmp3-.Leh_func_begin0 @ >> Call Site 4 << .long .Lset7 ---------------------------------------------------------------------- You can see udata4 of .Lset0 is located at offset 5 from .Lexception0. (.Lset2 is offset 18, .Lset5 is offset 31) This data is scaned by dwarf_eh_find_callsite() in /usr/src/contrib/libcxxrt/dwarf_eh.h: 418 while (callsite_table <= lsda->action_table) 419 { 420 // Once again, the layout deviates from the spec. 421 uint64_t call_site_start, call_site_size, landing_pad, action; 422 call_site_start = read_value(lsda->callsite_encoding, &callsite_table); 423 call_site_size = read_value(lsda->callsite_encoding, &callsite_table); Also, read_value is: 218 static uint64_t read_value(char encoding, dw_eh_ptr_t *data) 219 { 220 enum dwarf_data_encoding type = get_encoding(encoding); 221 uint64_t v; 222 switch (type) 223 { 224 // Read fixed-length types 225 #define READ(dwarf, type) \ 226 case dwarf:\ 227 v = static_cast(*reinterpret_cast(*data));\ 228 *data += sizeof(type);\ 229 break; 230 READ(DW_EH_PE_udata2, uint16_t) 231 READ(DW_EH_PE_udata4, uint32_t) 232 READ(DW_EH_PE_udata8, uint64_t) 233 READ(DW_EH_PE_sdata2, int16_t) 234 READ(DW_EH_PE_sdata4, int32_t) 235 READ(DW_EH_PE_sdata8, int64_t) 236 READ(DW_EH_PE_absptr, intptr_t) 237 #undef READ 238 // Read variable-length types 239 case DW_EH_PE_sleb128: 240 v = read_sleb128(data); 241 break; 242 case DW_EH_PE_uleb128: 243 v = read_uleb128(data); 244 break; 245 default: abort(); 246 } 247 248 return v; 249 } This reinterpret_cast code of data is probably generated like: ldr r0, [r0] But r0 is not aligned! As a result, "return v" is not expected value on RPi. (usually, it shows v = *((*data) & ~0x3)) To avoid unaligned access, I use byte access in contrib/libcxxrt/dwarf_eh.h. This solve unwind code in RPi. ---------------------------------------------------------------------- I don't know other CPU. Please check your CPU. Regards, -- Daisuke Aoyama