From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 7A1AB3858C3A for ; Wed, 20 Oct 2021 16:18:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A1AB3858C3A Received: from [IPv6:240e:35a:1002:de00:dc73:854d:832e:2] (unknown [IPv6:240e:35a:1002:de00:dc73:854d:832e:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id 4D1F266311; Wed, 20 Oct 2021 12:17:58 -0400 (EDT) Message-ID: Subject: Re: GCC link problem help! From: Xi Ruoyao To: =?gb2312?Q?=B9=F0=D3=C0=C1=D6?= , LIU Hao , Tom Kacvinsky Cc: gcc-help , =?gb2312?Q?=C1=F8=C3=AF=EA=BF?= , =?gb2312?Q?=C0=EE=B4=B3=B4=B3?= , =?gb2312?Q?=CC=C0=C8=EA?= Date: Thu, 21 Oct 2021 00:17:51 +0800 In-Reply-To: <241991aa.65e41.17c9e31312b.Coremail.guiyonglin@huaqin.com> References: <20f6fd91.5593e.17c6d6050ed.Coremail.guiyonglin@huaqin.com> <0e6a4bba-872f-92e5-af61-e5cc94a2b547@126.com> <241991aa.65e41.17c9e31312b.Coremail.guiyonglin@huaqin.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3030.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 16:18:13 -0000 On Wed, 2021-10-20 at 22:53 +0800, 桂永林 wrote: > Hellow Tom and Liu Hao, >    We encounter another GCC link problem. Our hardware is cotex-M33 > platform,  our software project development on windows environment and > use GCC compiler and the gcc-linker as bellow: > > >    gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch > revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2- > update) > >    GCC: GNU ISO C11  7 2018-q2-update > >    GCC parameter:  -std=gnu11 > >    gcc-linker parameter: --specs=nano.specs --specs=nosys.specs >    >    Our project need link a C++ static lib into our project. The C++ > lib build enviroment as bellow: >    G++：GNU ISO 2011 C++ >    G++ parameter：-std=gnu++11 -fabi-version=0 -fno-exceptions -fno- > rtti -fno-use-cxa-atexit -fno-non-call-exceptions > > > >    But we found that if we linked the C++ static lib to our program, > then the program have runtime logic problem sometimes. If we do not > link the C++ lib, it can run well. We can not understand why the > reason. We guess, if maybe some gcc linker parameter need used when we > need link the C++ lib? >    Can you give us some suggest about how to fix this problem!   I think it will be very difficult to tell. Maybe there is some undefined behavior (for example, out-of-bound access) in your program and linking in libstdc++ just changes the memory layout or something and exploits the issue. The undefined behavior may be even triggered by some hardware problem for a embedded system... (I once debugged my program for one day and then found out one capacitor was simply too small!) -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University