public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Fredrik Hederstierna <fredrik.hederstierna@verisure.com>
To: Luis Machado <luis.machado@linaro.org>,
	Simon Marchi <simark@simark.ca>,
	Paul Mathieu <paulmathieu@google.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi
Date: Mon, 26 Oct 2020 15:49:15 +0000	[thread overview]
Message-ID: <AM6PR10MB2150E67FB03ECBFFD18D4856EF190@AM6PR10MB2150.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <f914bb4d-e523-d19a-4f3f-9e3a9c9ef827@linaro.org>

> From: Luis Machado <luis.machado@linaro.org>
> Sent: Monday, October 26, 2020 12:24 PM
> 
>>> 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://urldefense.com/v3/__https://sourceware.org/pipermail/gdb-patches/2020-October/172721.html__;!!BFCLnRDDbM3FOmw!sNi8byoH5SSID20XZ9bMNX2DOjXF4ZJcrHvYbpgAnuXp0WCSVEiMdf2v2kNX1j4uVrbATpFt$ ). 
> 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.

Yes, agree, re-engineering is not preferred design,
and the Linux format is far more complex that what a none-corefile would need probably.
I tried to strip out everything but 'memory' and 'registers',
so the none corefile should be a regular valid ELF file, with memory and registers only I guess.

I tried to find a good specification/documentation source for corefiles, but it is not very clear where to look...
Found this as a starting point
https://stackoverflow.com/questions/5986366/elf-core-file-format

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)

/Fredrik

  reply	other threads:[~2020-10-26 15:49 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-17  0:02 Fredrik Hederstierna
2020-10-19  2:08 ` Simon Marchi
2020-10-19 13:13   ` Luis Machado
2020-10-19 13:15   ` Alan Hayward
2020-10-19 15:25   ` Paul Mathieu
2020-10-20 11:41     ` Fredrik Hederstierna
2020-10-20 12:39       ` Simon Marchi
2020-10-20 14:00         ` Fredrik Hederstierna
2020-10-20 15:04           ` Simon Marchi
2020-10-20 22:05             ` Fredrik Hederstierna
2020-10-20 23:06               ` Simon Marchi
2020-10-22  0:52                 ` Fredrik Hederstierna
2020-10-22  1:24                   ` Simon Marchi
2020-10-22  1:49                   ` Simon Marchi
2020-10-22 22:32                     ` Fredrik Hederstierna
2020-10-23  0:37                       ` Simon Marchi
2020-10-25 21:06                         ` Fredrik Hederstierna
2020-10-26 11:24                           ` Luis Machado
2020-10-26 15:49                             ` Fredrik Hederstierna [this message]
2020-10-27 16:53                               ` Paul Mathieu
2021-01-14 12:36                                 ` Fredrik Hederstierna
2021-01-14 12:50                                   ` Luis Machado
2021-01-18 11:09                                     ` Andrew Burgess
2021-01-18 14:01                                       ` Luis Machado
2021-06-21  6:30                                         ` [PATCH] sim: arm: add support for handling core dumps Fredrik Hederstierna
2021-06-22  3:20                                           ` Mike Frysinger
2021-06-24 13:01                                             ` Alan Hayward
2021-06-29  9:11                                               ` Fredrik Hederstierna
2021-01-18 11:01                                   ` [PATCH] gdb: add support for handling core dumps on arm-none-eabi Andrew Burgess
2021-06-22  2:16                           ` Mike Frysinger
2020-10-20 19:34       ` [PATCH] gdb: Support corefiles for arm-none-eabi Fredrik Hederstierna
2020-10-20 21:49       ` Fredrik Hederstierna
2020-10-20 21:58       ` [PATCH v2] Support for corefiles for arm-none-eabi target Fredrik Hederstierna
2020-10-21  2:51         ` Simon Marchi
2020-10-21 14:38         ` Luis Machado
2020-10-22  0:44       ` [PATCH v3][PR gdb/14383]: gdb: corefile support " Fredrik Hederstierna
2020-10-22  0:44         ` [PATCH v3][PR gdb/14383]: Support for corefiles " Fredrik Hederstierna
2020-10-25 20:46       ` [PATCH] " Fredrik Hederstierna
2020-10-25 20:50       ` [PATCH v4][PR gdb/14383] " Fredrik Hederstierna
  -- strict thread matches above, loose matches on Subject: below --
2020-10-02 17:32 [PATCH] gdb: add support for handling core dumps on arm-none-eabi Paul Mathieu
2020-10-02 17:51 ` Luis Machado
2020-10-02 21:54   ` Paul Mathieu
2020-10-02 21:59     ` Simon Marchi
2020-10-03  3:57     ` Simon Marchi
2020-10-02 23:55 ` Simon Marchi
2020-10-03  0:35   ` Paul Mathieu
2020-10-03  2:24     ` Simon Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM6PR10MB2150E67FB03ECBFFD18D4856EF190@AM6PR10MB2150.EURPRD10.PROD.OUTLOOK.COM \
    --to=fredrik.hederstierna@verisure.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@linaro.org \
    --cc=paulmathieu@google.com \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).