From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 7AB4A385702E for ; Wed, 26 Oct 2022 17:15:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7AB4A385702E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id DA1363408F0; Wed, 26 Oct 2022 17:15:57 +0000 (UTC) Date: Wed, 26 Oct 2022 21:46:33 +0545 From: Mike Frysinger To: Tsukasa OI Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2] sim, sim/{m32c,ppc,rl78}: Use getopt_long Message-ID: Mail-Followup-To: Tsukasa OI , gdb-patches@sourceware.org References: <24e83e920d728237c4efe6f4720643d6fbbf1084.1666113214.git.research_trasio@irq.a4lg.com> <7ad71357e72129e5dc642a5233868b3aa81c484c.1666679042.git.research_trasio@irq.a4lg.com> <8d3126e7-d6ed-fd03-4956-0226e099ab48@irq.a4lg.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/SSdLmMpJF2ewZ3g" Content-Disposition: inline In-Reply-To: <8d3126e7-d6ed-fd03-4956-0226e099ab48@irq.a4lg.com> X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00,GIT_PATCH_0,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --/SSdLmMpJF2ewZ3g Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 26 Oct 2022 19:57, Tsukasa OI wrote: > On 2022/10/26 17:59, Mike Frysinger wrote: > > On 25 Oct 2022 06:27, Tsukasa OI wrote: > >> Because of Binutils/GCC hack, getopt on GNU libc (2.25 or earlier) is > >> currently unusable on sim, causing a regression on CentOS 7. > >> > >> This is caused as follows: > >> > >> 1. If HAVE_DECL_GETOPT is defined (getopt with known prototype is > >> declared), a declaration of getopt in "include/getopt.h" is suppre= ssed. > >> The author started to define HAVE_DECL_GETOPT in sim with the comm= it > >> 340aa4f6872c ("sim: Check known getopt definition existence"). > >> 2. GNU libc (2.25 or earlier)'s includes to dec= lare > >> getopt function (only, not getopt_long or getopt_long_only) but it > >> causes to include Binutils/GCC's "include/getopt.h". > >> 3. If both 1. and 2. are satisfied, despite that tries to > >> declare getopt by including , "include/getopt.h" does not > >> define one, causing getopt function unusable. > >> > >> Getting rid of "include/getopt.h" (e.g. renaming this header file) is = the > >> best solution to avoid hacking but as a short-term solution, this comm= it > >> replaces getopt with getopt_long under sim/. > >> --- > >> sim/igen/igen.c | 6 ++++-- > >> sim/m32c/main.c | 5 ++++- > >> sim/ppc/dgen.c | 6 ++++-- > >> sim/ppc/igen.c | 9 ++++++--- > >> sim/rl78/main.c | 4 +++- > >> 5 files changed, 21 insertions(+), 9 deletions(-) > >> > >> diff --git a/sim/igen/igen.c b/sim/igen/igen.c > >> index ba856401fa9..22cfd30ec43 100644 > >> --- a/sim/igen/igen.c > >> +++ b/sim/igen/igen.c > >> @@ -989,6 +989,7 @@ main (int argc, char **argv, char **envp) > >> char *real_file_name =3D NULL; > >> int is_header =3D 0; > >> int ch; > >> + struct option dummy_longopts =3D { 0 }; > >=20 > > just call it "longopts" so we don't have to rename it in the future if = we > > decide to actually add long options. comes up in the other files too. > >=20 > > otherwise lgtm. > > -mike >=20 > To prepare actual long options, not just renaming, making them array of > struct option seems better. Moving longopts out from the caller is > avoided for now (since it might not get big so that it requires option > definition outside a function). That means... >=20 > Before: struct option dummy_longopts =3D { 0 }; > After: struct option longopts[] =3D { { 0 } }; >=20 > I fixed like this and I'll submit PATCH v3 (with fix above and minor > commit message clarification) soon. Finally, I can clean up the mess I > created. i would make it static const too in that case so it isn't constructed on the stack ... it's just part of the rodata and loaded right away. > Ah, a minor question to you, Mike. Can I consider your "lgtm" as an > approval for specific area you are responsible? "lgtm" is equiv to "approved, please push when you're ready" -mike --/SSdLmMpJF2ewZ3g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmNZWd0ACgkQQWM7n+g3 9YGasw//TiC1tEyGz3ufqKCj5SRrn0UbqMaloS8iaDXVnJDAKUetlxN0c0/xdykc 59FAz/tkd4/c1BrrlA8rjVtboann2Mw9Q+N3ca47cPM+bbaNFI+EW4nm+BpcXuJ/ c+HcL+xRlNgPzzu6BhQVBQdARpDUIWvuhjtubw7vyx1QyK1DbC3v8c+mTHPT1Sqt ALVzaHCo3xITXPkd+HABlvLSbKW91oKX0zV+bCHg+P7IYajsuTBAbBOZQFgzIyaV 9Kifu944EgNXQqexmnFjT/pEdX2g+x/4WDJRdWdxg5CzUFXfkHxxtM31DQhq6HCY LJs5mgcMScVXUqZ+tl5tjzjyibg3GcOW5L43X+1Ki/qMdss4OsReALOSkrohtPgz m0fZh0PEriz/xMTVzl0DqzENkpqVtLtXgOx0byC1+nN7WrEnrYQA/1cKIxitSNPm /uFzqp3nyKQQXDBnwOmjpPNXnm/Migv0XBI86wZjrbU1GW6Io1ryiKHBplPEkbQg aPD7l0ywG67hfgUnWDvATtcNOqJmMHqCofaWlaiS6PgzpMIFXDuJnibdCYX8wo8O oBWrpViry/QDRYjIUzRJ+z/xJA9Kq/oDVHFIelu3VDcupae4IxOWZzfzCYbgBj9Z +wKCAR89DDxVgpW1+eJ5ipLgPxr7x5U3F3xqEid50JNA42KtVBM= =cQjX -----END PGP SIGNATURE----- --/SSdLmMpJF2ewZ3g--