Re: arm core analysis on x86 host

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 29, 2005 at 11:13:53AM -0500, Jon Ringle wrote:
> On Monday 28 March 2005 23:58, Daniel Jacobowitz wrote:
> > On Mon, Mar 28, 2005 at 11:17:14PM -0500, Jon Ringle wrote:
> > > I am now using as an example ppc-linux-tdep.c, however it still seems
> > > that a call to deprecated_add_core_fns() is needed. When I use a 'target
> > > core /path/to/core' command, core_open() gets called which calls
> > > sniff_core_bfd(). sniff_core_bfd() has a loop to iterate over
> > > core_file_fns, which as far as I can tell gets populated via
> > > deprecated_add_core_fns(). I don't see how else core_file_fns gets
> > > populated. Am I misunderstanding the use of 'deprecated' here? My
> > > understanding of the word is that use is no longer desired in favor of a
> > > (hopefully) better solution or archetecture.
> >
> > Look harder :-)  sniff_core_bfd is disabled if you provide the new
> > mechanism.  It should be all you need.
> 
> I assume that you are refering to the test that is done at the beginning of 
> sniff_core_bfd():
>   /* Don't sniff if we have support for register sets in CORE_GDBARCH.  */
>   if (core_gdbarch && gdbarch_regset_from_core_section_p (core_gdbarch))
>     return NULL;
> 
> Howerver, the value of core_gdbarch is not the same as the gdbarch that was 
> used for the set_gdbarch_regset_from_core_section() causing the test to fail 
> and fall through to the core_file_fns loop.

The two being different is not a problem; however, the question is why
they are so different that they do not both pass through wherever you
are calling set_gdbarch_regset_from_core_section.

At least two gdbarches will be constructed before the core file is
opened, but you only show one call to
set_gdbarch_regset_from_core_section.

Where did you put it?

-- 
Daniel Jacobowitz
CodeSourcery, LLC