On Thu, Jan 10, 2019 at 4:29 AM Christopher Head <[email protected]> wrote:
> On January 9, 2019 2:46:13 PM PST, Tommy Murphy <[email protected]> > wrote: > >Surely this is something that the target OS needs to support rather > >than OpenOCD? > > I think it makes perfect sense in the context of a microcontroller. There > may not *be* a target OS. What’s in a core dump? Memory. OpenOCD is good at > reading that from the target. CPU registers. OpenOCD is good at reading > those, too. Threads. If a supported RTOS is in use, OpenOCD is good there > too. I see no reason why this doesn’t make sense. No need to talk about > semihosting. > > Would be nice but I do think that should be handled by GDB and not by OpenOCD. There is in fact a generate-core-file command in GDB for exactly that purpose, which sadly seems to work for only specific combinations of platforms and target OSes. GDB already has the ability to query the whole of the target state and it knows the core file format it expects so I don't see why that knowledge should be duplicated in OpenOCD. Better to extend GDB to be able to create the core file even for OS-less bare metal targets in a generic way. I'm not sure if threads are part of the core file data. If they're not, GDB would not be able to interpret them from the core file without help from OpenOCD. /Andreas
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
