From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id C329B3865C2D for ; Mon, 18 Jan 2021 11:01:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C329B3865C2D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wm1-x32c.google.com with SMTP id y187so13408946wmd.3 for ; Mon, 18 Jan 2021 03:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Bdl/J1cLpI0V3pKl3VCMWBRHRg+hc2nop2w5wZX2FzU=; b=XEXvdLNEY9IbEE1K2sk2+elDZFweFqYeccoTgEZZNfqhnDe8C2nsbogRlHUpqiXgtf 0Bh8C+UTczq4WE/iRw6mVD4kNesa2v48KSycxmE+xEEihioCCEjHxYCIYUwQOuOMU2qm YwtF+fyBohsgmXj29tLoWHbw4aUBYXx9HT9awVcqP1Vp+ADCUrp30y3qC+w0j9eHi0sG 7zLQm2oi7b4o+Aw7MZu8d0V7Ge2Y+/fG0WxXShL5zhL1CoQ+FulQvlky5frTwLCh+Xk6 GmO1TDxKfGNBHqtZ3vm3g09wpHf4sbC5FYbEMUgBtqJbRvcQTmWt31zfIR7A1cyM2Spv 2SiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Bdl/J1cLpI0V3pKl3VCMWBRHRg+hc2nop2w5wZX2FzU=; b=dQBcTVFJhXpVpwUxBbtRPiC9cCC5pK4ZI2dMFwcl7CeoCLV0hl+YUz5Z0LrvetWXne 2fNOz3Zyt+WOz2uZiimrafSV0l/TMLhC0v+ywlMTRSBk8PE9s+QiRGnv0x/3ZkQP4vgV peTK0SE14kCno/aY7o/W63tZdEn62c3eoo5pLesy6dNR4Xc+PvLz8dyI/hyX3QQr7XKR lHrqh6fj73uGwbWb7Q/OwRqUWVAU0ghnAmPq8mu2PFtkXY6pNHJOEu6RxD+ZFnLaIHoy 9l2oZFP6ifnPTjLLlmS6UOTbQ6s3tq63E2bw5WfJDwFlPzG3yUkU3fr8LyNaZlocgHOy 63+g== X-Gm-Message-State: AOAM532NMD3R9opQluy9wnyWaQHNogT8BlWvqGLTm2g8k8XBN7nwhmr8 01yGR87kpJQNiAbtVOdDKWkcsw== X-Google-Smtp-Source: ABdhPJwRky0hQjfhy7S2TWsjjbDtiwwTKyghdg3XnYQgs9/VALZQwTYj5VtUaXn5s2lOxEs58ouw/A== X-Received: by 2002:a1c:2802:: with SMTP id o2mr9980762wmo.68.1610967696928; Mon, 18 Jan 2021 03:01:36 -0800 (PST) Received: from localhost (host86-166-129-230.range86-166.btcentralplus.com. [86.166.129.230]) by smtp.gmail.com with ESMTPSA id d13sm29100306wrx.93.2021.01.18.03.01.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jan 2021 03:01:36 -0800 (PST) Date: Mon, 18 Jan 2021 11:01:35 +0000 From: Andrew Burgess To: Fredrik Hederstierna Cc: Paul Mathieu , Simon Marchi , "gdb-patches@sourceware.org" Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi Message-ID: <20210118110135.GS265215@embecosm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Operating-System: Linux/5.8.13-100.fc31.x86_64 (x86_64) X-Uptime: 10:47:54 up 40 days, 15:32, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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, 18 Jan 2021 11:01:40 -0000 * Fredrik Hederstierna via Gdb-patches [2021-0= 1-14 12:36:35 +0000]: > 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 unde= rstanding. >=20 > I read recently about RISCV now seems to have merged corefile > support for their arch? This is not correct, I posted some patches for RISC-V bare metal core file support here: https://sourceware.org/pipermail/gdb-patches/2020-December/173714.html They have not yet been merged. > 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. Patches are not merged based on the popularity of a target, but on the commitment of an engineer to see the patch merged. You need to follow up to review comments and convince other members of the list that the patch is worth adding to GDB. > And it would be really good if synergy could be used to share code, > since alot functions I guess are same. That requires people to do the work, right? > If documentation is the issue, do we have an issue ticket on that? You're welcome to create one. Luis has made it clear he's going to object to the patch until he sees some documentation. If you want to get your patch merged you either need to write the documentation, convince someone else to write it, or convince Luis to drop that requirement. If you think having a ticket will help with any of the above steps, then go for it. But creating a ticket in itself doesn't get the docs written. >=20 > 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'? The problem is nobody really wants to write documentation, so if we do things that way, there's a pretty good chance the docs wont get written. Then either we (a) leave the feature in with no docs, or (b) rip the feature out just to make some kind of point. I think we should just decide up front if we are happy for it to be undocumented, or write the docs. > It seems to be about to > fail again if time just goes and none try push it further forward. GDB is maintained with volunteer effort. Nothing happens unless someone wants to it happen. So don't think of it as "failing", instead think that if the patch stalls its simply a reflection that demand for this feature is actually pretty low. Thanks, Andrew >=20 > Thanks! Kindly, > Fredrik >=20 > 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=20 > =A0 > Hi Fredrik, >=20 > > This is the current format when trying from ARM simulator: > > > > fredrik@legion ~/src/armv4t_coretest$ readelf -aA test.core > > ELF Header: > >=A0=A0 Magic:=A0=A0 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 > >=A0=A0 Class:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 ELF32 > >=A0=A0 Data:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 2's complement, little endian > >=A0=A0 Version:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 1 (current) > >=A0=A0 OS/ABI:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 ARM > >=A0=A0 ABI Version:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 0 > >=A0=A0 Type:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 CORE (Core file) > >=A0=A0 Machine:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 ARM > >=A0=A0 Version:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 0x1 > >=A0=A0 Entry point address:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0 > >=A0=A0 Start of program headers:=A0=A0=A0=A0=A0=A0=A0=A0=A0 52 (bytes in= to file) > >=A0=A0 Start of section headers:=A0=A0=A0=A0=A0=A0=A0=A0=A0 8084 (bytes = into file) > >=A0=A0 Flags:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0 > >=A0=A0 Size of this header:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 52= (bytes) > >=A0=A0 Size of program headers:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 32 (bytes) > >=A0=A0 Number of program headers:=A0=A0=A0=A0=A0=A0=A0=A0 5 > >=A0=A0 Size of section headers:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 40 (bytes) > >=A0=A0 Number of section headers:=A0=A0=A0=A0=A0=A0=A0=A0 7 > >=A0=A0 Section header string table index: 6 > > > > Section Headers: > >=A0=A0 [Nr] Name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Type=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Addr=A0=A0=A0=A0 Off=A0=A0=A0 Size=A0=A0 ES Flg Lk In= f Al > >=A0=A0 [ 0]=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 NULL= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 00000000 000000 000000 00=A0=A0=A0=A0=A0 = 0=A0=A0 0=A0 0 > >=A0=A0 [ 1] note0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 NOTE=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 00000000 001e44 000138 00=A0=A0 A=A0 0=A0=A0 0=A0 1 > >=A0=A0 [ 2] load=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PROGBITS=A0=A0= =A0=A0=A0=A0=A0 00010000 0000d4 000100 00=A0 AX=A0 0=A0=A0 0=A0 1 > >=A0=A0 [ 3] load=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PROGBITS=A0=A0= =A0=A0=A0=A0=A0 00080000 0001d4 000000 00=A0 WA=A0 0=A0=A0 0=A0 1 > >=A0=A0 [ 4] load=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PROGBITS=A0=A0= =A0=A0=A0=A0=A0 00080000 0001d4 000400 00=A0 WA=A0 0=A0=A0 0=A0 1 > >=A0=A0 [ 5] load=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PROGBITS=A0=A0= =A0=A0=A0=A0=A0 000fe790 0005d4 001870 00=A0 WA=A0 0=A0=A0 0=A0 1 > >=A0=A0 [ 6] .shstrtab=A0=A0=A0=A0=A0=A0=A0=A0 STRTAB=A0=A0=A0=A0=A0=A0= =A0=A0=A0 00000000 001f7c 000016 00=A0=A0=A0=A0=A0 0=A0=A0 0=A0 1 > > Key to Flags: > >=A0=A0 W (write), A (alloc), X (execute), M (merge), S (strings), I (inf= o), > >=A0=A0 L (link order), O (extra OS processing required), G (group), T (T= LS), > >=A0=A0 C (compressed), x (unknown), o (OS specific), E (exclude), > >=A0=A0 y (purecode), p (processor specific) > > > > There are no section groups in this file. > > > > Program Headers: > >=A0=A0 Type=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Offset=A0=A0 VirtAddr=A0=A0 Ph= ysAddr=A0=A0 FileSiz MemSiz=A0 Flg Align > >=A0=A0 NOTE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x001e44 0x00000000 0x00000000= 0x00138 0x00000 R=A0=A0 0x1 > >=A0=A0 LOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0000d4 0x00010000 0x00000000= 0x00100 0x00100 R E 0x1 > >=A0=A0 LOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0001d4 0x00080000 0x00000000= 0x00000 0x00000 RW=A0 0x1 > >=A0=A0 LOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0001d4 0x00080000 0x00000000= 0x00400 0x00400 RW=A0 0x1 > >=A0=A0 LOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0005d4 0x000fe790 0x00000000= 0x01870 0x01870 RW=A0 0x1 > > > >=A0 Section to Segment mapping: > >=A0=A0 Segment Sections... > >=A0=A0=A0 00 > >=A0=A0=A0 01=A0=A0=A0=A0 load > >=A0=A0=A0 02=A0=A0=A0=A0 load > >=A0=A0=A0 03=A0=A0=A0=A0 load load > >=A0=A0=A0 04=A0=A0=A0=A0 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: > >=A0=A0 Owner=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Data size= =A0=A0=A0=A0=A0=A0 Description > >=A0=A0 CORE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0000007c= =A0=A0=A0=A0=A0=A0 NT_PRPSINFO (prpsinfo structure) > >=A0=A0 CORE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x00000094= =A0=A0=A0=A0=A0=A0 NT_PRSTATUS (prstatus structure) >=20 > Does this support `.reg/xxx` notes for RTOS that support multiple tasks? > It would be really nice to have `info threads` "just work" >=20 > Paul