From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id BD3553864808 for ; Fri, 10 Feb 2023 14:18:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD3553864808 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wr1-x42c.google.com with SMTP id y1so5225139wru.2 for ; Fri, 10 Feb 2023 06:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nxFOcaVLc1/siqFN22HAAAHL9rySfLW0dMuvmIM+324=; b=eVSOsbqGS7ZiynbUlfdz0SVLt6JL0ipgG7mUgBZ0ThvcoKILQcFAN8N9HAHhpvYBhv CoZYGPED5s+e+qpb80/oPqmhAfqtAJIhDvbVcjTfNi4dhl3V2LqGAVIoIzUNTCHR63b2 QWPFnUkF+y2epfR4Bw9ZFHncpnq55k5KvM9N+giEB/PQnHKjoRZJxR6ixLW+XZ6ksNEI pqFNAG3fwhwClSLLRCbz7IaKgfPe2jsF7RdlRTDX1zShkanoWY8yKy9S/oY/mNB8enkj y5iEPvQWJS/4wMY8pvjzmT/TlP6ijMwuRq3c7oB3jniZHzVfRydWKl0Ib1xkj/GwHBGW +bgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nxFOcaVLc1/siqFN22HAAAHL9rySfLW0dMuvmIM+324=; b=2lz76iFlp2BgT083KtfxL5UDaUrS/qqmk4no2Hj3+PKXJTBODD13RPxsOQUzSQDzyy AWYWoflLaz8QeCe1TD7qC6Oxt4m0f75jXnQUbVPB4P+2kCrgi15vhwR3aQB+iMxqGAMb FEKN09IDQMvw95JwBFm3Cw8AJXZFzmM+zanViOxgWvoUaLyfTeLKSYfSB5DP0C/7rwJ2 r9I6iZfwN/8aKRQ2ctIMjWlzC65yhYl77luFGmGD90uPxBS+Pnhk1ot1OFXYi43mBJNj n71jQJtYO3yrXgrf/VC1YQSC1UMTht666kE2cGTorNucMrFJ/T8AomH6pUokYnQMh3UW vl+g== X-Gm-Message-State: AO0yUKUE9owt1pOzqvzn2RJUl9RuJgCoQmN0kYFbez5Zd97t8XEDrl99 mCj4i2JAROmO6AKsfbGsmISXyg== X-Google-Smtp-Source: AK7set9mqx0UWL+gY0KCxYkij8kt+QKe99hCalbFmL219zmz4ifWVYcs1fle4gDW/yB4FmYK/feEUQ== X-Received: by 2002:adf:fa83:0:b0:2bf:ae16:817c with SMTP id h3-20020adffa83000000b002bfae16817cmr14292011wrr.29.1676038683539; Fri, 10 Feb 2023 06:18:03 -0800 (PST) Received: from tpp.orcam.me.uk (tpp.orcam.me.uk. [2001:8b0:154:0:ea6a:64ff:fe24:f2fc]) by smtp.gmail.com with ESMTPSA id n22-20020a05600c4f9600b003dcc82ce53fsm5912560wmq.38.2023.02.10.06.18.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2023 06:18:02 -0800 (PST) Date: Fri, 10 Feb 2023 14:18:01 +0000 (GMT) From: "Maciej W. Rozycki" To: Tom Tromey cc: gdb-patches@sourceware.org, Andrew Burgess , Richard Bunt Subject: Re: [PATCH v3 2/5] GDB: Fix the mess with value byte/bit range types In-Reply-To: <87k012lgol.fsf@tromey.com> Message-ID: References: <87k012lgol.fsf@tromey.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: On Tue, 31 Jan 2023, Tom Tromey wrote: > >>>>> "Maciej" == Maciej W Rozycki writes: > > Maciej> Consistently use the LONGEST and ULONGEST types for value byte/bit > Maciej> offsets and lengths respectively, avoiding slient truncation for ranges > Maciej> exceeding the 32-bit span, which may cause incorrect matching. Also > Maciej> report a conversion overflow on byte ranges that cannot be expressed in > Maciej> terms of bits with these data types, e.g.: > > Maciej> (gdb) print one_hundred[1LL << 58] > Maciej> Integer overflow in data location calculation > Maciej> (gdb) print one_hundred[(-1LL << 58) - 1] > Maciej> Integer overflow in data location calculation > Maciej> (gdb) > > Maciej> Previously such accesses would be let through with unpredictable results > Maciej> produced. > > Thank you. I'm curious how you found the spots to change. I have backtraced by hand, that is I started from `value_bits_available' and `insert_into_bit_range_vector' looking for the call sites recursively. > Maciej> + if (offset != ((offset & mask) ^ sign) - sign > Maciej> + || length != ((length & mask) ^ sign) - sign > Maciej> + || (length > 0 && (~offset & (offset + length - 1) & sign) != 0)) > Maciej> + error (_("Integer overflow in data location calculation")); > > Terrifying. And to my surprise we don't seem to have any sort of > generic sign extension macro. Indeed, and neither in BFD. We could have a use for one at least in bfd/elfxx-mips.c and gdb/mips-tdep.c; probably many others. This could go in bfd/bfd-in.h just as BFD_ALIGN, or libiberty. Maciej