From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by sourceware.org (Postfix) with ESMTPS id C9309385700B for ; Wed, 22 Jul 2020 13:36:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C9309385700B Received: by mail-ej1-x641.google.com with SMTP id n22so2239952ejy.3 for ; Wed, 22 Jul 2020 06:36:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=g71GN4Pbr5dssbn5tD8rMfuGkpbu2fS/hw0wOtpGdD8=; b=lzZtIwvIH9X4PF1vGdNE24Re+kaHGGBR68GnTNYlof06SHwvflItMc5xXOzVUdzNdI oqQuBR7AnW4DE6dsyXphCLhKn7tfobnMjx8ufCBWyxA/2A39urQV/ij42PLbNidOzeqx ysPkWHLbxcqvzIDnxrJCb8GZYE2wZe14CJWrntcfh+i8MmRXLlIgQyrgYL7C7KsVsPVa QPQQ+xcYLs5w/m8NFQenRMGZfKpoP0KzL0tmGyvOrDKOyqcQ+YwUSNnhGS//a9wImka/ KfmingphvdGlkTlXnMKVouMOJhRvBUAXMHzTjZPfua+GLS1qJ3uBrhdNFQwPBHENGg/a pEWw== X-Gm-Message-State: AOAM532tmF7NyWVAXncE+U+9+21+3eVwYuX6JiI73lalI4WT8K7aAXfZ BGh/oxrtINIE06zQWwRU0s1jir1A5eXMlw== X-Google-Smtp-Source: ABdhPJw5QCNSX+i4PdmMuQ39tmBP3/cD8I49AtN7z/eKxGQ3RMTQZCDMVPbxyho89In06tY6C5s0gg== X-Received: by 2002:a17:906:7115:: with SMTP id x21mr29377245ejj.86.1595424999890; Wed, 22 Jul 2020 06:36:39 -0700 (PDT) Received: from gmail.com ([2a03:1b20:3:f011::6d]) by smtp.gmail.com with ESMTPSA id c18sm18680652eja.59.2020.07.22.06.36.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jul 2020 06:36:39 -0700 (PDT) Date: Wed, 22 Jul 2020 15:36:41 +0200 From: Shahab Vahedi To: Simon Marchi Cc: gdb-patches@sourceware.org, Shahab Vahedi , Tom Tromey , Anton Kolesov , Francois Bedard Subject: Re: [PATCH v3 1/3] arc: Add ARCv2 XML target along with refactoring Message-ID: <20200722133641.GB10630@gmail.com> References: <20200428160437.1585-1-shahab.vahedi@gmail.com> <20200713154527.13430-1-shahab.vahedi@gmail.com> <20200713154527.13430-2-shahab.vahedi@gmail.com> <422b0905-456f-8722-b74d-97ade4a95c58@simark.ca> <20200715203500.GA4811@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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: Wed, 22 Jul 2020 13:36:42 -0000 On Thu, Jul 16, 2020 at 09:28:50AM -0400, Simon Marchi wrote: > On 2020-07-15 4:35 p.m., Shahab Vahedi wrote: > When I search for `arc_gdbarch_features_init` in that patch I don't find anything... You're correct. I have it in my local branch. The patch that uses it is going to be submitted very soon. I hope you don't mind if it remains like this. > The code in GDB constructing an arc_gdbarch_features will use the BFD to determine > these two values, whereas the code in GDBserver will use something else (usually > looking at the current process' properties). > > In fact, the constructor is optional, you could just build a arc_gdbarch_features > using aggregate initialization and return it from that function: > > arc_gdbarch_features features {reg_size, isa}; > > It doesn't really matter. I just happen to prefer the constructor method, because > that makes it so you can't "forget" a field and it ensures it can never be in an > uninitialized state. I see now. Actually, I have usecases to not initialize it immediately, but in a few lines of code. > > No, I haven't built it with AddressSanitizer. Could you point me in the right > > direction how I can use it? > > You already got the right information from Christian. You were correct. There were some leaks. After adapting the code to use "target_desc_up" on top of Andrew's fix [1], it is OK now. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0e26741636bee18321d6743ecee6ae9effd35d1f > Well, I guess that depends on how the hash map implementation uses the hash value > to map into buckets. Let's say that there are 16 buckets, and the hash table > implements decides which bucket a value goes in by looking at the last four bits. > And let's imagine that you insert 32 values, all with the same ISA value but with > 32 different reg_sizes values (assuming that would make sense). Then even though > the hash values are all different, they all end up in the same bucket. > > Having a hash function that uniformly distributes the hash values makes that kind > of pathological case much more unlikely. I didn't know about the internals (buckets). Thanks for the explanations. However, if I understand your example correctly, the implementation practically would use the hash values partially (only 8 bits). IMHO, I don't expect it to happen. > > Anyway, I won't press more on that issue, since it's really not that important. I'll leave it as is then. > We're talking about just a few items, so it will never make a difference. And as > Luis said on IRC, it could also use a vector it a linear search. Now specially that the leakage is not an issue anymore, I will keep it as a map. > If `std::hash (reg_size)` produces a uniformly-distributed hash value, and > `std::hash (isa)` as well, then the output is surely uniformly-distributed, > no? I'd say yes: f(x)+f(y) should be uniform if f() is uniform. Cheers, Shahab