From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YRkNFeYDKmr2uQAAWB0awg (envelope-from ) for ; Wed, 10 Jun 2026 20:40:06 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=eagercon.com header.i=@eagercon.com header.a=rsa-sha256 header.s=dreamhost header.b=UHj0WNgv; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 520D01E024; Wed, 10 Jun 2026 20:40:06 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6DAAB1E024 for ; Wed, 10 Jun 2026 20:40:05 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E19724BA798D for ; Thu, 11 Jun 2026 00:39:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E19724BA798D Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=eagercon.com header.i=@eagercon.com header.a=rsa-sha256 header.s=dreamhost header.b=UHj0WNgv Received: from cornsilk.maple.relay.mailchannels.net (cornsilk.maple.relay.mailchannels.net [23.83.214.40]) by sourceware.org (Postfix) with ESMTPS id D0A884BA2E05; Thu, 11 Jun 2026 00:39:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D0A884BA2E05 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=eagercon.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eagercon.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D0A884BA2E05 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=23.83.214.40 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781138355; cv=none; b=wN8TAdHK+T7NmbT2brisXTsIBt5BevwXbglDwoB3c0NGmHTdrs+Yapm/IyTQ9Gn0kJ7pYGR0zGk/3o2pxKVvzbf3CyGwgBaXX4DOTOV7x6MfXrDlev4bjaN+pkkbXByjvzvlqJsqZfr47RW8In5HUz9j51KKdQyS0GomMbwLa08= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781138355; c=relaxed/simple; bh=nQZvMcjNjj9pOw6xYZiP0NfTYYCL5BNf2DCFxTokxKA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=YhTIym/7CBg7QzNCE1JOYBRS/vr6beEOnYfD3AAkdBp9kmiF7H65ciTJ2hS/UGkXtDBx6GnWxSYkHOiCouamGKCCaXlBFRhl85FUOlSwWSKmI4H/U+PH6vvm+gEzIcnMQ4WTazo76DlPWF0oK1duuelMmbNRKBTA2ZWX7RC2Zwc= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=eagercon.com header.i=@eagercon.com header.a=rsa-sha256 header.s=dreamhost header.b=UHj0WNgv DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0A884BA2E05 X-Sender-Id: dreamhost|x-authsender|eager@eagerm.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B87AF7228A3; Thu, 11 Jun 2026 00:39:13 +0000 (UTC) Received: from pdx1-sub0-mail-a247.dreamhost.com (100-116-151-138.trex-nlb.outbound.svc.cluster.local [100.116.151.138]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5318C722990; Thu, 11 Jun 2026 00:39:13 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|eager@eagerm.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|eager@eagerm.com X-MailChannels-Auth-Id: dreamhost X-Tangy-Whimsical: 7a151d5f5e9baad2_1781138353603_3108025927 X-MC-Loop-Signature: 1781138353603:1193175245 X-MC-Ingress-Time: 1781138353603 Received: from pdx1-sub0-mail-a247.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.151.138 (trex/7.1.5); Thu, 11 Jun 2026 00:39:13 +0000 Received: from [192.168.20.10] (99-119-193-198.lightspeed.sntcca.sbcglobal.net [99.119.193.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by pdx1-sub0-mail-a247.dreamhost.com (Postfix) with ESMTPSA id 4gbP0c64qzz105D; Wed, 10 Jun 2026 17:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eagercon.com; s=dreamhost; t=1781138353; bh=YiVjDJMsm1WQgD0Kq9N4TaV6esAsM/Z8FKielmCLoF4=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=UHj0WNgvvs2H4w8SpIhaXS/Y39+Eh0htCSEEUuevDDSyBxKFKi21TzuEnfowbzapl YRapXsoXGM+1l+eavayocoMild9i2D3w3Nw4ujHXznWd24FeJZLW6a4Nv6xktJ56UL nRssC0z65NLnZ6Xzqh4h1HUw1/cyKja/KI60dL0mlPg1Gk26QNT682QBAgz02sL/iX jDBAM5c9sVlSWnO9EMdxAb0rD5XbH0OnK3mlUnY1YDm1EoPDNRhx3NkCrciUFnb149 9KUg5X2igg8F4hJYuvYJ0molJlepq+DbVdNpB1eTeO0tKRVzWTjr3O5VnARIIpiXe8 kuPmnUM9XJrpA== Message-ID: <09e2a40b-2f9f-4f8e-af31-0235baf61acd@eagercon.com> Date: Wed, 10 Jun 2026 17:39:12 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb/MicroBlaze: Add support for native linux gdb To: Gopi Kumar Bulusu , binutils@sourceware.org, gdb-patches@sourceware.org Cc: Tom Tromey , Simon Marchi References: <874ijq5knu.fsf@tromey.com> Content-Language: en-US From: Michael Eager In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Gopi -- I (or more accurately, git) fixed several whitespace issues. Since this is a revised patch, has it been retested? On 6/1/26 10:05 PM, Gopi Kumar Bulusu wrote: > namaskaaram > > Attached is the updated patch. All the changes suggested on PATCH v1 > have been made and tested. > > I did not remove the (sal.line != 0) check as it seemed trivial. > However, I can make that a separate patch if necessary. > > Our sysadm In the process of setting up a git compatible email - the > process may take more time; until then appreciate your patience with > the attachments. > > Important Note: > > 1) gdb appears to have an elaborate scheme to handle C++ exceptions > and "tunnel" them through exception unaware C code. This code is with > readline. Anytime > an error is discovered (even a syntax error) by a module, > gdb_exception_error() thrown is tunneled through readline using the > TRY_SJLJ/CATCH_SJLJ macros > implemented using setjmp/longjmp. > > 2) There is an issue that I came across while testing; native gdb goes > into an infinite loop when handling errors. I analyzed it and found it > to be an obvious glibc > sysdeps/unix/sysv/linux/microblaze/____longjmp_chk.S issue and > reported it to AMD. It is possible I missed out a glibc patch; At this > time - this is not a gdb issue. > > 3) Plan to follow through [2] and ensure a gcc/glibc defect report is > created if needed. > > dhanyavaadaaha > gopi > > On Tue, Jun 2, 2026 at 5:58 AM Michael Eager wrote: >> >> Please post an updated patch for review. >> >> On 5/31/26 11:38 PM, Gopi Kumar Bulusu wrote: >>> On Fri, May 29, 2026 at 8:26 PM Tom Tromey wrote: >>>> >>>>>>>>> Gopi Kumar Bulusu writes: >>>> >>>>> Attached is a patch to add native linux support for gdb including >>>>> cache target support.. >>>> >>>> Thanks for the patch. >>>> >>>> I read through it and have some nits. There's nothing very serious >>>> except this: >>>> >>>>> The original sources for the patch come from Xilinx/AMD Yocto git >>>>> repository (2025.2) >>>> >>>> Who wrote them and are they covered by the copyright assignment? >>>> >>>> This is the most important consideration, the patch can't land without >>>> this being clear. >>> >>> This work is being performed under a contract with Xilinx/AMD as >>> confirmed in a different response to >>> Simon and therefore covered by the copyright assignment. >>> >>> I will make the changes as described below and retest. >>> >>> Approved for commit ? >>> >>> dhanyavaadaaha >>> gopi >>> >>>> >>>>> From a3328b4cdfc58783b5f290f22255b36e26a6fb14 Mon Sep 17 00:00:00 2001 >>>>> From: Gopi Kumar Bulusu >>>>> Date: Thu, 7 May 2026 17:47:40 +0530 >>>>> Subject: [PATCH] gdb/MicroBlaze: Add support for native linux gdb >>>> >>>> It's best to just git send-email rather than using an attachment. >>>> >>>>> bfd/ChangeLog: >>>> >>>>> * elf32-microblaze.c (microblaze_elf_grok_prstatus): New function. >>>>> (microblaze_elf_grok_psinfo): Likewise. >>>> >>>>> gdb/ChangeLog: >>>> >>>>> * Makefile.in (HFILES_NO_SRCDIR): Add microblaze-linux-tdep.h >>>>> ALLDEPFILES: Add microblaze-linux-nat.c >>>> >>>> gdb doesn't use ChangeLogs any more and this text should all be removed. >>>> >>>>> +#define MICROBLAZE_TARGET_HAS_GETREGS 0 >>>>> +#define MICROBLAZE_TARGET_HAS_SETREGS 0 >>>> >>>> This seems weird: >>>> >>>>> +/* Wrapper function around ptrace. */ >>>>> + >>>>> +static void >>>>> +fetch_target_gp_regs (int tid, elf_gregset_t *gregs) >>>>> +{ >>>>> + elf_greg_t *gregp = *gregs; >>>>> + >>>>> +#if MICROBLAZE_TARGET_HAS_GETREGS >>>>> + if (ptrace (PTRACE_GETREGS, tid, 0, (long) gregp) < 0) >>>>> + { >>>>> + perror_with_name (_("Couldn't get registers")); >>>>> + return; >>>>> + } >>>>> +#error "this configuration did not work during testing" >>>> >>>> Normally we don't put new dead code into gdb. >>>> >>>> I think this and the defines could just be replaced with a comment >>>> explaining that PTRACE_GETREGS doesn't work on this platform. >>>> >>>>> +++ b/gdb/microblaze-linux-tdep.h >>>>> @@ -0,0 +1,24 @@ >>>>> +/* Target-dependent code for GNU/Linux on MicroBlaze. >>>>> + >>>>> + Copyright (C) 2021-2026 Free Software Foundation, Inc. >>>>> + >>>>> + This file is part of GDB. >>>>> + >>>>> + This program is free software; you can redistribute it and/or modify >>>>> + it under the terms of the GNU General Public License as published by >>>>> + the Free Software Foundation; either version 3 of the License, or >>>>> + (at your option) any later version. >>>>> + >>>>> + This program is distributed in the hope that it will be useful, >>>>> + but WITHOUT ANY WARRANTY; without even the implied warranty of >>>>> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>>> + GNU General Public License for more details. >>>>> + >>>>> + You should have received a copy of the GNU General Public License >>>>> + along with this program. If not, see . */ >>>>> +#ifndef MICROBLAZE_LINUX_TDEP_H >>>>> +#define MICROBLAZE_LINUX_TDEP_H >>>>> + /* Target descriptions. */ >>>>> + extern struct target_desc *tdesc_microblaze_linux; >>>> >>>> Blank line between the #define and the comment. >>>> >>>> Also this define should have a slightly different name, see >>>> check-include-guards.py. >>>> >>>>> non_stack_instruction_found = 0; >>>>> + cache->register_offsets[rd] = -imm; >>>>> continue; >>>> >>>> Indentation looks wrong, probably not using tabs. >>>> >>>>> @@ -399,8 +400,7 @@ microblaze_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR start_pc) >>>>> { >>>>> sal = find_sal_for_pc (func_start, 0); >>>> >>>>> - if (sal.end < func_end >>>>> - && start_pc <= sal.end) >>>>> + if (sal.line != 0 && sal.end <= func_end && start_pc <= sal.end) >>>>> start_pc = sal.end; >>>> >>>> No objection from me but this seems somewhat unrelated. >>>> >>>> >>>>> /* Call for side effects. */ >>>>> - get_frame_func (next_frame); >>>>> + cache->pc = get_frame_func (next_frame); >>>> >>>> Please remove that comment as it is now wrong. >>>> >>>>> + if (regnum == MICROBLAZE_SP_REGNUM) >>>>> + regnum = 1; >>>> >>>> Wrong indentation. >>>> >>>>> + if (regnum == -1) { >>>>> + int i; >>>>> + >>>>> + for (i = 0; i < MICROBLAZE_REDR_REGNUM; i++) { >>>>> + regcache->raw_supply (i, regs + i * MICROBLAZE_REGISTER_SIZE); >>>>> + } >>>> >>>> Wrong brace placement in this hunk. >>>> >>>>> + cb (".reg", tdep->sizeof_gregset, tdep->sizeof_gregset, tdep->gregset, NULL, >>>>> + cb_data); >>>> >>>> Normally in new code we're using 'nullptr' now. Best would be to go >>>> through the whole patch and check for this. You don't have to fix >>>> pre-existing code that is using NULL though. >>>> >>>>> gdbarch *gdbarch >>>>> = gdbarch_alloc (&info, gdbarch_tdep_up (new microblaze_gdbarch_tdep)); >>>> >>>>> + microblaze_gdbarch_tdep *tdep >>>>> + = gdbarch_tdep (gdbarch); >>>>> + >>>>> + tdep->gregset = NULL; >>>>> + tdep->sizeof_gregset = 0; >>>>> + tdep->fpregset = NULL; >>>>> + tdep->sizeof_fpregset = 0; >>>> >>>> Here it would be better to just add inline initializers to the new >>>> fields in microblaze_gdbarch_tdep. Then they'll automatically be >>>> initialized by the 'new'. >>>> >>>> Tom >>> >> -- Michael Eager