Re: memory region documentation

Re: memory region documentation

[Eli Zaretskii]

> From: jtc@redback.com (J.T. Conklin)
> Date: 21 Nov 2000 17:06:12 -0800
> 
> >> Can you tell me where you'd like me to put this chapter?  I assume
> >> it's a chapter, since it doesn't seem to be a good fit into any of
> >> the existing chapters --- especially if we start adding more varied
> >> attributes.
> 
> Eli> It looks like between "Native Debugging" and "Support Libraries"
> Eli> would be a good place.
> 
> Eh?  Those chapters are in the internals document, this is intended to
> be user documentation.

Ouch!  Whatever got me to think you were talking about gdbint.texinfo?
Sorry.

For gdb.texinfo, it looks like it should be a section in the
"Examining Data" chapter (node name "Data"), either as a section after
"Memory", or as a subsection of "Memory".  I'm puzzled why did you
think it didn't fit into the "Data" chapter.
From d_iftikhar@hotmail.com Wed Nov 22 02:35:00 2000
From: "danish iftikhar" <d_iftikhar@hotmail.com>
To: fnasser@cygnus.com
Cc: grante@visi.com, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Wed, 22 Nov 2000 02:35:00 -0000
Message-id: <F2693AmsfGdMNFmWAFs00000388@hotmail.com>
X-SW-Source: 2000-11/msg00227.html
Content-length: 4005

>From: Fernando Nasser <fnasser@cygnus.com>
>To: danish iftikhar <d_iftikhar@hotmail.com>
>CC: grante@visi.com
>Subject: Re: Jeeni & ARM720T with GDB
>Date: Wed, 22 Nov 2000 07:30:20 +0000
>
>Danish,
>
>I believe we need mode information.  The log seems normal to me.
>
>What is the value of the PC  (P/x $pc) after the load?
>
>Can you do a "x/30i $pc" so we see the startup code?
>
>When you do "break main", what is printed?
>
>And, maybe before all that, what was the exact command you've used to 
>compile?
>
>What is the output when you add "-v" to your gcc command?
>
>Fernando
>
***************************************************
  Hi

   i am enclosing all the information that u have asked for :

  arm-elf-gcc -v
Reading specs from 
/proj/danish/ECOS_EP7211/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/specs
gcc version 2.95.2 19991024 (release)

the command i am using to compile is :
CXX = arm-elf-gcc -mcpu=arm7tdmi -D__EDB7211


arm-elf-gdb -v
GNU gdb 5.0
Copyright 2000 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-elf".


After load Pc shows the address : 0x8060

The start uo code is :
(gdb) x/30i $pc
0x8060 <warm_reset>:    mrs     r7, cpsr
0x8064 <warm_reset+4>:  and     r7, r7, #31     ; 0x1f
0x8068 <warm_reset+8>:  cmp     r7, #19 ; 0x13
0x806c <warm_reset+12>: beq     0x80a0 <start>
0x8070 <warm_reset+16>: mov     r0, #0  ; 0x0
0x8074 <warm_reset+20>: str     r0, [r0, #64]
0x8078 <warm_reset+24>: ldr     r1, [pc, #4c0]  ; 0x8540 <_eCos_id+20>
0x807c <warm_reset+28>: ldr     r2, [r1, #4]
0x8080 <warm_reset+32>: str     r2, [r0, #4]
0x8084 <warm_reset+36>: ldr     r2, [r1, #36]
0x8088 <warm_reset+40>: str     r2, [r0, #36]
0x808c <warm_reset+44>: ldr     r2, [r1, #8]
0x8090 <warm_reset+48>: str     r2, [r0, #8]
0x8094 <warm_reset+52>: ldr     r2, [r1, #64]
0x8098 <warm_reset+56>: str     r2, [r0, #40]
0x809c <warm_reset+60>: swi     0x00000000
0x80a0 <start>: ldr     r0, [pc, #474]  ; 0x851c <.init_flag>
0x80a4 <start+4>:       ldr     r1, [r0]
0x80a8 <start+8>:       cmp     r1, #0  ; 0x0
0x80ac <start+12>:      bne     0x80a8 <start+8>
0x80b0 <start+16>:      ldr     r1, [pc, #c8]   ; 0x8180 <init_done>
0x80b4 <start+20>:      str     r1, [r0]
0x80b8 <start+24>:      mov     r0, #0  ; 0x0
0x80bc <start+28>:      ldr     r1, [pc, #454]  ; 0x8518 
<.__exception_handlers>
0x80c0 <start+32>:      cmp     r7, #19 ; 0x13
0x80c4 <start+36>:      beq     0x80d0 <start+48>
0x80c8 <start+40>:      ldr     r2, [r1, #40]
0x80cc <start+44>:      str     r2, [r0, #40]
0x80d0 <start+48>:      ldr     r2, [r1, #24]
0x80d4 <start+52>:      str     r2, [r0, #24]

  i am not able to do step or cont but using stepi i went through this 
startup function . It seems to loop around between 0x815c & 0x8164 and is 
not going ahead of that .
the code at this address is as follows :

0x8154  <start+180>:            cmp     r1, r2
-       0x8158  <start+184>:            beq     0x8168 <start+200>
-       0x815c  <start+188>:            str     r0, [r1], #4
-       0x8160  <start+192>:            cmp     r1, r2
-       0x8164  <start+196>:            bne     0x815c <start+188>
-       0x8168  <start+200>:            bl      0x1f194 <hal_hardware_init>
-       0x816c  <start+204>:            bl      0x1ee10 
<cyg_hal_invoke_constructors>
-       0x8170  <start+208>:            bl      0x1f358 <cyg_start>


umm when i do a break main , the reply is :

gdb) break main
Breakpoint 1 at 0x8558: file App.c

  Hoping to get an early reply from your side

thanks
danish.


_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

Re: memory region documentation

[Eli Zaretskii]

> From: jtc@redback.com (J.T. Conklin)
> Date: 30 Nov 2000 12:08:53 -0800
> 
> The reason I didn't think it fit in the Data chapter was the not yet
> implemented breakpoint attribute.  GDB needs to insert breakpoints for
> step, next, continue, etc.; but it can't do it if the memory region is
> protected (ie, image is running out of ROM, FLASH, etc.).  So there 
> needs to be a mechanism to tell GDB to use hardware breakpoints for
> those internal breakpoints.  This part of the feature isn't really
> "data" related.

That's true, but I don't think this is a reason grave enough to make
this a separate chapter.

I think the right question is: would a user reasonably expect this
feature be described under Data?  If so, we can put it there.  We can
also add a short explanation in the section about breakpoints saying
that in the case of read-only code memory, they need to use memory
regions first, with a cross-reference to the stuff you've written.
From rth@redhat.com Thu Nov 30 23:26:00 2000
From: Richard Henderson <rth@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Daniel Berlin <dberlin@redhat.com>, gdb@sources.redhat.com
Subject: Re: [crash] Section index is uninitialized
Date: Thu, 30 Nov 2000 23:26:00 -0000
Message-id: <20001130232605.A7627@redhat.com>
References: <20001130174058.A16314@redhat.com> <m3wvdk21xf.fsf@dan2.cygnus.com> <dberlin@redhat.com> <1001201054052.ZM7363@ocotillo.lan>
X-SW-Source: 2000-11/msg00290.html
Content-length: 540

On Thu, Nov 30, 2000 at 10:40:52PM -0700, Kevin Buettner wrote:
> The call to fixup_symbol_section() (which is one line before the line
> indicated above) should be setting section to the section associated
> with the minimal symbol.  I think we need to find out why
> fixup_symbol_section() is failing to do this.

Turns out to be more convoluted than that.  fixup_symbol_section
is setting the section to that of the minimal symbol.  It's just
that that is -1 as well.

More pointers?  Or, if you like, ~rth/gdb-killer in Sunnyvale.


r~
From kevinb@cygnus.com Fri Dec 01 00:51:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Richard Henderson <rth@redhat.com>
Cc: Daniel Berlin <dberlin@redhat.com>, gdb@sources.redhat.com
Subject: Re: [crash] Section index is uninitialized
Date: Fri, 01 Dec 2000 00:51:00 -0000
Message-id: <1001201085134.ZM28276@ocotillo.lan>
References: <20001130174058.A16314@redhat.com> <m3wvdk21xf.fsf@dan2.cygnus.com> <dberlin@redhat.com> <1001201054052.ZM7363@ocotillo.lan> <20001130232605.A7627@redhat.com> <rth@redhat.com>
X-SW-Source: 2000-12/msg00000.html
Content-length: 1996

On Nov 30, 11:26pm, Richard Henderson wrote:

> On Thu, Nov 30, 2000 at 10:40:52PM -0700, Kevin Buettner wrote:
> > The call to fixup_symbol_section() (which is one line before the line
> > indicated above) should be setting section to the section associated
> > with the minimal symbol.  I think we need to find out why
> > fixup_symbol_section() is failing to do this.
> 
> Turns out to be more convoluted than that.  fixup_symbol_section
> is setting the section to that of the minimal symbol.  It's just
> that that is -1 as well.
> 
> More pointers?  Or, if you like, ~rth/gdb-killer in Sunnyvale.

Try the following patch...

	* elfread.c (record_minimal_symbol_and_info): Don't guess
	at the section index to use; just use bfd's index.

Index: elfread.c
===================================================================
RCS file: /cvs/src/src/gdb/elfread.c,v
retrieving revision 1.11
diff -u -p -r1.11 elfread.c
--- elfread.c	2000/08/07 15:02:48	1.11
+++ elfread.c	2000/12/01 08:45:34
@@ -171,32 +171,13 @@ record_minimal_symbol_and_info (char *na
 				enum minimal_symbol_type ms_type, char *info,	/* FIXME, is this really char *? */
 				asection *bfd_section, struct objfile *objfile)
 {
-  int section;
-
-  /* Guess the section from the type.  This is likely to be wrong in
-     some cases.  */
-  switch (ms_type)
-    {
-    case mst_text:
-    case mst_file_text:
-      section = bfd_section->index;
 #ifdef SMASH_TEXT_ADDRESS
-      SMASH_TEXT_ADDRESS (address);
+  if (ms_type == mst_text || ms_type == mst_file_text)
+    SMASH_TEXT_ADDRESS (address);
 #endif
-      break;
-    case mst_data:
-    case mst_file_data:
-    case mst_bss:
-    case mst_file_bss:
-      section = bfd_section->index;
-      break;
-    default:
-      section = -1;
-      break;
-    }
 
   return prim_record_minimal_symbol_and_info
-    (name, address, ms_type, info, section, bfd_section, objfile);
+    (name, address, ms_type, info, bfd_section->index, bfd_section, objfile);
 }
 
 /*