From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out199-12.us.a.mail.aliyun.com (out199-12.us.a.mail.aliyun.com [47.90.199.12]) by sourceware.org (Postfix) with ESMTPS id 7CB1B3858C52 for ; Mon, 18 Apr 2022 02:32:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7CB1B3858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.alibaba.com X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01e04423; MF=rjiejie@linux.alibaba.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_---0VAH0IRY_1650249136; Received: from 30.225.212.47(mailfrom:rjiejie@linux.alibaba.com fp:SMTPD_---0VAH0IRY_1650249136) by smtp.aliyun-inc.com(127.0.0.1); Mon, 18 Apr 2022 10:32:17 +0800 Date: Mon, 18 Apr 2022 10:32:11 +0800 From: Jojo R To: Mike Frysinger Cc: newlib@sourceware.org Message-ID: <219fa77c-20a3-4557-bbaf-d6d938844dcb@Spark> In-Reply-To: References: <021a47e3-b78c-4481-8d9d-b8e746091932@Spark> Subject: Re: Weak symbol for printf/scanf family X-Readdle-Message-ID: 219fa77c-20a3-4557-bbaf-d6d938844dcb@Spark MIME-Version: 1.0 X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00, BODY_8BITS, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2022 02:32:22 -0000 Hi, Thanks for your explanation. I check the root cause of the 'multiple definition=E2=80=99 issue again,= the user=E2=80=99s printf symbol would be used first exactly. my issue is that there are two printf family symbols in one object, and user rewrite the one(vfprintf) of them, and other user function call= some other Newlib=E2=80=99s function like vprintf, this will create a error o= f 'multiple definition=E2=80=99. I think linker will check this error by whole .o object, so Newlib shoul= d write every printf/scanf family function in individual object =3F my test case is following : a.s ----------- .section .text.bar .global bar bar: =C2=A0ret =C2=A0.size bar, . - bar .global foo .text .type foo, function foo: =C2=A0call bar =C2=A0ret =C2=A0.size foo, . - foo ---------- build: ./gas/as -o a.o a.s AR: ./binutils/as -r liba.a a.o And the 'main' in b.s will call 'foo', and I want to rewrite function 'ba= r' b.s --------- .global foo .global bar .text bar: =C2=A0nop =C2=A0nop =C2=A0ret =C2=A0.size bar, . - bar .global main .text main: =C2=A0call foo =C2=A0.size main, . - main ---------- build: ./gas/as -o b.o b.s Link: ./ld/ld-new -o a b.o -L. -la it will report 'multi define'. =E2=80=94 Jojo =E5=9C=A8 2022=E5=B9=B44=E6=9C=8813=E6=97=A5 +0800 PM1:27=EF=BC=8CMike =46= rysinger =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A > On 11 Apr 2022 10:50, Jojo R wrote: > > Dose anyone know why libc dose not use WEAK attribution for > > some symbols like printf/scanf family =3F > > > > Some developers want to reimplement sub sets of them maybe :) > > weak symbols in static libs is generally a recipe for doom. the linker = won't > pull in objects from an archive unless there's a strong symbol pulling = it in > which means weak refs effectively never get satisfied. this is mitigate= d by > using --whole-archive, but that defeats the point of using a static lib= with > newlib in the first place. > > backing up a bit, newlib uses static linking, which means if your progr= am > provided the printf symbol, either directly or in an object listed befo= re > the -lc linkage, your printf symbol would be used first, and newlib's o= wn > printf would not be pulled in. if you're still seeing newlib's printf > being pulled in (and presumably causing duplicate symbol linker errors)= , > then something else is going on, and weak symbols wouldn't help. > > but it's hard to say without a concrete example of what you're trying t= o > do and how it isn't working. > -mike