From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 799563857350 for ; Tue, 19 Apr 2022 10:14:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 799563857350 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-434-nf0JfdysOqusOB1El64i9Q-1; Tue, 19 Apr 2022 06:14:41 -0400 X-MC-Unique: nf0JfdysOqusOB1El64i9Q-1 Received: by mail-wm1-f71.google.com with SMTP id r204-20020a1c44d5000000b0038eaca2b8c9so1091487wma.7 for ; Tue, 19 Apr 2022 03:14:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=eNYuprg2So/Wt8gTyKqZV7CYbGnlS0rHKHnb6MQKteQ=; b=lBlHOk41ZhEqh23CGvnxF4Bl48QLAkQWmKVm6RUXBtj+hIQp4m3VVXJxAFg/HYZd5j GhUuuastl0Ul15K5irLEkjm4w5QyWU7/JqMVgN/balLJ3yUkMMssMgwYHwv1NBXYu8pT zcYhojAZFvJIXVzqpu19HAn6ogt3S/glxxY2YN7asVCr9+h6E0JtP5J4MFEQ9SHQTjli 10ammVhD19SN2JMMtwLrDhGTtNAl1aSCc2J/C8pM2MZKtreeZVhOGqG+5Vag7gtAu7qu kGYoSSFBHEyadgdnkw+jYnO9j/+8vJRjGoj/kOmoVjG7tupmV+Txa93yT7LhT7eY5Gfy o4Pg== X-Gm-Message-State: AOAM532lCq06/UNtBuKHloU9yZFePRYuX9IVgHxEN0Ux2xOhObGTfAAs M1iPcrgvdsNXHgC5yDMQolrpNmi/DcufeQsTGhqVnOK69/L+xQSyIdQLsdWEyYp+J+vlWH6lItS yCrPVfko7g3hwwudflQ== X-Received: by 2002:a7b:c14d:0:b0:38e:b9ad:52fa with SMTP id z13-20020a7bc14d000000b0038eb9ad52famr15166609wmi.19.1650363280249; Tue, 19 Apr 2022 03:14:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9Nys1Myrfa0EWxHQjksDEfmB0O6H9/gkwK+KGJrCVNfmFgr1qhH9iqRgzwhTg5TmiH6oI/w== X-Received: by 2002:a7b:c14d:0:b0:38e:b9ad:52fa with SMTP id z13-20020a7bc14d000000b0038eb9ad52famr15166594wmi.19.1650363280075; Tue, 19 Apr 2022 03:14:40 -0700 (PDT) Received: from [192.168.1.6] (adsl-2-solo-173-39.claranet.co.uk. [80.168.173.39]) by smtp.gmail.com with ESMTPSA id c3-20020a05600c148300b0038ebc8ad740sm25023188wmh.1.2022.04.19.03.14.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Apr 2022 03:14:39 -0700 (PDT) Message-ID: <0221b84a-cf84-1a17-ce33-c426ec3716c9@redhat.com> Date: Tue, 19 Apr 2022 11:14:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: =?UTF-8?B?5aSP56uL5pa5?= , "binutils@sourceware.org" References: <6ee36ffc-44b4-478f-856b-ca48738d6a8b.lifang_xia@c-sky.com> From: Nick Clifton Subject: Re: LD: Question about rewriting the function in library In-Reply-To: <6ee36ffc-44b4-478f-856b-ca48738d6a8b.lifang_xia@c-sky.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2022 10:14:44 -0000 Hi 夏立方, > a.s > ----------- > .global bar > bar: > ret > b.s > --------- > .global bar > bar: > nop > nop > ret > it will report 'multi define'. Correct. > Spliting 'bar' to an other object (c.o) could solve this problem. But the library in the project can't be re-implemented now. OK. > From my understanding, overriding a function should not be related to other functions in the same section or in the same object. > So, my question is: Why not use the 'bar' in b.o? Because the bar symbol has been defined twice, once in a.o and once in b.o and the linker does not allow this. (If the symbols are global symbols). You have a couple of options to fix this problem. If you can edit the sources of a.s, you could make the definition of bar weak: a.s ------ .global bar .weak bar [...] Weak symbols can be overridden by another symbol of the same name, so in this case bar in a.o will only be used if another definition of bar cannot be found. If you link a.o and b.o time, the definition of bar in b.o will be used and the definition in a.o will be ignored. If you cannot modify a.s however, then you can make use of a linker feature that allows you to rename symbols. The "--wrap " option will tell the linker that any reference to should be replaced with a reference to __wrap_. So if you change the code in b.s to: .global __wrap_bar __wrap_bar: nop nop ret [...] And then link with "--wrap bar" specified on the linker command line; the call to "bar" in a.o will be transformed into a call "__wrap_bar" and so it will be resolved by the definition in b.o. I hope that this helps. Cheers Nick