From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4705 invoked by alias); 14 Dec 2010 17:05:14 -0000 Received: (qmail 4694 invoked by uid 22791); 14 Dec 2010 17:05:11 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 17:05:05 +0000 Received: (qmail 27387 invoked from network); 14 Dec 2010 17:05:03 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Dec 2010 17:05:03 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1PSYJB-0002nD-Kf; Tue, 14 Dec 2010 17:05:01 +0000 Date: Tue, 14 Dec 2010 17:56:00 -0000 From: "Joseph S. Myers" To: "Maciej W. Rozycki" cc: Richard Sandiford , Ilie Garbacea , binutils@sourceware.org, Chao-ying Fu , Rich Fuhler , David Lau , Kevin Mills , Catherine Moore , Nathan Sidwell , Nathan Froyd Subject: Re: [PATCH] MIPS: microMIPS ASE support In-Reply-To: Message-ID: References: <87y6fa9u3t.fsf@firetop.home> <876302kqvu.fsf@firetop.home> <871v5n9m7e.fsf@firetop.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00466.txt.bz2 On Tue, 14 Dec 2010, Maciej W. Rozycki wrote: > > > /* Calls from 16-bit code to 32-bit code and vice versa require the > > > - mode change. */ > > > - *cross_mode_jump_p = !info->relocatable > > > - && ((r_type == R_MIPS16_26 && !target_is_16_bit_code_p) > > > - || ((r_type == R_MIPS_26 || r_type == R_MIPS_JALR) > > > - && target_is_16_bit_code_p)); > > > + mode change. This is not required for calls to undefined weak > > > + symbols, which should never be executed at runtime. */ > > > > But why do we need to go out of our way to check for them? I'm sure > > there's a good reason, but the comment doesn't give much clue what it is. > > Undefined weak symbols are, well, undefined, so they have resolved to nil > and are meant never to be jumped to, so we don't want to error out on them > just because they do not have the ISA bit set and a JALX therefore > required could not be used for some reason, like the invocation being a > sibling call or because it would not satisfy the fixed delay slot > dependency. > > So we decide never to make a cross-mode jump in this situation and leave > the original jump instruction (i.e. JAL, JALS or JR) in place. If the > instruction is indeed reached, then 1 will be written to the PC rather > than 0 that would "canonically" be required here, but the outcome will be > the same (assuming the zeroth page is unmapped), i.e. a segfault will > happen. > > Joseph, I reckon you were involved with this piece -- did I get all the > context right here? Yes. A call to an undefined weak function is equally valid at compile and link time and invalid at execution time if executed whether or not the code is compiled in such a way as to support cross-mode jumps. Such a call is a call to an undefined function, never a call to an other-mode function, and so the linker should never give errors for cases such as JALS where it cannot convert to a cross-mode jump. The original observed problem case was statically linking sln with a call to __nptl_deallocate_tsd that never gets executed in single-threaded programs. -- Joseph S. Myers joseph@codesourcery.com