This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Coredump facility for Deeply Embedded Systems.


So I have lots of deeply embedded systems in test racks.

No debug connectors, only serial ports.

So it would be useful to revert to Ye Olde 1960's technology.... a coredump.

Alas, I have no support from my RTOS (eCos) to create a coredump.

So I have written a pair of handy facilities that takes me part of the
way... (which I would be glad to contribute back to the community)

Getting the "coredump" data out of a deeply embedded system.
============================================================

The first part is RLEZ, which streams out my whole .bss and .data segments,
plus some  memory mapped registers etc.

It is trivial to integrate this facility with your embedded exception
handler of last
resort.

All you have to do is define a function RLEZ_SquirtChar( uint_8 _t ch)
to squirt a
character out the serial port of your choice.

Then invoking RLEZ( uint8_t const * start, uint8_t const * end) streams all
data from start to end in a very simple, framed compressed and escaped
manner.

It does a couple of useful things like creates frames of the form
 [[ address [ rlez encoded data \n

Where '[' is the frame start marker, "\n" is the end of frame marker and
the address and data is transparently escaped to hide all incidentally
frame markers and xon and xoff.

Since .bss often has lots of nulls, I also run length compress zeroes.
Speeds things up by about a factor of 6.

>From RLEZ to srec
=================

I assume the other end of the serial port is attached to a PC or a log file
or ....

So as a post analysis step I have a facility that scans an arbitary log
file RLEZ frames, and decodes them into address / binary array packets and
outputs them as Motorola S3 srec records.

The binutil objcopy can juggle srecs.

(eg. I can use gdb "load file" to load these srecs into the ram of a
debugger connected development version of the hardware.)

>From srec's to core files.
==========================

This is the missing part of the puzzle.

I can't find a definition of the "coredump" format.

There seems to be a partial implementation within the gdb "gcore"
command... but it seems to barf complaining unsupported file format.

What I would like to do now, with your help, is add to binutils objcopy the
facility to transcode srecs to coredumps. (Alternately to teach gdb to
accept srecs or binary as a "source of truth" volatile / ram data for
corefiles.)

My basic plan of attack is to take the gdb-7.5/gdb/gcore.c file and splice
it into binutils as yet another output format.

Yup, I'm aware there are "problematic" elements about this agenda... for
example "S3 srecs" are all about data values are at which address. And core
files need to have knowledge of CPU registers.

As a first pass it would be sort of gnice to by pass the whole register
file problem.

So....
1) Any suggestions?
2) Any hints to pre-existing projects / code?
3) What would be the best way to feed this facility back into the
binutils and/or gdb project.
4) Anybody want to play with?

Thank you.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]