From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00047.outbound.protection.outlook.com [40.107.0.47]) by sourceware.org (Postfix) with ESMTPS id D76E43875A24 for ; Mon, 25 Jul 2022 18:03:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D76E43875A24 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=hLsIbtLuV/2L9jzDLWcr/TJxmJ1dWtDv+fvf+yYaKs/ffLwCnnx5mdstqN9yUUq+6+qK0kSeM3GBXavgK667SyGXIKdzwt/V9HXiwqAldJRRdgEVLBVWMOeFt0HccJVVgrRuT3KFu1gZ17Unb1gRAqM/wxp9bhRln7Pp/sijky4afje8i87hhUeYGID6VWuFzB1TeAYqsCZ8B66X7D1LQB6EhRm5Pc5EnBB0vvoOlcVBAT54ODfgXOoUdlFngf8tDqbnbkaqtirywCh+mBynbLHBzWQSWdxrv1gRxcI3uEfKvki+3hoqkYVQTdNgraZjeSlOGYTYyC80NOPcG6OZjA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9cg3ms/I3N6W4IfNxuAHXI8YPkejnGMzOSPWfx5vYZY=; b=D7OSTLmm9xtNcY85HPWgfxf5W68/uetNBbyl4jmSY/rvW/1U/WlJlh5YMnzloOvh7J+eS/l99qy5Hwcp9Ag3Y2TD9UhAJhcNKMK42GmB2wlhPphbMFRSKuC2gCpZ4H7gPFojrMgxuUGEGGJNL8PPl8OECm3lBwhF7/15jQxXikDXZmkDCinR3Vt026uegM9ilBAyFXXMUvK2FwK/nHd4D73uHfC0lLCwERHH4rCGPuoFpJkSyxWr2QLqW3pclndWQ20zylAa4ECoDLv8h7F4b9zXDxq42jSav2LVRer0fgYmlU9pqBwfSEWWbhzsCDj4d2uSm3gWQfAJhZd+Sn1/Ug== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) Received: from AM6P195CA0041.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::18) by VI1PR08MB5552.eurprd08.prod.outlook.com (2603:10a6:803:ff::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.18; Mon, 25 Jul 2022 18:03:36 +0000 Received: from VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::1b) by AM6P195CA0041.outlook.office365.com (2603:10a6:209:87::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19 via Frontend Transport; Mon, 25 Jul 2022 18:03:36 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT032.mail.protection.outlook.com (10.152.18.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.17 via Frontend Transport; Mon, 25 Jul 2022 18:03:35 +0000 Received: ("Tessian outbound fccf984e7173:v123"); Mon, 25 Jul 2022 18:03:35 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ce8ced05305615c9 X-CR-MTA-TID: 64aa7808 Received: from cf62b5b2cbd7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1C624460-68F9-44A1-8AC0-54CC78AE08A0.1; Mon, 25 Jul 2022 18:03:28 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cf62b5b2cbd7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 25 Jul 2022 18:03:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kOhJK/61Qy9weTUpCluBMSTfZOec82ziN8HLjQ1ZOqSR2ByZZoToayEcYSf+6Vcq/Gn6sbq4msoHoQMHToRAI+cDHGEiDVssjcCKDtOON9cZK6ft+jDFHbqxAl43W1XgaNMOoBbRF9WnRz/R87vKkB9DLbQud/MXFMHv+vOyyEckeIUbUgNvfaD7q6BHrEMwEqYmaME7nt2+WCRVUgWFaVsJ7d+G5OWyA4aEh5X96dXhEVFb9lTYhuU5H6/W+LRqIee1a0heH6zJxzDMH84fYDzXQ5fbiyRGYVfrN027UFia60fQzKKM/aWBBI0flEuUF7M1T9M5xiPtdOpKlFEWBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9cg3ms/I3N6W4IfNxuAHXI8YPkejnGMzOSPWfx5vYZY=; b=Vs/qVvDQE6qtjDBoDC3qOjDN+jIPY98iPhF+GL4pUnWAijxuWxV33NyGNXl4zF2dWNNCgbFWksuMut+XygcqV6LpqUYU65Y8hzU+WKKfS2Kk79SfS5B0sTigEVTWyQ9IWDBt3TRRWrqEsycrva8nQHo5V8kGyw9K8N7hYbNjL1+7GljBLTqrZm4hEl4ZsV2e7o6flSccGy8gFDCN2Renba9E1zyj+OIEUstjmVH+X4Ap4pnaMFIMSCOb6zZRoMgYCaUuTkOrlHl63PTixZ/3sPRqbcBL+1QKXXMJxGFRcuUppp+KkoRGTP2GvmImdheGV+BrJjDTVsL4K538rhfYFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by VE1PR08MB4670.eurprd08.prod.outlook.com (2603:10a6:802:ac::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19; Mon, 25 Jul 2022 18:03:27 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::e866:af0e:2168:5ca7]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::e866:af0e:2168:5ca7%5]) with mapi id 15.20.5458.019; Mon, 25 Jul 2022 18:03:26 +0000 Message-ID: Date: Mon, 25 Jul 2022 19:03:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] Update auxv cache when there is no auxv cached data Content-Language: en-US To: John Baldwin , gdb-patches@sourceware.org References: <20220719144542.1478037-1-luis.machado@arm.com> <76097707-ed9e-1556-fac2-1992ab3cabae@FreeBSD.org> From: Luis Machado In-Reply-To: <76097707-ed9e-1556-fac2-1992ab3cabae@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LNXP265CA0001.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::13) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: ecec9bab-5e65-4a32-c859-08da6e67fe8c X-MS-TrafficTypeDiagnostic: VE1PR08MB4670:EE_|VE1EUR03FT032:EE_|VI1PR08MB5552:EE_ x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 9Uw/txK+hQXo1XN1+tUrGY6nahqC6O0Kjmp4NBzOoLZ0qxDN4nxGgl6ZErXhiOx1JA8JexA1K+WcHkhBtSOxsruwNzBqdEdgBrG7SfK1VeBer8JvddK6S2sVSZcgbvHAfP4e2TlpCsa6MGs9bXnKKBFzEIHmIdkPMG/O9NwKhanmm9/hPCP+JfgASzRojru0+9LOw2ne/8/uPhgVK/Rv6QbSbJxKZA6SOIyAMzADVtzsjVQ8sbp2xGb/m5J+cUx0Dhp6YJxAsQbpXPAFre82vh5nLVZzvgv3JcqpERYO8NCSwtXy+sOzTb9kt8OpYwTxnU/79UNvDszCq4u5drdM/dotXTHbKNUBDczA0X6z3tMdccu3FCjIIRNZDd8kvvFy07jJCBUJe5g0ztUgSQYe9D2TIy7FzMqdeBAeEq8luPmPDGoAxqxVZxLBU/QASAH1sWxP/9J1ptJ+x7zM6YXk86NgcTRMttlWEW43/no3ciGXD0ljartnqOln0Qe2kiKD6v6ZkLwx8CZbV2aUAZh1E0VhLz8ypGjH+5jgmuk1Q73gup9dPnq9w45JrOX7BJl+b+Z2FRJznmKDCj6f1/P7D7bbtLfvzpDqtKj33bt6aYzjynZwEQOAiRRf6pZ3RorvVbpy7bSdgZQNvWea6C6+Vowvgnr+QVm4EMo/KOppkEmy2kK/NOMsqfqBKze4OY8Md3Np5KWRzKBLlN7sFh9vHzEw6Lof178opZzm2sNqMTHNfioV7kIvtVimcfmbYGxtiMot2Di3FYWS4DYdi91SwWUSRTgmXYte2xwuyiGl4rIVKfr6Q5i3/qo8izmiN4jYqmUYcsEIeQH/JSujYgppNg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB3919.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(396003)(346002)(39860400002)(136003)(366004)(376002)(26005)(5660300002)(8936002)(15650500001)(44832011)(86362001)(6486002)(478600001)(66946007)(66476007)(53546011)(6506007)(6512007)(83380400001)(31696002)(66556008)(8676002)(41300700001)(31686004)(38100700002)(316002)(2906002)(2616005)(186003)(36756003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4670 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: b4501f03-c994-41d4-f542-08da6e67f8f9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TXDiYYGe06JbjHPJ6mWGeiVc65G4k7knN0+ifGk+H+Ujxb3rmuLn1BW0LQhoF2kbp8z74E2RLZWSLwld4DMrfrR1x0a5ELNE0J10RnOedBem8DwbP4OtHQzQh477Lv1UQeyq9vxUiqYcb9r9FH2FZhaJo1Fxd6w821/qzfphCLzcfSi9w33uzlariLfXTDJJM1i+uWc1Pkd+3zm06zO016yWiHgXFf5I+fAjMaFsd8R7Sa2mfBQCm9PTy2RHSIyq/3gC8PzLbtgKUSEAjaRCL/s9Qesz0UznsBxHRr5MU78XuQsOoUoDSn+3Zl5m4DFJ8B9fApxk6JVS1jqVP1G7wCEHJGVyFPY6lzMZrqLc/NjZGcBcbKSnSM1mgJNxs2NmM9WXtyQXsuWHPchx+ZcUS8NGWq21Slqe0/NLArDa40r9wMYiscfz7O1WfeChIAun32f0Knv12OdrRv073FNBMRkCASQ0xEOyu0tUEtMlmQGhFcJjAMGR4J9eRT6KLYTMIHZhuovx3v7LLB8a0vDvU/9bnnDICD5ZUTLVkgyej8cGDbkDq4nFvkNqwuNcJA5DaYKPJdaStJlCn6/gyJQdvHa6++DlzolTXvgy8qfxXHJaf+UE72sBYnTwFl+3fiBm2++N6w/09vjc4shBfZFMxMeRuef9ldP6KdpRbitn8AbFDMxh/WkV/lhTa8sSjxsvMKB1D3mwsQvgWJansTOGVigq9zc/IIjGNdmloZgOckrLLlPU7zRr6mwwK56xvwdLXEBKrJ4JzpWUriFx2UXe4u34K2APZ94jpS5gAlbReBIINYnqFUkm3gpN88M/FTwTB0slBvjYHbtQek0nOuIerw== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230016)(4636009)(396003)(39860400002)(136003)(376002)(346002)(40470700004)(46966006)(36840700001)(478600001)(40480700001)(82310400005)(6486002)(6506007)(15650500001)(36860700001)(82740400003)(36756003)(31696002)(31686004)(70206006)(2906002)(53546011)(41300700001)(70586007)(40460700003)(8676002)(47076005)(26005)(336012)(86362001)(2616005)(356005)(6512007)(83380400001)(316002)(5660300002)(8936002)(44832011)(186003)(81166007)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jul 2022 18:03:35.6266 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ecec9bab-5e65-4a32-c859-08da6e67fe8c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5552 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, KAM_DMARC_NONE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 25 Jul 2022 18:03:47 -0000 On 7/25/22 17:05, John Baldwin wrote: > On 7/19/22 7:45 AM, Luis Machado via Gdb-patches wrote: >> While adding support for MTE corefiles and running the MTE corefile tests, >> I noticed a strange situation where loading the symbol file + core file >> through the command line has a different behavior compared to firing up >> GDB, loading the symbol file with the "file" command and then loading the >> core file with the "core" command. >> >> I tracked this down to gdb/auxv.c:get_auxv_inferior_data returning a valid >> info struct, but with no auxv data. >> >> We've been doing the auxv caching for a while now, but sometime between >> enabling auxv data caching and now, we turned the auxv data into an optional >> value. > > The commit to use gdb::optional<> was this one in 2018: > > commit 9018be22e022e6db2ba07c4e407c7244022bc69a > Author: Simon Marchi > Date:   Sat Apr 7 13:19:12 2018 -0400 > >     Make target_read_alloc & al return vectors >     This patch started by changing target_read_alloc_1 to return a >     byte_vector, to avoid manual memory management (in target_read_alloc_1 >     and in the callers).  To communicate failures to the callers, it >     actually returns a gdb::optional. >     Adjusting target_read_stralloc was a bit more tricky, since it wants to >     return a buffer of char, and not gdb_byte.  Since you can't just cast a >     gdb::byte_vector into a gdb::def_vector, I made >     target_read_alloc_1 templated, so both versions (that return vectors of >     gdb_byte and char) are generated.  Since target_read_stralloc now >     returns a gdb::char_vector instead of a gdb::unique_xmalloc_ptr, a >     few callers need to be adjusted. > > But looking at it's diff, it was always caching negative results even > before this change.  This is the relevant hunk of that commit: True. I think my analysis went bad when I mixed up data before (a pointer) the optional conversion and after (an optional vector). So we used to access the contents of auxv through a data pointer, but now we access it through data->data (). > > @@ -358,9 +356,8 @@ get_auxv_inferior_data (struct target_ops *ops) >    info = (struct auxv_info *) inferior_data (inf, auxv_inferior_data); >    if (info == NULL) >      { > -      info = XCNEW (struct auxv_info); > -      info->length = target_read_alloc (ops, TARGET_OBJECT_AUXV, > -                    NULL, &info->data); > +      info = new auxv_info; > +      info->data = target_read_alloc (ops, TARGET_OBJECT_AUXV, NULL); >        set_inferior_data (inf, auxv_inferior_data, info); >      } > > So even before it seems that we would have cached a "negative" result. > > I believe your change will mean that we will keep asking over and over > for the auxv data if a target doesn't support it and that it will only > support positive caching.  I wonder if a recent change means that in > your test case something is trying to fetch the AUXV vector before the > target can read it, e.g. trying to fetch AT_HWCAP* when determining the > target description for a core file or the like?  It seems like for > the core target in corelow.c it should be fine to fetch AUXV data in > the gdbarch_core_read_description hook though.  Did you try setting a > breakpoint for when this function was called to see when it is being > cached? Yes, we do try to fetch data from auxv before it exists. I think it's always been this way for this particular case. > > I wonder if the issue is that parsing the symbol file without a core > is trying to fetch hwcap actually.  Presumably a breakpoint would let > you see that case?  Maybe the fetch of hwcap needs to be guarded by > something like "target_has_execution" or the like? > No, it is trying to fetch AT_ENTRY to figure out the relocation that should be applied to the executable (if any). When we finally load the (native) corefile, then we have access to the AUXV data through the corefile data. This doesn't reproduce with a gcore corefile due to the fact that we now include the target description GDB was using when the corefile was generated. Here's the backtrace: -- #0 get_auxv_inferior_data (ops=0xaaaaad3b0760 ) at ../../../repos/binutils-gdb/gdb/auxv.c:359 #1 0x0000aaaaab28cdc8 in target_auxv_search (ops=0xaaaaad3b0760 , match=0x9, valp=0xffffffffe988) at ../../../repos/binutils-gdb/gdb/auxv.c:381 #2 0x0000aaaaab920110 in svr4_exec_displacement (displacementp=0xffffffffebc0) at ../../../repos/binutils-gdb/gdb/solib-svr4.c:2482 #3 0x0000aaaaab920e4c in svr4_relocate_main_executable () at ../../../repos/binutils-gdb/gdb/solib-svr4.c:2878 #4 0x0000aaaaab921008 in svr4_solib_create_inferior_hook (from_tty=1) at ../../../repos/binutils-gdb/gdb/solib-svr4.c:2933 #5 0x0000aaaaab9288a0 in solib_create_inferior_hook (from_tty=1) at ../../../repos/binutils-gdb/gdb/solib.c:1285 #6 0x0000aaaaab9747cc in symbol_file_command (args=0xfffffffff6c6 "~/aarch64-mte-gcore", from_tty=1) at ../../../repos/binutils-gdb/gdb/symfile.c:1655 #7 0x0000aaaaab500fc4 in file_command (arg=0xfffffffff6c6 "~/aarch64-mte-gcore", from_tty=1) at ../../../repos/binutils-gdb/gdb/exec.c:555 #8 0x0000aaaaab3519f0 in do_simple_func (args=0xfffffffff6c6 "~/aarch64-mte-gcore", from_tty=1, c=0xaaaaad786a60) at ../../../repos/binutils-gdb/gdb/cli/cli-decode.c:95 #9 0x0000aaaaab3572c8 in cmd_func (cmd=0xaaaaad786a60, args=0xfffffffff6c6 "~/aarch64-mte-gcore", from_tty=1) at ../../../repos/binutils-gdb/gdb/cli/cli-decode.c:2516 #10 0x0000aaaaab9f0ed4 in execute_command (p=0xfffffffff6d8 "e", from_tty=1) at ../../../repos/binutils-gdb/gdb/top.c:699 #11 0x0000aaaaab68c75c in catch_command_errors (command=0xaaaaab9f0984 , arg=0xfffffffff6c1 "file ~/aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at ../../../repos/binutils-gdb/gdb/main.c:513 #12 0x0000aaaaab68c9ac in execute_cmdargs (cmdarg_vec=0xfffffffff080, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0xffffffffefd4) at ../../../repos/binutils-gdb/gdb/main.c:608 #13 0x0000aaaaab68df18 in captured_main_1 (context=0xfffffffff280) at ../../../repos/binutils-gdb/gdb/main.c:1298 #14 0x0000aaaaab68e0c0 in captured_main (data=0xfffffffff280) at ../../../repos/binutils-gdb/gdb/main.c:1319 #15 0x0000aaaaab68e11c in gdb_main (During symbol reading: const value length mismatch for 'sigall_set', got 128, expected 0 args=0xfffffffff280) at ../../../repos/binutils-gdb/gdb/main.c:1344 #16 0x0000aaaaab1655ec in main (argc=5, argv=0xfffffffff418) at ../../../repos/binutils-gdb/gdb/gdb.c:32 -- I think this was a latent bug and I just happened to run into it. It doesn't make sense to cache the output of the auxv from a target that doesn't have auxv data. But we don't want to keep requesting things over and over again.