Re: Questions on how to implement native core file support

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Wed, 22 Apr 2009 12:18:33 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Hello,
> 
> While looking at expunging REGISTER_U_ADDR from our documentation
> (no longer used), I found out that the documentation about how to
> provide core file support is out of date (core-aout has been deleted
> a year ago).
> 
> Having never written support for core file reading, I have tried
> to figure out how to add it.  As far as I can tell, I can see
> two forms of core file support:
> 
>   1. Native core file support
>   2. gdbarch core file support
> 
> In the second case, it appears that all you have to do is define
> the gdbarch_regset_from_core_section method for your architecture,
> and I would guess that this is the prefered method.  However, may
> not be always doable, in particular if you depend on certain 
> system headers... Any other possible reason?

You never have to depend on system headers.  The right thing to do is
add support to BFD for the core file format in question.  That code
should compile on any system, and relevant constants and data
structures should go in a header file in the toplevel include
directory.  After that, writing the appropriate
gdbarch_regset_from_core_section() function is all that's needed on
the GDB side.

We certainly should avoid adding more "native core file support" code.

> In the first case, it looks like core_low is relying on
> a struct core_fns which is provides pointers to various
> target-dependent routines. The thing is, the routine I see
> in order to register a particular instance is marked as
> deprecated:
> 
>     extern void deprecated_add_core_fns (struct core_fns *cf);
> 
> Does it mean that, as of today, we only consider the second
> gdbarch-based approach? If that's the case, then should we simply
> update the documentation to either remove the "Native core file Support"
> section, or replace it with a link to gdbarch_regset_from_core_section?

I think so.