arm core analysis on x86 host

arm core analysis on x86 host

[Jon Ringle]

Hello,

I'm trying to analyze an arm core dump on an x86 host and I get the error when 
using the core command:
	GDB can't read core files on this machine.

The error message is coming because find_core_target() is returning NULL, and 
it's returning NULL because it can't find a match for
	(*t)->to_stratum == core_stratum

I find that the only place that core_stratum gets used to set to_stratum is in 
init_core_ops(), which gets called by _initialize_corelow(). However, I can't 
find any code that calls _initialize_corelow().

1) Can the current gdb analyze an arm core dump?
2) If not, I would appreciate some pointers to help me add this support.

Thanks,

Jon

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

On Mon, Mar 28, 2005 at 06:29:19PM -0500, Jon Ringle wrote:
> Hello,
> 
> I'm trying to analyze an arm core dump on an x86 host and I get the error when 
> using the core command:
> 	GDB can't read core files on this machine.
> 
> The error message is coming because find_core_target() is returning NULL, and 
> it's returning NULL because it can't find a match for
> 	(*t)->to_stratum == core_stratum
> 
> I find that the only place that core_stratum gets used to set to_stratum is in 
> init_core_ops(), which gets called by _initialize_corelow(). However, I can't 
> find any code that calls _initialize_corelow().

It's called from init.c, which is a generated file, if it is included in
the gdb build.  See the .mh and .mt files.

> 1) Can the current gdb analyze an arm core dump?
> 2) If not, I would appreciate some pointers to help me add this support.

Take a look at any target which registers core functions in a tdep
file, instead of a nat file.  arm-linux still does it in the nat file.
That just needs to be fixed.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm core analysis on x86 host

[Jon Ringle]

On Monday 28 March 2005 18:57, Daniel Jacobowitz wrote:
> On Mon, Mar 28, 2005 at 06:29:19PM -0500, Jon Ringle wrote:
> > 1) Can the current gdb analyze an arm core dump?
> > 2) If not, I would appreciate some pointers to help me add this support.
>
> Take a look at any target which registers core functions in a tdep
> file, instead of a nat file.  arm-linux still does it in the nat file.
> That just needs to be fixed.

I looked at mips-linux-tdep.c as an example and it uses:
	deprecated_add_core_fns (&regset_core_fns);

Is there a non-deprecated version I should be use instead? Is there a better 
example to follow?

Jon

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

On Mon, Mar 28, 2005 at 07:48:44PM -0500, Jon Ringle wrote:
> On Monday 28 March 2005 18:57, Daniel Jacobowitz wrote:
> > On Mon, Mar 28, 2005 at 06:29:19PM -0500, Jon Ringle wrote:
> > > 1) Can the current gdb analyze an arm core dump?
> > > 2) If not, I would appreciate some pointers to help me add this support.
> >
> > Take a look at any target which registers core functions in a tdep
> > file, instead of a nat file.  arm-linux still does it in the nat file.
> > That just needs to be fixed.
> 
> I looked at mips-linux-tdep.c as an example and it uses:
> 	deprecated_add_core_fns (&regset_core_fns);
> 
> Is there a non-deprecated version I should be use instead? Is there a better 
> example to follow?

Try anything using set_gdbarch_regset_from_core_section.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm core analysis on x86 host

[Jon Ringle]

On Monday 28 March 2005 18:57, Daniel Jacobowitz wrote:
> On Mon, Mar 28, 2005 at 06:29:19PM -0500, Jon Ringle wrote:
> > I find that the only place that core_stratum gets used to set to_stratum
> > is in init_core_ops(), which gets called by _initialize_corelow().
> > However, I can't find any code that calls _initialize_corelow().
>
> It's called from init.c, which is a generated file, if it is included in
> the gdb build.  See the .mh and .mt files.

Ok. I added corelow.o to gdb/config/arm/linux.mt and now _initialize_corelow() 
is being called.

> > On Monday 28 March 2005 18:57, Daniel Jacobowitz wrote:
> > > Take a look at any target which registers core functions in a tdep
> > > file, instead of a nat file.  arm-linux still does it in the nat file.
> > > That just needs to be fixed.
> >
> > I looked at mips-linux-tdep.c as an example and it uses:
> >      deprecated_add_core_fns (&regset_core_fns);
> >
> > Is there a non-deprecated version I should be use instead? Is there a
> > better example to follow?
> Try anything using set_gdbarch_regset_from_core_section.

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.

Jon

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm core analysis on x86 host

[Jon Ringle]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

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.

Here is a gdb session:


[-- Attachment #2: typescript --]
[-- Type: text/plain, Size: 4753 bytes --]

[ringlej@heavymobile gdb]$ cat topgdb-bp
b set_gdbarch_regset_from_core_section
b gdbarch_regset_from_core_section
b gdbarch_regset_from_core_section_p
b corelow.c:350

[ringlej@heavymobile gdb]$ cat gdbcoreinit
cd /home/ringlej/mp1000/trunk-fixes/Soundpipe/ippbx
set solib-search-path /usr/arm-linux/lib
set solib-absolute-prefix /usr/arm-linux/lib
set radix 16
directory ../sysutil ../pstngw ../sipgw ../phonemgr ../callthd ../Microsip2 ../parkgw ../ringgw
file ippbx.gdb
target core ./core

[ringlej@heavymobile gdb]$ gdb -x topgdb-bp gdb
GNU gdb 6.2-2mdk (Mandrakelinux)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

Setting up the environment for debugging gdb.
Breakpoint 1 at 0x805cc73: file ../../src/gdb/utils.c, line 817.
Breakpoint 2 at 0x8086a35: file ../../src/gdb/cli/cli-cmds.c, line 193.
Breakpoint 3 at 0x80fcce2: file ../../src/gdb/gdbarch.c, line 3683.
Breakpoint 4 at 0x80fcc38: file ../../src/gdb/gdbarch.c, line 3672.
Breakpoint 5 at 0x80fcbeb: file ../../src/gdb/gdbarch.c, line 3665.
Breakpoint 6 at 0x806bae2: file ../../src/gdb/corelow.c, line 350.
(top-gdb) run -n -x gdbcoreinit
Starting program: /home/ringlej/gdb-cvs/arm/gdb/gdb -x gdbcoreinit
Backtrace limit of 50 exceeded
Backtrace limit of 50 exceeded

Breakpoint 3, set_gdbarch_regset_from_core_section (gdbarch=0x848d2e8, regset_from_core_section=0x8068a47 <arm_linux_regset_from_core_section>) at ../../src/gdb/gdbarch.c:3683
3683	  gdbarch->regset_from_core_section = regset_from_core_section;
(top-gdb) n
Backtrace limit of 50 exceeded
During symbol reading, Incomplete CFI data; unspecified registers at 0x080fcce2.
set_gdbarch_regset_from_core_section (gdbarch=0x848d2e8, regset_from_core_section=0x8068a47 <arm_linux_regset_from_core_section>) at ../../src/gdb/gdbarch.c:3684
3684	}
(top-gdb) p gdbarch
$1 = (struct gdbarch *) 0x848d2e8
(top-gdb) p gdbarch->regset_from_core_section
$2 = (gdbarch_regset_from_core_section_ftype *) 0x8068a47 <arm_linux_regset_from_core_section>
(top-gdb) c
Continuing.
GNU gdb 6.3.50.20050328-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux".
Backtrace limit of 50 exceeded

Breakpoint 6, core_open (filename=0x8495658 "/home/ringlej/mp1000/trunk-fixes/Soundpipe/ippbx/./core", from_tty=0) at ../../src/gdb/corelow.c:350
350	  core_vec = sniff_core_bfd (core_bfd);
(top-gdb) p core_bfd
$3 = (bfd *) 0x849caf0
(top-gdb) s
Backtrace limit of 50 exceeded
sniff_core_bfd (abfd=0x8495658) at ../../src/gdb/corelow.c:138
138	{
(top-gdb) n
Backtrace limit of 50 exceeded
sniff_core_bfd (abfd=0x849caf0) at ../../src/gdb/corelow.c:140
140	  struct core_fns *yummy = NULL;
(top-gdb) n
Backtrace limit of 50 exceeded
sniff_core_bfd (abfd=0x849caf0) at ../../src/gdb/corelow.c:141
141	  int matches = 0;;
(top-gdb) n
Backtrace limit of 50 exceeded
sniff_core_bfd (abfd=0x849caf0) at ../../src/gdb/corelow.c:144
144	  if (core_gdbarch && gdbarch_regset_from_core_section_p (core_gdbarch))
(top-gdb) p core_gdbarch
$4 = (struct gdbarch *) 0x85723d0
(top-gdb) n
Backtrace limit of 50 exceeded
gdbarch_regset_from_core_section_p (gdbarch=0x849caf0) at ../../src/gdb/gdbarch.c:3664
3664	{
(top-gdb) n
Backtrace limit of 50 exceeded

Breakpoint 5, gdbarch_regset_from_core_section_p (gdbarch=0x85723d0) at ../../src/gdb/gdbarch.c:3665
3665	  gdb_assert (gdbarch != NULL);
(top-gdb) n
Backtrace limit of 50 exceeded
gdbarch_regset_from_core_section_p (gdbarch=0x85723d0) at ../../src/gdb/gdbarch.c:3666
3666	  return gdbarch->regset_from_core_section != NULL;
(top-gdb) p gdbarch
$5 = (struct gdbarch *) 0x85723d0
(top-gdb) p gdbarch->regset_from_core_section
$6 = (gdbarch_regset_from_core_section_ftype *) 0
(top-gdb) n
Backtrace limit of 50 exceeded
gdbarch_regset_from_core_section_p (gdbarch=0x85723d0) at ../../src/gdb/gdbarch.c:3667
3667	}
(top-gdb) n
Backtrace limit of 50 exceeded
Backtrace limit of 50 exceeded
sniff_core_bfd (abfd=0x849caf0) at ../../src/gdb/corelow.c:147
147	  for (cf = core_file_fns; cf != NULL; cf = cf->next)
(top-gdb) quit
The program is running.  Exit anyway? (y or n) y

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

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

Re: arm core analysis on x86 host

[Jon Ringle]

On Tuesday 29 March 2005 11:33, Daniel Jacobowitz wrote:
> On Tue, Mar 29, 2005 at 11:13:53AM -0500, Jon Ringle wrote:
> > On Monday 28 March 2005 23:58, Daniel Jacobowitz wrote:
> > > 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?

I put a call to set_gdbarch_regset_from_core_section at the end of 
arm_linux_init_abi(), just like ppc_linux_init_abi().

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

On Tue, Mar 29, 2005 at 11:39:15AM -0500, Jon Ringle wrote:
> On Tuesday 29 March 2005 11:33, Daniel Jacobowitz wrote:
> > On Tue, Mar 29, 2005 at 11:13:53AM -0500, Jon Ringle wrote:
> > > On Monday 28 March 2005 23:58, Daniel Jacobowitz wrote:
> > > > 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?
> 
> I put a call to set_gdbarch_regset_from_core_section at the end of 
> arm_linux_init_abi(), just like ppc_linux_init_abi().

Trace through the gdbarch initialization to see what's going on, then.
The core file may not be recognized as a Linux object.  This has
happened on other platforms; I don't know what was done about it, but
maybe Mark remembers.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm core analysis on x86 host

[Jon Ringle]

On Tuesday 29 March 2005 11:53, Daniel Jacobowitz wrote:
> Trace through the gdbarch initialization to see what's going on, then.
> The core file may not be recognized as a Linux object.  This has
> happened on other platforms; I don't know what was done about it, but
> maybe Mark remembers.

I set #define GDBARCH_DEBUG 1 at the top of gdbarch.c, now I am getting an 
internal error...

$ gdb ./gdb
GNU gdb 6.2-2mdk (Mandrakelinux)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu"...Using host libthread_db 
library "/lib/tls/libthread_db.so.1".

Setting up the environment for debugging gdb.
Breakpoint 1 at 0x805cc73: file ../../src/gdb/utils.c, line 817.
Breakpoint 2 at 0x8086a35: file ../../src/gdb/cli/cli-cmds.c, line 193.
(top-gdb) run -n
Starting program: /home/ringlej/gdb-cvs/arm/gdb/gdb -n
Backtrace limit of 50 exceeded
register_gdbarch_init (arm, 0x08067c66)
find_arch_by_info: info.bfd_arch_info arm
find_arch_by_info: info.byte_order 1 (little)
find_arch_by_info: info.osabi 5 (GNU/Linux)
find_arch_by_info: info.abfd 0x0
find_arch_by_info: info.tdep_info 0x0
find_arch_by_info: New architecture 0x0848d2e0 (arm) selected
gdbarch_dump: GDB_XM_FILE = <not-defined>
gdbarch_dump: GDB_NM_FILE = <not-defined>
gdbarch_dump: GDB_TM_FILE = config/arm/tm-linux.h
gdbarch_dump: TARGET_ADDR_BIT # (gdbarch_addr_bit (current_gdbarch))
gdbarch_dump: addr_bit = 32
gdbarch_dump: ADDR_BITS_REMOVE(addr) # (gdbarch_addr_bits_remove 
(current_gdbarch, addr))
gdbarch_dump: addr_bits_remove = <0x806494a>
gdbarch_dump: gdbarch_address_class_name_to_type_flags_p() = 0
gdbarch_dump: address_class_name_to_type_flags = <0x0>
gdbarch_dump: ADDRESS_CLASS_TYPE_FLAGS_P() # 
(gdbarch_address_class_type_flags_p (current_gdbarch))
gdbarch_dump: gdbarch_address_class_type_flags_p() = 0
gdbarch_dump: ADDRESS_CLASS_TYPE_FLAGS(byte_size, dwarf2_addr_class) # 
(gdbarch_address_class_type_flags (current_gdbarch, byte_size, 
dwarf2_addr_class))
gdbarch_dump: address_class_type_flags = <0x0>
gdbarch_dump: gdbarch_address_class_type_flags_to_name_p() = 0
gdbarch_dump: address_class_type_flags_to_name = <0x0>
gdbarch_dump: ADDRESS_TO_POINTER(type, buf, addr) # 
(gdbarch_address_to_pointer (current_gdbarch, type, buf, addr))
gdbarch_dump: address_to_pointer = <0x80b1881>
gdbarch_dump: gdbarch_adjust_breakpoint_address_p() = 0
gdbarch_dump: adjust_breakpoint_address = <0x0>
gdbarch_dump: BELIEVE_PCC_PROMOTION # (gdbarch_believe_pcc_promotion 
(current_gdbarch))
gdbarch_dump: believe_pcc_promotion = 0
gdbarch_dump: TARGET_ARCHITECTURE # (gdbarch_bfd_arch_info (current_gdbarch))
gdbarch_dump: bfd_arch_info = arm
gdbarch_dump: TARGET_BFD_VMA_BIT # (gdbarch_bfd_vma_bit (current_gdbarch))
gdbarch_dump: bfd_vma_bit = 32
gdbarch_dump: BREAKPOINT_FROM_PC(pcptr, lenptr) # (gdbarch_breakpoint_from_pc 
(current_gdbarch, pcptr, lenptr))
gdbarch_dump: breakpoint_from_pc = <0x8066f53>
gdbarch_dump: TARGET_BYTE_ORDER # (gdbarch_byte_order (current_gdbarch))
gdbarch_dump: byte_order = 1
gdbarch_dump: CALL_DUMMY_LOCATION # (gdbarch_call_dummy_location 
(current_gdbarch))
gdbarch_dump: call_dummy_location = 4
gdbarch_dump: CANNOT_FETCH_REGISTER(regnum) # (gdbarch_cannot_fetch_register 
(current_gdbarch, regnum))
gdbarch_dump: cannot_fetch_register = <0x80fde61>
gdbarch_dump: CANNOT_STEP_BREAKPOINT # (gdbarch_cannot_step_breakpoint 
(current_gdbarch))
gdbarch_dump: cannot_step_breakpoint = 0
gdbarch_dump: CANNOT_STORE_REGISTER(regnum) # (gdbarch_cannot_store_register 
(current_gdbarch, regnum))
gdbarch_dump: cannot_store_register = <0x80fde61>
gdbarch_dump: TARGET_CHAR_SIGNED # (gdbarch_char_signed (current_gdbarch))
gdbarch_dump: char_signed = 0
gdbarch_dump: COFF_MAKE_MSYMBOL_SPECIAL(val, msym) # 
(gdbarch_coff_make_msymbol_special (current_gdbarch, val, msym))
gdbarch_dump: coff_make_msymbol_special = <0x8067a6b>
gdbarch_dump: construct_inferior_arguments = <0x80e0595>
gdbarch_dump: convert_from_func_ptr_addr = <0x80fde47>
gdbarch_dump: CONVERT_REGISTER_P(regnum, type) # (gdbarch_convert_register_p 
(current_gdbarch, regnum, type))
gdbarch_dump: convert_register_p = <0x80fe095>
gdbarch_dump: DECR_PC_AFTER_BREAK # (gdbarch_decr_pc_after_break 
(current_gdbarch))
Backtrace limit of 50 exceeded

Breakpoint 1, internal_error (file=0x83a92a2 "../../src/gdb/gdbarch.c", 
line=1858, string=0x83a9287 "%s: Assertion `%s' failed.") 
at ../../src/gdb/utils.c:817
817       va_start (ap, string);
(top-gdb) bt
#-1 internal_error (file=0x83a92a2 "../../src/gdb/gdbarch.c", line=1858, 
string=0x83a9287 "%s: Assertion `%s' failed.") at ../../src/gdb/utils.c:817
Backtrace limit of 50 exceeded

Re: arm core analysis on x86 host

[Jon Ringle]

On Tuesday 29 March 2005 12:17, Jon Ringle wrote:
> On Tuesday 29 March 2005 11:53, Daniel Jacobowitz wrote:
> > Trace through the gdbarch initialization to see what's going on, then.
> > The core file may not be recognized as a Linux object.  This has
> > happened on other platforms; I don't know what was done about it, but
> > maybe Mark remembers.
>
> I set #define GDBARCH_DEBUG 1 at the top of gdbarch.c, now I am getting an
> internal error...

I also get the same internal error with a host=i686-linux target=i686-linux 
build of gdb when #define GDBARCH_DEBUG 1 is set in gdbarch.c. It is very 
easy to reproduce.

Jon

Re: arm core analysis on x86 host

[Jon Ringle]

On Tuesday 29 March 2005 11:53, Daniel Jacobowitz wrote:
> On Tue, Mar 29, 2005 at 11:39:15AM -0500, Jon Ringle wrote:
> > On Tuesday 29 March 2005 11:33, Daniel Jacobowitz wrote:
> > > On Tue, Mar 29, 2005 at 11:13:53AM -0500, Jon Ringle wrote:
> > > > On Monday 28 March 2005 23:58, Daniel Jacobowitz wrote:
> > > > > 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?
> >
> > I put a call to set_gdbarch_regset_from_core_section at the end of
> > arm_linux_init_abi(), just like ppc_linux_init_abi().
>
> Trace through the gdbarch initialization to see what's going on, then.
> The core file may not be recognized as a Linux object.  This has
> happened on other platforms; I don't know what was done about it, but
> maybe Mark remembers.

Daniel,

Is the problem that the osabi for the file and target don't match?

(gdb) file ippbx.gdb
find_arch_by_info: info.bfd_arch_info arm
find_arch_by_info: info.byte_order 1 (little)
find_arch_by_info: info.osabi 5 (GNU/Linux)
find_arch_by_info: info.abfd 0x849e558
find_arch_by_info: info.tdep_info 0x0
find_arch_by_info: Previous architecture 0x0848e430 (arm) selected
Reading symbols 
from /home/ringlej/mp1000/trunk-fixes/Soundpipe/ippbx/ippbx.gdb...done.
(gdb) target core ./core
find_arch_by_info: info.bfd_arch_info arm
find_arch_by_info: info.byte_order 1 (little)
find_arch_by_info: info.osabi 21 (ARM APCS)
find_arch_by_info: info.abfd 0x84a0450
find_arch_by_info: info.tdep_info 0x0
find_arch_by_info: New architecture 0x08571958 (arm) selected

Jon

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

On Tue, Mar 29, 2005 at 09:07:17PM -0500, Jon Ringle wrote:
> Daniel,
> 
> Is the problem that the osabi for the file and target don't match?
> 
> (gdb) file ippbx.gdb
> find_arch_by_info: info.bfd_arch_info arm
> find_arch_by_info: info.byte_order 1 (little)
> find_arch_by_info: info.osabi 5 (GNU/Linux)
> find_arch_by_info: info.abfd 0x849e558
> find_arch_by_info: info.tdep_info 0x0
> find_arch_by_info: Previous architecture 0x0848e430 (arm) selected
> Reading symbols 
> from /home/ringlej/mp1000/trunk-fixes/Soundpipe/ippbx/ippbx.gdb...done.
> (gdb) target core ./core
> find_arch_by_info: info.bfd_arch_info arm
> find_arch_by_info: info.byte_order 1 (little)
> find_arch_by_info: info.osabi 21 (ARM APCS)
> find_arch_by_info: info.abfd 0x84a0450
> find_arch_by_info: info.tdep_info 0x0
> find_arch_by_info: New architecture 0x08571958 (arm) selected

You should try to see how this works on PPC.  I don't know.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm core analysis on x86 host

[Jon Ringle]

On Tuesday 29 March 2005 23:51, Daniel Jacobowitz wrote:
> You should try to see how this works on PPC.  I don't know.

If I had one, I would :( I was just using the ppc code as an example to 
follow.

Where can I find documentation on the core file format?
Also, do you know where in the kernel source does a core file get generated?

Thanks,
Jon

Re: arm core analysis on x86 host

[M.M. Kettenis]

Jon Ringle <jon.ringle@comdial.com> wrote:

> On Tuesday 29 March 2005 23:51, Daniel Jacobowitz wrote:
> > You should try to see how this works on PPC.  I don't know.
>
> If I had one, I would :( I was just using the ppc code as an example to
> follow.
>
> Where can I find documentation on the core file format?
> Also, do you know where in the kernel source does a core file get generated?

Sorry folks for not replying earlier; last days have been a bit busy.

First off, the code for reading ARM core files lives in
../bfd/elf32-arm.c (from a gdb standpoint).  Looks like everything is
there to properly support arm-*-linux-gnu core files, but it could be
wrong.

Secondly, the OS/ABI for core files don't have to match the executable
exactly, but of course they have to be somewhat compatible. I know
for sure that 32x64-bit cross debugging works on AMD64, and it is
assumed to be working on PowerPC too.  There might be some nasty
side-effects though if you load a core file without the matching
executable.

However, if the OS/ABI's differ, be aware that
regset_from_core_section() will be called for the OS/ABI of the core
file. That regset_from_core_section() will have to do the proper
translation on the register sets for the OS/ABI of the executable.
That OS/ABI can be determined from the regcache that is passed to
regset_from_core_section().

I'd suggest looking at the i386/amd64 *BSD code or NetBSD/sparc64 code
for good examples.

Beware, besides differences in OS/ABI, there might also be differences
in bfd machine type (bfd_mach_xxx).  You'll have to make sure that there is an OS/ABI that is compatible with the bfd machine type of the
core file.  For most architectures this will be the case if the OS/ABI
is registered for the default machine type (0), but I don't know if
that is the case for ARM.

Mark

> Thanks,
> Jon
>
>

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

On Wed, Mar 30, 2005 at 03:10:31PM +0000, M.M. Kettenis wrote:
> Secondly, the OS/ABI for core files don't have to match the executable
> exactly, but of course they have to be somewhat compatible. I know
> for sure that 32x64-bit cross debugging works on AMD64, and it is
> assumed to be working on PowerPC too.  There might be some nasty
> side-effects though if you load a core file without the matching
> executable.
> 
> However, if the OS/ABI's differ, be aware that
> regset_from_core_section() will be called for the OS/ABI of the core
> file. That regset_from_core_section() will have to do the proper
> translation on the register sets for the OS/ABI of the executable.
> That OS/ABI can be determined from the regcache that is passed to
> regset_from_core_section().
> 
> I'd suggest looking at the i386/amd64 *BSD code or NetBSD/sparc64 code
> for good examples.

How does this work?  In amd64_init_abi, we only call
set_gdbarch_regset_from_core_section if this OS/ABI has a registered
gregset.  So if the core file is not tagged as Linux, then the right
OS/ABI's code will never be called.

It looks to me from tracing this through on i386, that the reason
it works is because foo-*-linux* configurations default to
GDB_OSABI_LINUX and none of the OS/ABI sniffers trigger on the core
file.  An accident, basically.

The reason this doesn't work for ARM is because the sniffer tags the
core file as GDB_OSABI_ARM_APCS.  I've been meaning to change the way
ARM OS/ABI detection works, which will "fix" this as a side effect;
I will move that up my list and try to do it today.

But I'm left wondering about the overall design.  How are we supposed
to figure out what sort of core file we have?  Is the target
architecture required to arbitrate between possible subtarget core
formats?  Do the sniffers need to become cleverer - if that's even
possible?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm core analysis on x86 host

[Mark Kettenis]

   Date: Wed, 30 Mar 2005 10:26:36 -0500
   From: Daniel Jacobowitz <drow@false.org>

   On Wed, Mar 30, 2005 at 03:10:31PM +0000, M.M. Kettenis wrote:
   > Secondly, the OS/ABI for core files don't have to match the executable
   > exactly, but of course they have to be somewhat compatible. I know
   > for sure that 32x64-bit cross debugging works on AMD64, and it is
   > assumed to be working on PowerPC too.  There might be some nasty
   > side-effects though if you load a core file without the matching
   > executable.
   > 
   > However, if the OS/ABI's differ, be aware that
   > regset_from_core_section() will be called for the OS/ABI of the core
   > file. That regset_from_core_section() will have to do the proper
   > translation on the register sets for the OS/ABI of the executable.
   > That OS/ABI can be determined from the regcache that is passed to
   > regset_from_core_section().
   > 
   > I'd suggest looking at the i386/amd64 *BSD code or NetBSD/sparc64 code
   > for good examples.

   How does this work?  In amd64_init_abi, we only call
   set_gdbarch_regset_from_core_section if this OS/ABI has a registered
   gregset.  So if the core file is not tagged as Linux, then the right
   OS/ABI's code will never be called.

The core file should somehow be tagged as Linux.  If it is not tagged
as such, how are we going to interpret it?  The fact that it is an ELF
core file, and has notes like NT_PRSTATUS does not tell us where each
register is stored.  Right now we have to guess what the layout of
these notes is based on the size of the sections or because the header
describing the layout is available because we're building a native
GDB.  But of course this all wrong [1].

A much better way to do things is the way NetBSD creates ELF core
file.  They have their own set of notes, with a layout that is the
same on 32-bit and 64-bit architectures and names that clearly
proclaim this it's produced by NetBSD.

   It looks to me from tracing this through on i386, that the reason
   it works is because foo-*-linux* configurations default to
   GDB_OSABI_LINUX and none of the OS/ABI sniffers trigger on the core
   file.  An accident, basically.

Not completely accidental.  If we don't have the means to determine
the OS/ABI it makes sense to default to the target (implicitly)
selected by the user.

   The reason this doesn't work for ARM is because the sniffer tags
   the core file as GDB_OSABI_ARM_APCS.  I've been meaning to change
   the way ARM OS/ABI detection works, which will "fix" this as a side
   effect; I will move that up my list and try to do it today.

Well, if there is some sort of standard ARM APCS core file this is
perfectly OK.  In that case we shouldn't think about this as a Linux
core file, but an ARM APCS core file.  There should be an ARM APCS
architecture vector with a regset_from_core_section() that knows how
to interpret it.

But i guess that's not the case.

   But I'm left wondering about the overall design.  How are we supposed
   to figure out what sort of core file we have?  Is the target
   architecture required to arbitrate between possible subtarget core
   formats?  Do the sniffers need to become cleverer - if that's even
   possible?

There are several possibilities.  Yes, sniffers should be as clever as
they can possibly be.  But the regset_from_core_section() functions
can be made cleverer too.  And the core file reading code in BFD can
help too by generating core file sections with meaningful names.

Mark


[1] Unless of course we're really dealing with a standard SVR4 core
    file here (which it really proclaims to be).  However, we suffer
    from the problem that we treat (generic) SVR4 ELF files as having
    no OS/ABI.

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

On Wed, Mar 30, 2005 at 08:01:56PM +0200, Mark Kettenis wrote:
>    It looks to me from tracing this through on i386, that the reason
>    it works is because foo-*-linux* configurations default to
>    GDB_OSABI_LINUX and none of the OS/ABI sniffers trigger on the core
>    file.  An accident, basically.
> 
> Not completely accidental.  If we don't have the means to determine
> the OS/ABI it makes sense to default to the target (implicitly)
> selected by the user.

Well, yes.  This is one of the reasons I added the default osabi
mechanism.  At least I think it was me :-)

>    The reason this doesn't work for ARM is because the sniffer tags
>    the core file as GDB_OSABI_ARM_APCS.  I've been meaning to change
>    the way ARM OS/ABI detection works, which will "fix" this as a side
>    effect; I will move that up my list and try to do it today.
> 
> Well, if there is some sort of standard ARM APCS core file this is
> perfectly OK.  In that case we shouldn't think about this as a Linux
> core file, but an ARM APCS core file.  There should be an ARM APCS
> architecture vector with a regset_from_core_section() that knows how
> to interpret it.
> 
> But i guess that's not the case.

Right.  APCS is simply the default for "unknown" ABIs; the sniffer is
being over-eager.  Patch forthcoming.

> There are several possibilities.  Yes, sniffers should be as clever as
> they can possibly be.  But the regset_from_core_section() functions
> can be made cleverer too.  And the core file reading code in BFD can
> help too by generating core file sections with meaningful names.

I wonder if we should fall back to the executable's OSABI in some case?
Anyway, not an urgent question.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm core analysis on x86 host

[Jon Ringle]

On Wednesday 30 March 2005 13:01, Mark Kettenis wrote:
> The core file should somehow be tagged as Linux.  If it is not tagged
> as such, how are we going to interpret it?  The fact that it is an ELF
> core file, and has notes like NT_PRSTATUS does not tell us where each
> register is stored.  Right now we have to guess what the layout of
> these notes is based on the size of the sections or because the header
> describing the layout is available because we're building a native
> GDB.

I modified my linux kernel (based on 2.2.16) in linux/fs/binfmt_elf.c to emit:
	elf.e_ident[EI_OSABI] = ELFOSABI_LINUX;
The linux-2.6 series does this.

This seemed to help in conjuction with changes to gdb/arm-linux-tdep.c to add:
set_gdbarch_regset_from_core_section(gdbarch,arm_linux_regset_from_core_section);

I can send in a patch for the arm-linux-tdep.c changes if you'd like.

Jon

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

On Thu, Mar 31, 2005 at 09:08:05AM -0500, Jon Ringle wrote:
> On Wednesday 30 March 2005 13:01, Mark Kettenis wrote:
> > The core file should somehow be tagged as Linux.  If it is not tagged
> > as such, how are we going to interpret it?  The fact that it is an ELF
> > core file, and has notes like NT_PRSTATUS does not tell us where each
> > register is stored.  Right now we have to guess what the layout of
> > these notes is based on the size of the sections or because the header
> > describing the layout is available because we're building a native
> > GDB.
> 
> I modified my linux kernel (based on 2.2.16) in linux/fs/binfmt_elf.c to emit:
> 	elf.e_ident[EI_OSABI] = ELFOSABI_LINUX;
> The linux-2.6 series does this.
> 
> This seemed to help in conjuction with changes to gdb/arm-linux-tdep.c to add:
> set_gdbarch_regset_from_core_section(gdbarch,arm_linux_regset_from_core_section);
> 
> I can send in a patch for the arm-linux-tdep.c changes if you'd like.

It doesn't look like you have a copyright assignment on file - is that
right?  In that case, give me a couple of days; once my current ARM
patch is finished, I can look into doing this myself based on our
conversation.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm core analysis on x86 host

[Jon Ringle]

On Thursday 31 March 2005 09:29, Daniel Jacobowitz wrote:
> On Thu, Mar 31, 2005 at 09:08:05AM -0500, Jon Ringle wrote:
> > I can send in a patch for the arm-linux-tdep.c changes if you'd like.
>
> It doesn't look like you have a copyright assignment on file - is that
> right?
No. Please send or direct me to info about this.

> In that case, give me a couple of days; once my current ARM 
> patch is finished, I can look into doing this myself based on our
> conversation.
Thanks. I feel much better you doing it anyway. I am more likely to do it The 
Wrong Way, as I am mainly wandering around unfamiliar code.

Jon

Re: arm core analysis on x86 host

[Jon Ringle]

On Thursday 31 March 2005 09:29, Daniel Jacobowitz wrote:
> In that case, give me a couple of days; once my current ARM
> patch is finished, I can look into doing this myself based on our
> conversation.

Daniel,

Have you had a chance to create a patch for this issue? Or did I miss it?

Thanks,

Jon

Re: arm core analysis on x86 host

[Daniel Jacobowitz]

On Wed, Apr 06, 2005 at 06:16:48PM -0400, Jon Ringle wrote:
> On Thursday 31 March 2005 09:29, Daniel Jacobowitz wrote:
> > In that case, give me a couple of days; once my current ARM
> > patch is finished, I can look into doing this myself based on our
> > conversation.
> 
> Daniel,
> 
> Have you had a chance to create a patch for this issue? Or did I miss it?

The previous patch is still pending; let me nag Richard...

-- 
Daniel Jacobowitz
CodeSourcery, LLC