From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by sourceware.org (Postfix) with ESMTPS id 336A5388EC19 for ; Mon, 26 Oct 2020 11:24:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 336A5388EC19 Received: by mail-qk1-x744.google.com with SMTP id a23so7873817qkg.13 for ; Mon, 26 Oct 2020 04:24:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6dc3qegD34DbsWqT5Io1JrZ9G8FVVrfxhv8UqpPXTk8=; b=RfnHS5K6as9mAxmBm3UTlny9NiamlJqBuKc4g0Y86GKAnrLEZvpQPC3yw9eqM+R0FI KGju9LvFGdmckhPq3O1FeskM0IB998KGGIHpdTEgXzLo58FU+HKjI+uCZ/8YK/Ry8vwt kg7ObthGDOEXm9siIWC1QMdFzhFOhewWpoqWJCRu+/wiOMntGqi0q4O070rA/Q8GRCRb R4At0qUIu/L/PrlAjU7pHebyLFhUgj8URDABo6LWJVZJPlcMeAvtp0k2EX3JRDkOg50R DwvzBNmDb3ZGJhwQLXKAf2W7BSPBXTBxm4GlfNk0E3TjNEx6cAyOvmtETMNkDHmJ2BoW kicA== X-Gm-Message-State: AOAM5335WUyML1jowJ76wOgpE7fJSWRPZhRNi5dML19b4MYYxu/aNjjK w8rBNK+rKIgMxcLj3J1Rvpor//x351AEkQ== X-Google-Smtp-Source: ABdhPJyYCJ+THwBP5MBwK6J5Bq5Zen0lYgyNLRfLe/xXd2fwslNG92zajrYyj1vwaY25H2xyiFNS6Q== X-Received: by 2002:ae9:f507:: with SMTP id o7mr14928673qkg.420.1603711463547; Mon, 26 Oct 2020 04:24:23 -0700 (PDT) Received: from ?IPv6:2804:7f0:8284:1487:e8:f2cf:c3e1:1857? ([2804:7f0:8284:1487:e8:f2cf:c3e1:1857]) by smtp.gmail.com with ESMTPSA id q3sm6091206qkf.24.2020.10.26.04.24.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 04:24:22 -0700 (PDT) Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi To: Fredrik Hederstierna , Simon Marchi , Paul Mathieu Cc: "gdb-patches@sourceware.org" References: <688f8081-e972-2ca1-255a-14b63e9e173d@simark.ca> From: Luis Machado Message-ID: Date: Mon, 26 Oct 2020 08:24:20 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: Mon, 26 Oct 2020 11:24:26 -0000 On 10/25/20 6:06 PM, Fredrik Hederstierna via Gdb-patches wrote: >> From: Simon Marchi >> Sent: Friday, October 23, 2020 2:37 AM >> >> On my side, from the comments I gave earlier and other observations: >> >> - there area clearly some unnecessary includes, cut it down to what's >> necessary >> - don't put things in the header file if they are only used in the >>   source file (the macros in arm-none-tdep.h, for example) >> - none_init_corefile has an unused parameter >> - some unnecessary forward declarations here and there >> - is the handling of inferior arguments relevant for bare-metal? >> - if it works with the GDB simulator (target sim), I'd really like if we >>   could have a test for this: generate a core, read it back, make sure >>   you can print stuff > > Thanks for feedback, I think the new [Patch v4] address all your bullets above. > > I have tested the patch on ARM simulator in GDB, and it worked, > though some observations: > > - The ARM simulator does not support ARM Cortex architecture? > I had to try it out on ARMv4T arch code, though needed to make some patchwork. > - The ARM simulator does enumerate registers differently, and remapping is done, > though if trying to fetch all registers by passing -1, then eg D0-D15 was not handled. > - The ARM simulator expect that target have a stack frame and tried to put that in separate section, > though this needs to be setup, if just running with SP=0, then SP will soon be 0xFFFFFFFxx, and > then when trying to make corefile and stack should be saved, all 0-0xFFFFFFFFF will be saved 4GByte! > Though by explicitly setting SP (either by code or from console) it seems to work. > Cortex handles initial stack pointer differently by having an entry for SP in start vectors table. > > This worked for me in the ARM simulator on test application compiled for ARMv4T thumb. > > (gdb) target sim > (gdb) load > (gdb) break main > (gdb) run > (gdb) set $sp = 0xFFFFFF > (gdb) cont > > (gdb) gcore test.core > > Exiting and restarting GDB with elf-file and adding corefile 'test.core', same registers and call-stack could be reviewed, so my simple example worked. > >> Luis and Alan (both GDB ARM maintainers) also expressed the desire to >> have the format documented.  Alan suggested a section in the GDB manual, >> in the ARM-specific section.  I think it is a good idea.  This is >> important, so we have something to point to when people ask "what format >> should I generate so GDB can read it". > > Yes, it was suggested by someone to adding an arm-none section in "G.5.3 ARM Features". > How to proceed on this? I guess the current design is same as *ix minus all specific *ix parts that could be stripped out from documentation. I recall also suggesting discussing the core file format out in the open through the gdb@sourcware.org mailing list (here https://sourceware.org/pipermail/gdb-patches/2020-October/172721.html). That would make it easier to others interested in this to contribute and provide their thoughts. It makes it a bit harder to design things based on patches directly.