From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20583 invoked by alias); 18 Dec 2019 01:50:10 -0000 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 Received: (qmail 20311 invoked by uid 89); 18 Dec 2019 01:50:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:sk:mail-il, HX-Languages-Length:1405, H*f:sk:b4V6iUu, H*f:sk:CAFyWVa X-HELO: mail-il1-f180.google.com Received: from mail-il1-f180.google.com (HELO mail-il1-f180.google.com) (209.85.166.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2019 01:50:06 +0000 Received: by mail-il1-f180.google.com with SMTP id a6so270741ili.9 for ; Tue, 17 Dec 2019 17:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YdUPQ9W2IfY/HbxI3+MDHhvvvOZY1s+2p2ygpC58U0Q=; b=heRN2SzORSqOrYQL0ai6cwDTosUgKTpZoRWsrF+MUSl3uT6Xj8HjqyO7otg2c9eFTG gr1STk57OkKWAi7oj3izXsDkZ49HF+zyvsn6B4vVXHje0v7BSu1k3m4fPvgvh3az7lAX TP7c85gTEPhjy1/D8vVUBbvFlUtRoq8UDwTdZgPoElTQHcEDdLIyiBZ9R7gkkXx16Ffi oFx7xYW2Z2HEX/aHtdvpgMPQkQHvziWJaLOyHF4z+jeKqtCngCmiEWRNT45kzNSEfrLL yOhralec/EH+0r6x+Q84htvEwI4YUY7iZ1221WB6vnA5lt9SoT89E0cXz1tXp2spAs6B C81w== MIME-Version: 1.0 References: In-Reply-To: From: Nelson Chu Date: Wed, 18 Dec 2019 01:50:00 -0000 Message-ID: Subject: Re: [PATCH] [RISCV] Support subtraction of .uleb128. To: Jim Wilson Cc: Kuan-Lin Chen , Palmer Dabbelt , "binutils@sourceware.org Development" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00280.txt.bz2 There is one minor thing. Maciej has pointed out before that it's better done with one the percent-codes to `_bfd_error_handler' rather than aborting the link right away, so that any further link errors are also reported and you don't have to shake them out one by one. So report the relocation error via linker's callback function seems to be better. I think maybe we can report a dangerous relocation for the mismatched R_RISCV_SET_ULEB128 and R_RISCV_SUB_ULEB128. What I meant is that, + case R_RISCV_SET_ULEB128: ... + else + { + if (uleb128_rel->r_offset != rel->r_offset) + { - (*_bfd_error_handler) (_("%pB: relocation %s mismatched. "), - input_bfd, howto->name); - bfd_set_error (bfd_error_bad_value); + msg = ("R_RISCV_SET_ULEB128 and R_RISCV_SUB_ULEB128 are mismatched. "); + r = bfd_reloc_dangerous; + break; + } + relocation = relocation - uleb128_vma; + uleb128_rel = NULL; + break; + } + + case R_RISCV_SUB_ULEB128: + if (uleb128_rel) + { + if (uleb128_rel->r_offset != rel->r_offset) + { - (*_bfd_error_handler) (_("%pB: relocation %s mismatched. "), - input_bfd, howto->name); - bfd_set_error (bfd_error_bad_value); + msg = ("R_RISCV_SET_ULEB128 and R_RISCV_SUB_ULEB128 are mismatched. "); + r = bfd_reloc_dangerous; + break; + } + relocation = uleb128_vma - relocation; + uleb128_rel = NULL; + break; + } Thanks and regards Nelson