From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 31CAA385800A for ; Tue, 11 May 2021 20:48:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 31CAA385800A Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id E72AD335C6F; Tue, 11 May 2021 20:48:03 +0000 (UTC) Date: Tue, 11 May 2021 16:48:02 -0400 From: Mike Frysinger To: Luis Machado Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] [sim] Fix build failure in d10v sim Message-ID: Mail-Followup-To: Luis Machado , gdb-patches@sourceware.org References: <20210510191423.3627307-1-luis.machado@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 11 May 2021 20:48:08 -0000 On 10 May 2021 23:01, Luis Machado via Gdb-patches wrote: > On 5/10/21 7:30 PM, Mike Frysinger wrote: > > On 10 May 2021 16:14, Luis Machado via Gdb-patches wrote: > >> While building all targets on Ubuntu 20.04/aarch64, I ran into the following > >> build error: > >> > >> In file included from /usr/include/string.h:495, > >> from ../../bfd/bfd.h:48, > >> from ../../../../repos/binutils-gdb/sim/d10v/interp.c:4: > >> In function 'memset', > >> inlined from 'sim_create_inferior' at ../../../../repos/binutils-gdb/sim/d10v/interp.c:1146:3: > >> /usr/include/aarch64-linux-gnu/bits/string_fortified.h:71:10: error: ‘__builtin_memset’ offset [33, 616] from the object at ‘State’ is out of the bounds of referenced subobject ‘regs’ with type ‘reg_t[16]’ {aka ‘short unsigned int[16]’} at offset 0 [-Werror=array-bounds] > >> 71 | return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); > >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> cc1: all warnings being treated as errors > >> make[3]: *** [Makefile:558: interp.o] Error 1 > >> > >> I looked at a different sim (cr16), and it zeroes out the entire State, not > >> just the registers. > > > > it's clearing more than just the regs. it's clearing all the members in the > > state struct from regs up to mem. so regs, cregs, sp, a, slot, etc... if > > you want to change it, the comment in the header probably needs adjusting. > > Heh... the comment in the header says something and the one before > memset says another that is completely different. > > >> It is unclear why we have the casts to uintptr. > > > > because pointer math on diff types isn't allowed, and the 3rd arg to memset > > needs to be a scalar integer. so casting to uintptr_t is the correct way to > > calculate this value. > > Right. What I mean is I don't understand why the complexity to clear > some data with memset while the comment is stating we should clear > everything. Then again, it looks like it was copy/pasted from somewhere > else and not documented properly in the .c file. > > The same seems to be happening with cr16. The header says we reset > things until a certain member. But the .c code says we reset everything. i don't think the comment/code is at odds. it's just not as precise as it should be. it's clearing all the cpu state, but leaving the system (memory) state alone. if you look through the git history on these files, it was a bit more explicit: it would save the fields it cared about, memset the whole thing, then restore the fields. at some point that was all deleted and replaced with this (clever?) memset call. copy pasta between some of these older sim ports is quite bad/heavy. it's slow going converting it over, especially for ports that don't seem to have anyone who cares about them anymore. some of these arches i know exist only because there's a sim port for them ... never heard of them otherwise. -mike