From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id g+PbCbkSWWMS0xAAWB0awg (envelope-from ) for ; Wed, 26 Oct 2022 06:58:01 -0400 Received: by simark.ca (Postfix, from userid 112) id 1BAF71E11A; Wed, 26 Oct 2022 06:58:01 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=jqPtxUTV; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 628EF1E0D3 for ; Wed, 26 Oct 2022 06:58:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 914AC3857024 for ; Wed, 26 Oct 2022 10:57:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 914AC3857024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666781879; bh=7fp1R80gPo7THu7hxw/ylLiuLqjJo+8fe9u5Fr8j0pE=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=jqPtxUTVOtdpC87B7heCSfpAYbo/ouHw19P62V+7JbzvhSYEguo37pCuXnjtm1uLG NKDPVdFAFJV58xfsIeCUoPjZdt2gWW/+ASs/B7jwdQOUDM2gv9LlBA4ynMZmj+woqV kDnZRPViDS2ejO2RqP6DmfckdbihSFV30l4oHLrE= Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id 74C9A3858C60 for ; Wed, 26 Oct 2022 10:57:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 74C9A3858C60 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 45B95300089; Wed, 26 Oct 2022 10:57:33 +0000 (UTC) Message-ID: <8d3126e7-d6ed-fd03-4956-0226e099ab48@irq.a4lg.com> Date: Wed, 26 Oct 2022 19:57:30 +0900 Mime-Version: 1.0 Subject: Re: [PATCH v2] sim, sim/{m32c,ppc,rl78}: Use getopt_long To: gdb-patches@sourceware.org, Mike Frysinger References: <24e83e920d728237c4efe6f4720643d6fbbf1084.1666113214.git.research_trasio@irq.a4lg.com> <7ad71357e72129e5dc642a5233868b3aa81c484c.1666679042.git.research_trasio@irq.a4lg.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Tsukasa OI via Gdb-patches Reply-To: Tsukasa OI Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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 suppressed. >> The author started to define HAVE_DECL_GETOPT in sim with the commit >> 340aa4f6872c ("sim: Check known getopt definition existence"). >> 2. GNU libc (2.25 or earlier)'s includes to declare >> 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 commit >> 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 = NULL; >> int is_header = 0; >> int ch; >> + struct option dummy_longopts = { 0 }; > > 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. > > otherwise lgtm. > -mike 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... Before: struct option dummy_longopts = { 0 }; After: struct option longopts[] = { { 0 } }; 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. Ah, a minor question to you, Mike. Can I consider your "lgtm" as an approval for specific area you are responsible? Best regards, Tsukasa