From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MNrTHMSUBWA2HgAAWB0awg (envelope-from ) for ; Mon, 18 Jan 2021 09:01:40 -0500 Received: by simark.ca (Postfix, from userid 112) id 6C3CA1EF80; Mon, 18 Jan 2021 09:01:40 -0500 (EST) 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 E48371E945 for ; Mon, 18 Jan 2021 09:01:36 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5CE353AAB000; Mon, 18 Jan 2021 14:01:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5CE353AAB000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610978496; bh=gk674BgKpXnDvJTNnhRpNFegAu4ST3BPDpWkDI+oAvY=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Xw7+VswIv2eLV3u13WEkgKTu/FvuWgzNrpwvEaP0ZtbU+rb1xjjvCqQJFhkPRuc0e VpXpndkFGoGYveMOlPVmQ/Cwzp4a/apMy4B48VEkfN+HFxaC+jLLRMMxC2rA0Ycvn2 R0vzOlhpyEL4QAL2sImHsPNdIfYOFqDIoyeq5fxA= Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) by sourceware.org (Postfix) with ESMTPS id D713E386F432 for ; Mon, 18 Jan 2021 14:01:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D713E386F432 Received: by mail-qk1-x72d.google.com with SMTP id d14so18637323qkc.13 for ; Mon, 18 Jan 2021 06:01:30 -0800 (PST) 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=gk674BgKpXnDvJTNnhRpNFegAu4ST3BPDpWkDI+oAvY=; b=W4e08DwSKfezyj2y3pXV1P7O1EKl8ZsHsu+spynFkAXJu5gJla3sO1G8CTh2E/4Hve WMeKC8w974idHxV0oYjiOwZ6zJ6X8lavzc+NxnQpcECXCSwWLeHyHx51DfuUu2XXK3DN 41U5EpiPqfxSc4mRHcl5CH1e2TYl+cm2CZxYRYQqyhAHjxmK9X011E4kEGyrPtU730Ts H4eZfo5VAAn7HunhP3fwESX2QCF66+96283KgXH4uzrp6qvzt9aNT1XKSlINnqkHIV0x yGyZGAxaqJLXFoaV8FTSYwT47x+utUfz53vPJdsNQ8RhsUkQSVu/Fa3uD5H6qEIfOsIt JnvQ== X-Gm-Message-State: AOAM533U/cgo/dVLEbY1cv4XAj+omke+nP7G03BttfSt0bLN+xWH03cy mAxFywzqH5C3dPrcit6CW693a7fMon9aow== X-Google-Smtp-Source: ABdhPJwJvAW6hbbCtd/uAf0X+cSYXAkjSbzbCFy2t743XKcCXkYeILpbupDe2npBjb1sXM3haCpTMQ== X-Received: by 2002:a37:ae44:: with SMTP id x65mr24780092qke.347.1610978489907; Mon, 18 Jan 2021 06:01:29 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:874d:d01c:4557:3294:bc27? ([2804:7f0:8284:874d:d01c:4557:3294:bc27]) by smtp.gmail.com with ESMTPSA id o58sm493055qtc.59.2021.01.18.06.01.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jan 2021 06:01:29 -0800 (PST) Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi To: Andrew Burgess References: <20210118110922.GT265215@embecosm.com> Message-ID: <0327e6b6-2a4e-cf4f-333c-5f3cde18c49c@linaro.org> Date: Mon, 18 Jan 2021 11:01:25 -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: <20210118110922.GT265215@embecosm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Luis Machado via Gdb-patches Reply-To: Luis Machado Cc: Fredrik Hederstierna , Simon Marchi , "gdb-patches@sourceware.org" , Paul Mathieu Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi Andrew, On 1/18/21 8:09 AM, Andrew Burgess wrote: > * Luis Machado via Gdb-patches [2021-01-14 09:50:42 -0300]: > >> Hi, >> >> On 1/14/21 9:36 AM, Fredrik Hederstierna wrote: >>> Ping, do anyone have any more input how to proceed on this? >>> I think I have made what I can do, to the limits of my knowledge and understanding. >>> >>> I read recently about RISCV now seems to have merged corefile support for their arch? >> >> The idea was to establish a common ground that could be used for both RISCV >> and ARM, and prevent design issues from getting in the way. >> >> If RISCV bare metal corefile was merged, does that mean we can reuse the >> same strategy to pursue bare metal ARM core file support now? And does that >> mean we just need to come up with a patch using the same design? > > We covered most of this ground in the discussion on the RISC-V patch, > but if we assume that the plan is ELF + NOTES then most of the > "design" is actually dictated by GDB and BFD already. All we actually > end up providing on the GDB side is glue to funnel the GDB state over > to BFD. > > Most of the work is in laying out the registers, something which is (I > hope we can agree) something that is target specific. > > My goal for this week is to get an updated revision of the RISC-V bare > metal patches on to the list, with as much code as possible moved into > a common file. Honestly, I don't think there's going to be a huge > amount of reuse, but I'll do as much as I can. I'm sure you will. I can write some documentation based on my understanding so far. Maybe that will be a good start and then folks can add to it. > > The ARM patch that was proposed was already ELF + NOTES, and already > had some code in a common file. So I'll probably borrow some of that. > >> >>> why can RISCV corefile be merged but not this? I guess ARM-Cortex users is magnitude amount higher and the benefit of this feature is huge. >>> And it would be really good if synergy could be used to share code, since alot functions I guess are same. >>> If documentation is the issue, do we have an issue ticket on that? >> >> From my end, the acceptance of ARM bare metal core files was dependent on >> having a documented design of what the bare metal core files should look >> like. Was that documentation included in the RISCV work? If not, that wasn't >> the agreement when I send comments to that patch series. > > The RISC-V work has not been merged, and writing some documentation is > also on my goal list for this week. That's what I noticed when I went looking for the commits. I think there was a misunderstanding. > > I take all feedback I get on this list seriously, and though mistakes > can happen, I'll not going to merge a patch without fixing the review > issues, at least not without having a good discussion with the > reviewer first. No doubt about that, really. I think there was some expectation that merging changes into GDB was quicker than it really is in practice. > > Thanks, > Andrew > >> >>> >>> Can we just merge this patch-v4 and set target GDB-11, and solve the doc-issue-ticket, then we just force ourselves to solve docs before the release, >>> or how can we 'make it happen'? It seems to be about to fail again if time just goes and none try push it further forward. >> >> I'd love to have such support, but I'm not actively working on it. I can >> commit to review the changes and not let it be forgotten, but the >> development work must be pursued by someone else. > > > >> >>> >>> Thanks! Kindly, >>> Fredrik >>> >>> From: Paul Mathieu >>> Sent: Tuesday, October 27, 2020 5:53 PM >>> To: Fredrik Hederstierna >>> Cc: Luis Machado ; Simon Marchi ; gdb-patches@sourceware.org >>> Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi >>> Hi Fredrik, >>> >>>> This is the current format when trying from ARM simulator: >>>> >>>> fredrik@legion ~/src/armv4t_coretest$ readelf -aA test.core >>>> ELF Header: >>>>    Magic:   7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 >>>>    Class:                             ELF32 >>>>    Data:                              2's complement, little endian >>>>    Version:                           1 (current) >>>>    OS/ABI:                            ARM >>>>    ABI Version:                       0 >>>>    Type:                              CORE (Core file) >>>>    Machine:                           ARM >>>>    Version:                           0x1 >>>>    Entry point address:               0x0 >>>>    Start of program headers:          52 (bytes into file) >>>>    Start of section headers:          8084 (bytes into file) >>>>    Flags:                             0x0 >>>>    Size of this header:               52 (bytes) >>>>    Size of program headers:           32 (bytes) >>>>    Number of program headers:         5 >>>>    Size of section headers:           40 (bytes) >>>>    Number of section headers:         7 >>>>    Section header string table index: 6 >>>> >>>> Section Headers: >>>>    [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al >>>>    [ 0]                   NULL            00000000 000000 000000 00      0   0  0 >>>>    [ 1] note0             NOTE            00000000 001e44 000138 00   A  0   0  1 >>>>    [ 2] load              PROGBITS        00010000 0000d4 000100 00  AX  0   0  1 >>>>    [ 3] load              PROGBITS        00080000 0001d4 000000 00  WA  0   0  1 >>>>    [ 4] load              PROGBITS        00080000 0001d4 000400 00  WA  0   0  1 >>>>    [ 5] load              PROGBITS        000fe790 0005d4 001870 00  WA  0   0  1 >>>>    [ 6] .shstrtab         STRTAB          00000000 001f7c 000016 00      0   0  1 >>>> Key to Flags: >>>>    W (write), A (alloc), X (execute), M (merge), S (strings), I (info), >>>>    L (link order), O (extra OS processing required), G (group), T (TLS), >>>>    C (compressed), x (unknown), o (OS specific), E (exclude), >>>>    y (purecode), p (processor specific) >>>> >>>> There are no section groups in this file. >>>> >>>> Program Headers: >>>>    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align >>>>    NOTE           0x001e44 0x00000000 0x00000000 0x00138 0x00000 R   0x1 >>>>    LOAD           0x0000d4 0x00010000 0x00000000 0x00100 0x00100 R E 0x1 >>>>    LOAD           0x0001d4 0x00080000 0x00000000 0x00000 0x00000 RW  0x1 >>>>    LOAD           0x0001d4 0x00080000 0x00000000 0x00400 0x00400 RW  0x1 >>>>    LOAD           0x0005d4 0x000fe790 0x00000000 0x01870 0x01870 RW  0x1 >>>> >>>>   Section to Segment mapping: >>>>    Segment Sections... >>>>     00 >>>>     01     load >>>>     02     load >>>>     03     load load >>>>     04     load >>>> >>>> There is no dynamic section in this file. >>>> There are no relocations in this file. >>>> There are no unwind sections in this file. >>>> No version information found in this file. >>>> >>>> Displaying notes found at file offset 0x00001e44 with length 0x00000138: >>>>    Owner                 Data size       Description >>>>    CORE                 0x0000007c       NT_PRPSINFO (prpsinfo structure) >>>>    CORE                 0x00000094       NT_PRSTATUS (prstatus structure) >>> >>> Does this support `.reg/xxx` notes for RTOS that support multiple tasks? >>> It would be really nice to have `info threads` "just work" >>> >>> Paul >>>