From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2047.outbound.protection.outlook.com [40.107.20.47]) by sourceware.org (Postfix) with ESMTPS id A9BD73856DE7 for ; Wed, 11 May 2022 14:52:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A9BD73856DE7 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=OA6HaoTmpNq8LeZvBuSQ79GuhfrCLiAj+urSFQfJeWolHYLsbvcxdWqlx4c4qIQDTNdTc9q6RNtWjcvYzT0chNRXCm5hq2loscmejS16sJf6yemCEK1iusqsMjmjenK8hqMmbkjwWUgWpkyNP6441z/j7X+8jnfmq7CLnk79ZtHV67bpCQlIn/pkCPBCfT0GXEucayhDYANmwZSvtHyfLI60LXi/QWvsE69KIQkotkm80xsbzERidmrVdRqWArUkCyfMIDOimXdrEcUmqv3J7SE+iXTucsaQ1dvLsA2VzDvdY3UQopgUuMVxTiL51cCbNcPPOaf8kYAPt1e7uRSnzA== 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=alMfSCYELqyRLqzr5OmXptFKt80d2O+cTe7LmoE+kGY=; b=ShyyRnumMEifhoaIniJUEBvMCm0AeUbnF5r2Vm558ZBSBKnW7QKiI/MAV+FGUtibm6Hw0N7dxgZr/Mfia0wGNaOtCPsLHO2NXAMm3zppD4nPpjW4YG7yy2txeVJ19V71dBdqlOqBFBWGNLsIL3AywYRgfA60idWeEkbt2C8Rhuvvgaa2t+SCft9G8qRguKBTtd5mLiOaal5dr2jdpJUA7bu1OoaMz7zRyWA7yxIfW573GP8/NA9HRLkZcAxemfaeSEcM2MzKHOoKxqgZsZebU+wX8GtdvLlQWh/c4Ov5uu4ncxkG7MG9SIUcjBTk74jj6CAt+HqFG6rhVFpnlkhPBw== 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 DB6PR0802CA0026.eurprd08.prod.outlook.com (2603:10a6:4:a3::12) by DB9PR08MB7113.eurprd08.prod.outlook.com (2603:10a6:10:2c2::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13; Wed, 11 May 2022 14:52:08 +0000 Received: from DB5EUR03FT006.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a3:cafe::f5) by DB6PR0802CA0026.outlook.office365.com (2603:10a6:4:a3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13 via Frontend Transport; Wed, 11 May 2022 14:52:08 +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; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT006.mail.protection.outlook.com (10.152.20.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13 via Frontend Transport; Wed, 11 May 2022 14:52:08 +0000 Received: ("Tessian outbound 42cead292588:v119"); Wed, 11 May 2022 14:52:08 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ea2885123d419fdd X-CR-MTA-TID: 64aa7808 Received: from e4e43db38fcf.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 956E8F66-081A-436F-BBFD-D420C6D42A54.1; Wed, 11 May 2022 14:52:01 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e4e43db38fcf.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 11 May 2022 14:52:01 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nx6fXZbrI4rrQbdClSQU0NIZVAsGSXaQW0ETiepvMR6kEaW3HyE6ycZnuQmag35TALb13Qdy2sTXkONjJbpfM5ew/f/2CZRACwPvdhDJB5FOlBNwcSrJbTFLcIZDrO84Wez84+7MujZyG4BwkNHFD2XxBogu2Yp7vzcmP5JfTvAjqCEJxR0RD5McmlFr4ZkYM0gb0KOM2N6QUufq+mGcFy5tDcGwfoOTJyuMIIISIYsK6KntoVvJWcFTduOyfz8P6+uCMTK9+gZOGoFIIHHQYO0tKfavO2m1MxDR1bx8x+lE2W+/V+fM2I6cqbRFvupN/H/xPy7R7NfaRwF2002kEQ== 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=alMfSCYELqyRLqzr5OmXptFKt80d2O+cTe7LmoE+kGY=; b=O/aepL9ji47sWvnpbeks81LtIVsvND80xSJkgPF3mk8EjrAOluY01K4EXhNLNLeO1MZJ/ZloHHZArbP0UwFC3r98YIFZA2OH7KmpPbdTcoMT7EreVYpzg1TIq9LbhE9MrSDmKEb4H7Sd8NhPTOxOcLstW5siPhPGN7n/msW4YKuWb5laU/k+0qinRnAvTn8L4eCqGHZdSvV318G/tr88KOmsncAGHXTcfi/1vG/gNFP6NyehBn/Jr18+usHmNJ1FtF38T4n3wgUHgcdegb845nbZMq390k+l26Dag+2m5VcvLKFPmvLg61XrYyr/WEwlTo76rvWS+I/OfPxqTR2Sew== 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 DB8PR08MB4172.eurprd08.prod.outlook.com (2603:10a6:10:af::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5227.22; Wed, 11 May 2022 14:52:00 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7080:6233:cf8f:a8a6]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::7080:6233:cf8f:a8a6%7]) with mapi id 15.20.5227.023; Wed, 11 May 2022 14:52:00 +0000 Message-ID: <763c426d-7a62-bcb9-223a-d1b5b7e8fc03@arm.com> Date: Wed, 11 May 2022 15:51:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Restoring pc to a different value than lr on aarch64 Content-Language: en-US To: Yichao Yu Cc: gdb@sourceware.org References: <257aa215-a141-6d9b-672d-ea8ce209b107@arm.com> <63f63d70-8a55-618c-06e8-22f923c39e02@arm.com> <02ebd5db-54c6-7fba-e75a-fe35cf1253af@arm.com> From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P123CA0096.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:139::11) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 28d18f99-b931-4b21-38a2-08da335dd2b7 X-MS-TrafficTypeDiagnostic: DB8PR08MB4172:EE_|DB5EUR03FT006:EE_|DB9PR08MB7113:EE_ X-Microsoft-Antispam-PRVS: 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: KRzhPyaH/UQYTFrOWhVQZum7szS5rjtlhp3Wdr+uCa/UlViiiljjZ9wpQg2Q34BMuzk0bhQY4txmDVu68AR+2vuwVNqLCyOZqwdoRUyGvXHNskd/FsXd6cXibTNm4mAbwdJBglUJsKO1hbs9HdMb/m5Av1Ye7GpR4LYfw4F0r9AYXUl++tJ2Gb/RiVxHXOpAoPPi+ZnmjeR7KVn0an1f9n9wASdcpPwStgsecD3vTQICVQSwvR9ltAFy/g/Iegm0g5Q7Za4blGt9Bmo65gTZRX7XaPIyn1vyYd9u2tA6D29bP3gIDM0q5jwFaMBBPa41gBqPUBFNwQu6q0IEm7vZ+zHlkVf7hq/ekx5330okGUbzJBDPRaJkH5lyn6VQSJ116iX/17AsAfNbhELknhYivnJdaCCTKfJRwGMwSGUemgNfuSd5KOI3ZtU0GPOESwiSsR4wps0sRRV/mzYY3weev4TYeX2733nsow/bkpht1e5q+0f9u6kw7e3lzxn2ldoER2FFImAj3T24d0zGhAAKFmS+RhbkkT2n9JA/c6+/o4otpmnVgNUZqEZO3hoHczl9OOkyZWFtTL0XTd7Q+dNSr3n/0MVzXvnlc3dtPzNs9sG699E8Q49r/bXSBRQkxQxdKoZWMuSeCZV0B+wHvtEKSGzBNZ+qvTi5tBWRXVYpCQ2lDc9AJzibzqiBa+O8HnBEUKuEEYF9Oq7I1x+7REv9YUSkUf5v+uiLhbYxdqUKb2A23XYjheHpJ5nOhl3VlyOj 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:(13230001)(4636009)(366004)(508600001)(5660300002)(6916009)(38100700002)(316002)(8936002)(66556008)(66476007)(36756003)(31686004)(186003)(66946007)(2616005)(6512007)(26005)(86362001)(4326008)(8676002)(2906002)(6486002)(83380400001)(6506007)(44832011)(53546011)(31696002)(21314003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB4172 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: DB5EUR03FT006.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: c06df640-8f0d-4fba-780b-08da335dcda7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JRG/RIMwOC8oIw/ywahjILOfoUXAxMLqy7xMoI75KgtZuAjSRH225AZ57Id/YmRdK8CiISc2HW6PE7SjP+mUp5t2IBKcTNDl9bIaUDqvZJAHYQhusPxE/wJkcJz6YqaOnghTTLU4ZAfFKhFhTnC4gqPJyWyHM+sI0sG6ci9neuH4R4kqhrBWRZdPCgbwllxM9FxIFe0zshnXnjsEXA28ZURq06jQeTHR4Nv4wUABWzHIBwhSYVFBruy53pynj+G+q1mj6eq916C0Nf6eHG/h1R7Mu1y1xlQqANV8xBxtQeFMjuNg7PXBugp/ukIbHiw18ADOR6BaDZbKKaGLzchKXXWssutuhSIpQ3Ml59xLzMzQEvNxC5fE8FuCM35EijyKwc8UQqmvjfUjpK/zwj1td7VlRF14C81JtRrkJaK15nU3QIFjQ1Nimovc+rVzAsjqaHGAU1rDrXejEVClLchzLWRxtjoZVJi9XSTYZfmQ/0e3J0JVG7wV/zMkZj0EDtUMqBovWC/5epOgSbuSNNpFNjhsNA6IhjqpqkLnlMYWxyNmYuSZbcWqZDkglMo85HFQOBkwg2fpuBDVAjxdbbYudehg+Vfk/Uv4zxoe/mSJ79bpQzBMqR/pw75NCdebRaFKx30B71JIf36a4HPety+6KWrj9RVYDMR1dMlZIbSLX4MXHbHUodBJyfYX6md8jPsI9PoCMDh08ci0uX13lLbVYftkmnDokox9aTMMo8FTI6E= 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:(13230001)(4636009)(40470700004)(46966006)(36840700001)(8936002)(31696002)(86362001)(6486002)(508600001)(316002)(82310400005)(81166007)(5660300002)(356005)(40460700003)(8676002)(4326008)(70206006)(70586007)(6862004)(36860700001)(31686004)(47076005)(336012)(186003)(36756003)(2616005)(83380400001)(6512007)(26005)(53546011)(2906002)(44832011)(6506007)(21314003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2022 14:52:08.6459 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 28d18f99-b931-4b21-38a2-08da335dd2b7 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: DB5EUR03FT006.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7113 X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2022 14:52:14 -0000 On 5/11/22 14:26, Yichao Yu wrote: > On Tue, May 10, 2022 at 10:49 AM Luis Machado wrote: >> >> On 5/9/22 15:24, Yichao Yu wrote: >>> On Mon, May 9, 2022 at 6:44 AM Luis Machado wrote: >>>> >>>> On 5/6/22 17:30, Yichao Yu wrote: >>>>> On Fri, May 6, 2022 at 12:11 PM Yichao Yu wrote: >>>>>> >>>>>>>> Actually I misspoke for that. It seems that sp is probably fine and >>>>>>>> the only thing missing causing pc to not work is that >>>>>>>> aarch64_dwarf_reg_to_regnum doesn't understand the PC dwarf reg >>>>>>>> number. It seems that the only thing needed is to add a >>>>>>>> >>>>>>>> + if (reg == AARCH64_DWARF_PC) >>>>>>>> + return AARCH64_PC_REGNUM; >>>>>>>> >>>>>>>> to that function. >>>>>>>> >>>>>>> >>>>>>> Yes, GDB always assumes the PC from the previous frame is the LR from >>>>>>> the current frame. That is what GCC generates. >>>>>>> >>>>>>> If a different setup is needed, GDB needs to be taught about it. >>>>>> >>>>>> I agree the current code makes sense for what gcc generates. However, >>>>>> I think given the document from arm, explicitly setting the PC value >>>>>> in the unwind info should also work. >>>>>> Would a patch similar to the one above be acceptable to fix this issue? >>>>>> >>>>>> A related issue is that gdb also seems to be ignoring the return >>>>>> address register in CIE. There is at least one use of it in glibc[2] >>>>>> where the return address register is set to x15 instead. >>>>>> I've verified that gdb is currently unable to unwind after the call to >>>>>> `strlen` from `rawmemchr` even though the return address is still in >>>>>> x15. >>>>>> I thought this can be fixed by chaiming that PC is RA just like the >>>>>> fallback case but that is apparently not working... >>>>> >>>>> Actually this did work but the address is wrong before the value was >>>>> written to x15... So it was just due to incorrect unwind info (the >>>>> glibc implementation should specify how to find x15 on the entry of >>>>> rawmemchr). >>>>> Is the current implementation due to some edge cases? (like old >>>>> compiler version doesn't put a valid value in the CIE for the return >>>>> address register). It seems that many other architecture simply use >>>>> _RA so I don't see why this would have broader problems... >> >> This looks like a genuine bug, one that is not hit that often given it >> is not very common for frame to change the return address column. This >> will need to be fixed eventually. Thanks for spotting that. >> >>>> >>>> It is probably historical that this has been handled like this. If there >>>> is a use case for having a PC column containing distinct data, then we >>>> could support that. >>> >>> I couldn't find any existed code using this, but it seems that this is >>> the intent from ARM and I really can't think of any other way to >>> restore everything including both pc and lr so I'd like to support >>> that at least.... >>> >>>> It wouldn't be as simple as that change you mentioned though, as other >>>> parts of the code assume PC comes from the LR. >> >> I take that back. I investigated this further and I think this should >> work, although it is a use case that is not so common. >> >>> >>> There are indeed other unwinders (the prologue unwinder) that assumes >>> this, which I think should be fine. Specifying the PC explicitly >>> should only apply to the dwarf unwinder. The only other place where I >>> can find that relies on this is aarch64_gen_return_address. It doesn't >>> seem that this function is used in most of the other logics and if the >>> return address column is somehow accessible from here it should also >>> not be too hard to fix. >> >> I think it is only the case for the dwarf unwinder, as that is the >> unwinder that has access to the CFI information. > > Sorry what did you mean by "it" here? (being able to handle PC != LR > during unwinding?) Do I need to worry about gen_return_address? > Sorry, I meant that we only need to worry about the dwarf unwinder functions. The other code not relying on CFI information doesn't need to be touched (prologue unwinder, aarch64_gen_return_address etc). At this point, we'd like to augment aarch64_dwarf_reg_to_regnum to return a valid number for the dwarf PC register. >>> >>> Is there any other cases that I'm missing? I've also tested with my >>> simple change and it seems that unwinding from normal functions still >>> works as intended. >> >> Yes, I tried it on my end as well and it does work. What I was worried >> about is that we need to adjust the LR value in some cases. >> >> For aarch32 we need to remove the LSB, and for aarch64 we need to unmask >> the value of LR if it is signed through PAC. This is the reason why we >> have a custom dwarf2_prev_register implementation. > > Is the aarch64-tdep code used for aarch32 tracee as well? > The aarch64 code is not shared by aarch32 (that would be arm-tdep.c). I just mentioned it because both arm-tdep.c and aarch64-tdep.c use the same mechanism for unwinding PC. That is, they return LR instead. >> gcc and clang emit the return address column as r30. If we don't specify >> any initialization rule for PC, then the dwarf2 unwinder will go through >> the route of fetching LR and adjusting the values. >> >> On the other hand, if PC is available in a CFI column, then the dwarf >> unwinder won't call the custom hook and will instead proceed to >> calculate PC from the CFI expression at that column, which should give >> the result that you want. > > Right, and I guess that means that the custom unwind rule needs to > take the pointer authentication into account? > (I've never used any machines with that enabled so I'm not 100% how > it's supposed to work....) It does need to take that into account. But using a custom function for unwinding PC means we will not have access to > >> We can't initialize PC to DWARF2_FRAME_REG_RA though (not yet, anyway), >> as that would default to mapping PC to the return address column. For >> gcc and clang, this would be x30. That would give GDB no chance of >> adjusting the LR values if required (for PAC-signed LR values). > > Just so that I understand, if LR is signed, then upon return it should > still have the signed value. (Or in the case a different register is > used for return address, `ret xn` would not change xn value) > Only the resulting PC should have the signed part masked off. That's > why the unwinding of LR is correct without any post-processing logic > as-is but the unwinding of PC needs to be treated specially. > That's correct. >> It would be nice to have a testcase for this, alongside your patch, to >> make sure GDB is always doing the correct unwinding. > > The part for returning the name of PC is easy. I assume the test would > be mainly throwing in a aarch64-xxx.{c,exp} and to check if explicitly > specifying the PC in the unwind info result in valid unwinding. I'll > try look for some but any examples that I can follow? I think gdb/testsuite/gdb.arch/arm-disp-step.{S,exp} is a good example. Basically, some .S file that contains some random instructions and CFI directives that we single-step over and check if GDB is following the values of the registers correctly. The .S file gives us more control over those CFI directives. > This should fix the case where PC is explicitly specified but wont fix > the case where a return column is specified. Handling that requires a > different way to post-processing the PC. Correct. That is a separate bug and I'll need to investigate that. Thanks! Luis