From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 1BC4638460B4 for ; Mon, 18 Jan 2021 11:09:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1BC4638460B4 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-wr1-x435.google.com with SMTP id l12so10811874wry.2 for ; Mon, 18 Jan 2021 03:09:25 -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=15pP1JLflvgOyUd6uyu9DdlT0hJposV6xWCoGRShJlE=; b=IMtGGbDPm8aNzOn8B/HBWohO316AzuwVC8QovPXFEEmpJPSboRsjpOVQYXlksxtjLt z4t3UhwTIrY8x4bDaUJ+8r/s/ekgE/PS6YXzoqiIN1vRPuV5TBKWzzUXcPFCBaC6rBo4 NBYr5wf9MbWenLoijTGhwj8XpfVImwyFv32RMwN8pP57EagjKAQ0hhM5mziloC8f/hBX WmR/WpamJRQ80z0Pm1HS/jmUEgwnX6KgVIB5B0ilejeZ2GezFGFtZ3s4iN+AzWCcw+rD brFT0hdFm3Bl5syCX49iHb02nt0P+EuUMQ5te4KVYRyU9V0F+EzmVImAhrznteq04nYe uzIg== 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=15pP1JLflvgOyUd6uyu9DdlT0hJposV6xWCoGRShJlE=; b=BZ4aESQYTwwBN10ateHNbbtyVG5yKkkJaDQWtoa/Jwq0ngiXrSUKvQdw4dPR5PkjWZ 40jNNieer5TodNErQMQlUr4izoDGqcIG4cRQPRUYMpLTnrYgQk0zvPZg1YMXeZhYXIob EzlDNUWz9vrGiatTjFl3KD5wck9owhf8zgqlQdBGKTDbof88k/z6MCxAHL555qKkmwA9 De3OryONBl+O2TN6Y43SSNMsHREj4CUsVcDIi1IddxsPQJfF9LbA7Vmczfmt1B8u8cF+ g3AXex06MN6ORintJNJ0aLb7Yal/NDZzQ4HbFzYaR+f4wfsIQ3zFWUMUEQAhaqJiHC7a HpNg== X-Gm-Message-State: AOAM530nSkEiMBJ9+0iULHSKxHEZ3s++g4enTLfVobhyHZsPvyIqoSkH 03O8+aQtRG5AW2NL2Sz7C8bl/g== X-Google-Smtp-Source: ABdhPJxfgadzDSL7KSQct2B0r+FNqbuHXfzR6HVpv8SwfpAx7wh17vUWZcVEJt91KMZrgU9Wx6hs2Q== X-Received: by 2002:adf:ba8b:: with SMTP id p11mr25247350wrg.328.1610968164215; Mon, 18 Jan 2021 03:09:24 -0800 (PST) Received: from localhost (host86-166-129-230.range86-166.btcentralplus.com. [86.166.129.230]) by smtp.gmail.com with ESMTPSA id x18sm33317069wrg.55.2021.01.18.03.09.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jan 2021 03:09:23 -0800 (PST) Date: Mon, 18 Jan 2021 11:09:22 +0000 From: Andrew Burgess To: Luis Machado Cc: Fredrik Hederstierna , Paul Mathieu , Simon Marchi , "gdb-patches@sourceware.org" Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi Message-ID: <20210118110922.GT265215@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: 11:01:40 up 40 days, 15:46, 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:09:27 -0000 * Luis Machado via Gdb-patches [2021-01-14 09:= 50:42 -0300]: > Hi, >=20 > 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 un= derstanding. > >=20 > > I read recently about RISCV now seems to have merged corefile support f= or their arch? >=20 > The idea was to establish a common ground that could be used for both RIS= CV > and ARM, and prevent design issues from getting in the way. >=20 > 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 th= at > 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. 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. >=20 > > 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, sin= ce alot functions I guess are same. > > If documentation is the issue, do we have an issue ticket on that? >=20 > 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 was= n'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. 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. Thanks, Andrew >=20 > >=20 > > Can we just merge this patch-v4 and set target GDB-11, and solve the do= c-issue-ticket, then we just force ourselves to solve docs before the relea= se, > > or how can we 'make it happen'? It seems to be about to fail again if t= ime just goes and none try push it further forward. >=20 > 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. >=20 > >=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-no= ne-eabi > > Hi Fredrik, > >=20 > > > This is the current format when trying from ARM simulator: > > >=20 > > > 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 (byte= s into file) > > > =A0=A0 Start of section headers:=A0=A0=A0=A0=A0=A0=A0=A0=A0 8084 (by= tes 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 (by= tes) > > > =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 (by= tes) > > > =A0=A0 Number of section headers:=A0=A0=A0=A0=A0=A0=A0=A0 7 > > > =A0=A0 Section header string table index: 6 > > >=20 > > > 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 Inf Al > > > =A0=A0 [ 0]=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 NU= LL=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 = (info), > > > =A0=A0 L (link order), O (extra OS processing required), G (group), = T (TLS), > > > =A0=A0 C (compressed), x (unknown), o (OS specific), E (exclude), > > > =A0=A0 y (purecode), p (processor specific) > > >=20 > > > There are no section groups in this file. > > >=20 > > > Program Headers: > > > =A0=A0 Type=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Offset=A0=A0 VirtAddr=A0= =A0 PhysAddr=A0=A0 FileSiz MemSiz=A0 Flg Align > > > =A0=A0 NOTE=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x001e44 0x00000000 0x0000= 0000 0x00138 0x00000 R=A0=A0 0x1 > > > =A0=A0 LOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0000d4 0x00010000 0x0000= 0000 0x00100 0x00100 R E 0x1 > > > =A0=A0 LOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0001d4 0x00080000 0x0000= 0000 0x00000 0x00000 RW=A0 0x1 > > > =A0=A0 LOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0001d4 0x00080000 0x0000= 0000 0x00400 0x00400 RW=A0 0x1 > > > =A0=A0 LOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0x0005d4 0x000fe790 0x0000= 0000 0x01870 0x01870 RW=A0 0x1 > > >=20 > > > =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 > > >=20 > > > 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. > > >=20 > > > Displaying notes found at file offset 0x00001e44 with length 0x000001= 38: > > > =A0=A0 Owner=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Data si= ze=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 0x000000= 7c=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 0x000000= 94=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 > >=20