From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +IvOFsMGel91bAAAWB0awg (envelope-from ) for ; Sun, 04 Oct 2020 13:30:43 -0400 Received: by simark.ca (Postfix, from userid 112) id 5B4121EE0F; Sun, 4 Oct 2020 13:30:43 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A8B1E1E965 for ; Sun, 4 Oct 2020 13:30:42 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 421BA384C005; Sun, 4 Oct 2020 17:30:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 421BA384C005 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601832642; bh=9KEWo+kDUAJ9wX31Kmf7e1WjrcGittP2J31BGJsdNNk=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=q/oe6pGLDGOf3yfjk3YtJ5QfrsgpxObmgKi3BY7PVp3AuQbOPNT4ERtr/e/W3ynGo BAAwLSczBwkqtSaRMoo5zWaDqXPH+noQPmS9/Mv8IUyhniCBFlqeXQCIrmQu1cEp92 opfCtiaa5bbPlciWV23wJ/GHH6swCjjJCeG59JtA= Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by sourceware.org (Postfix) with ESMTPS id 19659384C005 for ; Sun, 4 Oct 2020 17:30:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 19659384C005 Received: by mail-pj1-x1042.google.com with SMTP id t7so4092256pjd.3 for ; Sun, 04 Oct 2020 10:30:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9KEWo+kDUAJ9wX31Kmf7e1WjrcGittP2J31BGJsdNNk=; b=EA1tGM6B8KhLefGVuU0zEQ+SG2iWESDj4LbPUZdj1MKxqoqhQZx7xk6onlIwHoF7NE 8SqplI9Dy/nm7TnF8rHIaJY+WRx2qHeQZ233z08N5HhVq4lafriVXBVWEoXSHwvYnKu6 ZuccB3SOj/1ziC9LFiuteuSTPYzIWPYv/s2Kz1oWfl04VFEfvwjbzJjtJatRIcJYb/CD sEoodhfa4LmeKG7xNBT7ZYkhdnR8KLdXV31HxdxyCJVKCvz4HRtPxgUVBQi37R7pgwam S/J26oNrkaf1alOq2l1KAPlIUsir+d34uYCC8Ya8P1buf5ld9Iork7yTcgRAxEum6063 BzSg== X-Gm-Message-State: AOAM531zjS0f+44WFXtwOIiAWxWV77DGHGdjzxE91iOgKNYomQklWzEh dpTbUCYU4WxXFx6VrUIie0/n/cfG+gusr5z7JJju0SNwOgI= X-Google-Smtp-Source: ABdhPJxYwVPmEIHbcwHoZ6d0BH0fS0ximLEbr1le3lTbb5SKaI6zjzPZ1m91j/nMKmXOMU3Lu/wK0vE6mhpD8mYwqpw= X-Received: by 2002:a17:90b:4acf:: with SMTP id mh15mr12409935pjb.204.1601832638716; Sun, 04 Oct 2020 10:30:38 -0700 (PDT) MIME-Version: 1.0 References: <55f5bbd9-86ce-c9bc-61ac-5447f078d2ec@simark.ca> <20201003181451.GA2211174@google.com> In-Reply-To: <20201003181451.GA2211174@google.com> Date: Sun, 4 Oct 2020 10:30:27 -0700 Message-ID: Subject: Re: [PATCH v2] gdb: add support for handling core dumps on arm-none-eabi To: gdb-patches@sourceware.org, Luis Machado , Simon Marchi , Robin Haberkorn Content-Type: text/plain; charset="UTF-8" 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: , From: Paul Mathieu via Gdb-patches Reply-To: Paul Mathieu Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Cc'ing Robin, the original author of the patch, who can maybe help us answer a couple questions. > > Ok, so that answers the question in my other email, about which tool > > produces this format of core. The answer is this specific python > > script, and the format is "Paul's ARM core format" :). > > It was some team work between what gdb understood "natively" and what > the patch does. > More specifically, this patch only seems to tell gdb to get the > registers from the core file the way it would normally do, and then > supply them almost verbatim to the regcache. > The struct for these registers is nothing special either, you can find > it in the kernel code as well: > https://elixir.bootlin.com/linux/latest/source/arch/arm/include/uapi/asm/ptrace.h#L135 > > > > I don't know what Luis thinks about this, but I would be a bit hesitant > > to add support in GDB for a core format that's not standard nor the > > output of some "well-known" tool (which would be a de facto standard). > > > > Is there a format that already exists in the ARM ecosystem for core > > dumps of bare-metal systems, we could base our stuff on? > > I'm not aware of anything that does that. There are tools that generate > memory dumps and CPU register dumps into their own proprietary format, > but nothing that I know that you could call a 'core file'. > > Are there other tools besides gdb that deal with core dumps? Maybe that > could help me find other formats. > > That being said, the format used here is "well-known" in the sense that > it's the exact same format the linux kernel would use to dump cores on > arm-linux-* Robin, what was the format you used for your core dumps? Did you use a tool that's already out there?