Postmortem debugging with arm-none-eabi-gdb from memory dump (not core)

Postmortem debugging with arm-none-eabi-gdb from memory dump (not core)

[Hesham M]

Hi all,

As this is my first email to the list, and as an old user for gdb, I'd like
first to thank the gdb community for their effort.

In a bare-metal ARM system, is there a way to use arm-none-eabi-gdb for
postmortem debugging, the same way we do when we debug with core file on
Linux, for example?

The issue is that I don't have a "core" file but I can generate memory dump
of the whole memory (ROM is already known and through the hardware debugger
used I can write the RAM contents to a file (outside the target of course).
I can also collect the registers at the time of the crash. I can do the
debugging/analysis if I connect gdb to the target at the time of the crash
but I need to do this in later time away from the target. I hope to find a
way to debug with memory dumps the same way gdb debugs with core files.

Of course if I can convert the memory dump to a valid core file, it might
be another path to the solution. I don't know how to do that or if there is
a tool that can help with this conversion.

Any idea if this is possible?

A variant of this is idea is done for Keil tools:
https://os.mbed.com/blog/entry/Post-mortem-debugging-with-ARM-mbed/

I have posted a similar question on stackoverflow but they closed it! So,
please let me know if my question isn't clear.

Thanks,
-Hesham

Re: Postmortem debugging with arm-none-eabi-gdb from memory dump (not core)

[Hesham M]

Hi,

I'm still looking for guidance or pointers that may help with this issue.

Thanks,
-Hesham

On Thu, Oct 5, 2017 at 5:55 AM, Hesham M <hesham.eembedded@gmail.com> wrote:

> Hi all,
>
> As this is my first email to the list, and as an old user for gdb, I'd
> like first to thank the gdb community for their effort.
>
> In a bare-metal ARM system, is there a way to use arm-none-eabi-gdb for
> postmortem debugging, the same way we do when we debug with core file on
> Linux, for example?
>
> The issue is that I don't have a "core" file but I can generate memory
> dump of the whole memory (ROM is already known and through the hardware
> debugger used I can write the RAM contents to a file (outside the target of
> course). I can also collect the registers at the time of the crash. I can
> do the debugging/analysis if I connect gdb to the target at the time of the
> crash but I need to do this in later time away from the target. I hope to
> find a way to debug with memory dumps the same way gdb debugs with core
> files.
>
> Of course if I can convert the memory dump to a valid core file, it might
> be another path to the solution. I don't know how to do that or if there is
> a tool that can help with this conversion.
>
> Any idea if this is possible?
>
> A variant of this is idea is done for Keil tools:
> https://os.mbed.com/blog/entry/Post-mortem-debugging-with-ARM-mbed/
>
> I have posted a similar question on stackoverflow but they closed it! So,
> please let me know if my question isn't clear.
>
> Thanks,
> -Hesham
>

Re: Postmortem debugging with arm-none-eabi-gdb from memory dump (not core)

[Yao Qi]

On 17-10-05 05:55:38, Hesham M wrote:
> Hi all,
> 
> As this is my first email to the list, and as an old user for gdb, I'd like
> first to thank the gdb community for their effort.
> 
> In a bare-metal ARM system, is there a way to use arm-none-eabi-gdb for
> postmortem debugging, the same way we do when we debug with core file on
> Linux, for example?
> 
> The issue is that I don't have a "core" file but I can generate memory dump
> of the whole memory (ROM is already known and through the hardware debugger
> used I can write the RAM contents to a file (outside the target of course).
> I can also collect the registers at the time of the crash. I can do the
> debugging/analysis if I connect gdb to the target at the time of the crash
> but I need to do this in later time away from the target. I hope to find a
> way to debug with memory dumps the same way gdb debugs with core files.
> 
> Of course if I can convert the memory dump to a valid core file, it might
> be another path to the solution. I don't know how to do that or if there is
> a tool that can help with this conversion.
> 
> Any idea if this is possible?

I prefer this approach, and it is possible.  GDB has a command "gcore",
https://sourceware.org/gdb/current/onlinedocs/gdb/Core-File-Generation.html#index-generate_002dcore_002dfile
you can take a loop how GDB does it.

> 
> A variant of this is idea is done for Keil tools:
> https://os.mbed.com/blog/entry/Post-mortem-debugging-with-ARM-mbed/
> 
> I have posted a similar question on stackoverflow but they closed it! So,
> please let me know if my question isn't clear.
> 
> Thanks,
> -Hesham

-- 
Yao (齐尧)

Re: Postmortem debugging with arm-none-eabi-gdb from memory dump (not core)

[Hesham M]

On Fri, Oct 13, 2017 at 4:19 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
> On 17-10-05 05:55:38, Hesham M wrote:
>> Hi all,
>>
>> As this is my first email to the list, and as an old user for gdb, I'd like
>> first to thank the gdb community for their effort.
>>
>> In a bare-metal ARM system, is there a way to use arm-none-eabi-gdb for
>> postmortem debugging, the same way we do when we debug with core file on
>> Linux, for example?
>>
>> The issue is that I don't have a "core" file but I can generate memory dump
>> of the whole memory (ROM is already known and through the hardware debugger
>> used I can write the RAM contents to a file (outside the target of course).
>> I can also collect the registers at the time of the crash. I can do the
>> debugging/analysis if I connect gdb to the target at the time of the crash
>> but I need to do this in later time away from the target. I hope to find a
>> way to debug with memory dumps the same way gdb debugs with core files.
>>
>> Of course if I can convert the memory dump to a valid core file, it might
>> be another path to the solution. I don't know how to do that or if there is
>> a tool that can help with this conversion.
>>
>> Any idea if this is possible?
>
> I prefer this approach, and it is possible.  GDB has a command "gcore",
> https://sourceware.org/gdb/current/onlinedocs/gdb/Core-File-Generation.html#index-generate_002dcore_002dfile
> you can take a loop how GDB does it.
>
>>
>> A variant of this is idea is done for Keil tools:
>> https://os.mbed.com/blog/entry/Post-mortem-debugging-with-ARM-mbed/
>>
>> I have posted a similar question on stackoverflow but they closed it! So,
>> please let me know if my question isn't clear.
>>
>> Thanks,
>> -Hesham
>
> --
> Yao (齐尧)


Hi Yao,

Thanks for replying. Unfortunately, gcore is not implemented for
bare-metal ARM, arm-none-eabi-gdb.
GDB documentation says abour gcore:

Note that this command is implemented only for some systems (as of
this writing, GNU/Linux, FreeBSD, Solaris, and S390).


Trying it on my system, I got:

(gdb) gcore file
Command not implemented for this target.

I appreciate any ideas or hints.

Thanks,
-Hesham

Re: Postmortem debugging with arm-none-eabi-gdb from memory dump (not core)

[Christian Gagneraud]

On 14 October 2017 at 21:52, Hesham M <hesham.eembedded@gmail.com> wrote:
> On Fri, Oct 13, 2017 at 4:19 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
>> On 17-10-05 05:55:38, Hesham M wrote:
>>> Hi all,
>>>
>>> As this is my first email to the list, and as an old user for gdb, I'd like
>>> first to thank the gdb community for their effort.
>>>
>>> In a bare-metal ARM system, is there a way to use arm-none-eabi-gdb for
>>> postmortem debugging, the same way we do when we debug with core file on
>>> Linux, for example?
>>>
>>> The issue is that I don't have a "core" file but I can generate memory dump
>>> of the whole memory (ROM is already known and through the hardware debugger
>>> used I can write the RAM contents to a file (outside the target of course).
>>> I can also collect the registers at the time of the crash. I can do the
>>> debugging/analysis if I connect gdb to the target at the time of the crash
>>> but I need to do this in later time away from the target. I hope to find a
>>> way to debug with memory dumps the same way gdb debugs with core files.
>>>
>>> Of course if I can convert the memory dump to a valid core file, it might
>>> be another path to the solution. I don't know how to do that or if there is
>>> a tool that can help with this conversion.
>>>
>>> Any idea if this is possible?
>>
>> I prefer this approach, and it is possible.  GDB has a command "gcore",
>> https://sourceware.org/gdb/current/onlinedocs/gdb/Core-File-Generation.html#index-generate_002dcore_002dfile
>> you can take a loop how GDB does it.

Core dump are just ELF files, you might be able to create one yourself:
https://stackoverflow.com/questions/5986366/elf-core-file-format


>>
>>>
>>> A variant of this is idea is done for Keil tools:
>>> https://os.mbed.com/blog/entry/Post-mortem-debugging-with-ARM-mbed/
>>>
>>> I have posted a similar question on stackoverflow but they closed it! So,
>>> please let me know if my question isn't clear.

Do you have a link to this SO question?

Chris

Re: Postmortem debugging with arm-none-eabi-gdb from memory dump (not core)

[Hesham M]

On Sun, Oct 15, 2017 at 4:11 AM, Christian Gagneraud <chgans@gmail.com> wrote:
> On 14 October 2017 at 21:52, Hesham M <hesham.eembedded@gmail.com> wrote:
>> On Fri, Oct 13, 2017 at 4:19 PM, Yao Qi <qiyaoltc@gmail.com> wrote:
>>> On 17-10-05 05:55:38, Hesham M wrote:
>>>> Hi all,
>>>>
>>>> As this is my first email to the list, and as an old user for gdb, I'd like
>>>> first to thank the gdb community for their effort.
>>>>
>>>> In a bare-metal ARM system, is there a way to use arm-none-eabi-gdb for
>>>> postmortem debugging, the same way we do when we debug with core file on
>>>> Linux, for example?
>>>>
>>>> The issue is that I don't have a "core" file but I can generate memory dump
>>>> of the whole memory (ROM is already known and through the hardware debugger
>>>> used I can write the RAM contents to a file (outside the target of course).
>>>> I can also collect the registers at the time of the crash. I can do the
>>>> debugging/analysis if I connect gdb to the target at the time of the crash
>>>> but I need to do this in later time away from the target. I hope to find a
>>>> way to debug with memory dumps the same way gdb debugs with core files.
>>>>
>>>> Of course if I can convert the memory dump to a valid core file, it might
>>>> be another path to the solution. I don't know how to do that or if there is
>>>> a tool that can help with this conversion.
>>>>
>>>> Any idea if this is possible?
>>>
>>> I prefer this approach, and it is possible.  GDB has a command "gcore",
>>> https://sourceware.org/gdb/current/onlinedocs/gdb/Core-File-Generation.html#index-generate_002dcore_002dfile
>>> you can take a loop how GDB does it.
>
> Core dump are just ELF files, you might be able to create one yourself:
> https://stackoverflow.com/questions/5986366/elf-core-file-format
>
>
>>>
>>>>
>>>> A variant of this is idea is done for Keil tools:
>>>> https://os.mbed.com/blog/entry/Post-mortem-debugging-with-ARM-mbed/
>>>>
>>>> I have posted a similar question on stackoverflow but they closed it! So,
>>>> please let me know if my question isn't clear.
>
> Do you have a link to this SO question?
>
> Chris

Hi Chris,

Thank for your reply. I know core is an elf file but it'd be helpful
if there is a tool that can help or something in gdb that I can use
instead of reinventing the wheel.
If this is the only resort, I might need to do it. If this can be
included somehow in GDB, provided nothing can do that now and there is
interest in this, I can try to help. I'd need community support,
though, as I haven't done any gdb work before.

My deleted SO question link:
https://stackoverflow.com/questions/46374391/postmortem-debugging-with-gdb-from-memory-dump-not-core

Thanks,
-Hesham