From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21543 invoked by alias); 14 Dec 2010 13:30:19 -0000 Received: (qmail 21531 invoked by uid 22791); 14 Dec 2010 13:30:17 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_XF X-Spam-Check-By: sourceware.org Received: from mail-fx0-f42.google.com (HELO mail-fx0-f42.google.com) (209.85.161.42) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 14 Dec 2010 13:30:12 +0000 Received: by fxm11 with SMTP id 11so657805fxm.15 for ; Tue, 14 Dec 2010 05:30:09 -0800 (PST) Received: by 10.223.73.202 with SMTP id r10mr1980435faj.133.1292333409408; Tue, 14 Dec 2010 05:30:09 -0800 (PST) Received: from richards-desktop-2.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice3n2.emea.ibm.com [195.212.29.84]) by mx.google.com with ESMTPS id f24sm2125307fak.24.2010.12.14.05.30.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Dec 2010 05:30:08 -0800 (PST) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,Ilie Garbacea , Joseph Myers , binutils@sourceware.org, Chao-ying Fu , Rich Fuhler , David Lau , Kevin Mills , Catherine Moore , Nathan Sidwell , Nathan Froyd , rdsandiford@googlemail.com Cc: Ilie Garbacea , Joseph Myers , 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 References: <87y6fa9u3t.fsf@firetop.home> <876302kqvu.fsf@firetop.home> <871v5n9m7e.fsf@firetop.home> Date: Tue, 14 Dec 2010 14:51:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Tue\, 14 Dec 2010 12\:06\:04 +0000 \(GMT\)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) 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/msg00455.txt.bz2 "Maciej W. Rozycki" writes: >> I think we're getting close, so could you post any updates as patches >> relative to this one, rather than reposting the whole thing? > > Yes, I think it will make it easier for us both to keep track of what has > been addressed and what not. I have no technical problem with including > further changes in a separate patch. Thanks. For avoidance of doubt, please make any updates (with the FIXMEs fixed, for instance), relative to the original. >> Formatting nit: >> >> /* If the output section is the PLT section, >> then the target is not microMIPS. */ >> target_is_micromips_code_p = (htab->splt != sec >> && ELF_ST_IS_MICROMIPS (h->root.other)); >> >> More importantly, the comment isn't any help. When do we create >> statically-resolved relocations against .plt? Oops, ignore this, I was thinking "sec" was the section that contained the relocation. >> > /* 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. OK, makes sense. Please update the comment to something like: /* Calls from 16-bit code to 32-bit code and vice versa require the mode change. However, we can ignore calls to undefined weak symbols, which should never be executed at runtime. This exception is important because the assembly writer may have "known" that any definition of the symbol would be 16-bit code, and that direct jumps were therefore acceptable. */ >> At least, that's what the code seems to do, since it returns 2 for >> things like: >> >> > + { /* "b(g|l)(e|t)z", "s,p", */ 0x40000000, 0xff200000 }, >> >> which as far as I can tell from the opcodes patch allows both 16-bit >> and 32-bit delay slots. (IV-g doesn't seem to be public yet, so I can't >> check the spec.) But from the way the function is used, it looks >> like 0 really means "no size constraints", so why doesn't the function >> return 0 for instructions like these? > > Only link variations of branches and jumps have a fixed-size delay slot > -- that's because the link register is set to a fixed offset from the > delay-slot instruction (either four as with JAL or two as with JALS). Of > all such jumps and branches only JALX does not have a JALXS counterpart > (regrettably, as it would have made life of software much, much easier). > > I've explained the meaning of 0 below -- it's unsafe to return this value > for a variable-size delay slot. Hmm, I was thinking of the case where there was no branch _after_ the LUI, and where the instruction after the LUI could then become the delay slot for a variable-length branch before the (deleted) LUI. But yeah, I can see that 0 isn't correct if there is a branch immediately after the LUI. >> I'm not sure whether I like the idea of making this function quadratic >> simply to decide whether the preceding instruction is a branch, >> but there's probably not much we can do about that. > > Hmm, we could do this in two passes over the reloc table (still O(n)) and > first make a fast auxiliary data structure (e.g. a hash) to keep addresses > of branch and jump relocations. Given linker relaxation is off by default > I'd vote for this as a future improvement. Yeah, I'd wondered about that, but then we'd need to measure whether that made things better or not. I'm OK with leaving it. Richard