This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: arm core analysis on x86 host
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