RE: Segmentation Fault sid&gdb

RE: Segmentation Fault sid&gdb

[Bernard Dautrevaux]

> -----Original Message-----
> From: Frank Ch. Eigler [ mailto:fche@redhat.com ]
> Sent: Tuesday, January 16, 2001 6:56 PM
> To: norbert.c.esser@philips.com
> Cc: sid@sources.redhat.com
> Subject: Re: Segmentation Fault sid&gdb
> 
> 
	 [...]

> : I'm using the following:
> : 
> : binutils-2.10.1
> : gcc-2.95.2
> : insight-5.0    (also tried gdb-5.0 with same results)
> : newlib-1.9.0
> : 
> : All configured with --target=arm-elf
> 
> Your gcc may be too old, but the others sound fine.
> 


Hey, what's the up-to-date gcc? last time I look (not so far away), 2.95.2
was the latest one (and is still the one delivered as latest release by a
lot of people, even at cygnus, er... redhat)

TIA

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: Segmentation Fault sid&gdb

[Frank Ch. Eigler]

Hi -

On Tue, Jan 16, 2001 at 07:49:19PM +0100, Bernard Dautrevaux wrote:
: [...]
: Hey, what's the up-to-date gcc? last time I look (not so far away), 2.95.2
: was the latest one 

That's true, though I don't know if that release included proper arm-elf
target support.


: (and is still the one delivered as latest release by a lot of people,
: even at cygnus, er... redhat)

Nah - AFAIK neither Cygnus nor Red Hat has released gcc 2.95.2.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6ZLhHVZbdDOm/ZT0RAhwfAJ4hzAHrbxuk6gpillaJg416g9xtEQCeN7l0
kYNrouc6eoD98ygmHSmmTW0=
=x3Oj
-----END PGP SIGNATURE-----

RE: Segmentation Fault sid&gdb

[Ben Elliston]

   Hey, what's the up-to-date gcc? last time I look (not so far away),
   2.95.2 was the latest one (and is still the one delivered as latest
   release by a lot of people, even at cygnus, er... redhat)

2.95.2 is the latest release from the GCC group.

Ben

RE: Segmentation Fault sid&gdb

[Bernard Dautrevaux]

> -----Original Message-----
> From: Frank Ch. Eigler [ mailto:fche@redhat.com ]
> Sent: Tuesday, January 16, 2001 10:08 PM
> To: Bernard Dautrevaux
> Cc: norbert.c.esser@philips.com; sid@sources.redhat.com
> Subject: Re: Segmentation Fault sid&gdb
> 
> 
	<snipped>
> 
> : (and is still the one delivered as latest release by a lot 
> of people,
> : even at cygnus, er... redhat)
> 
> Nah - AFAIK neither Cygnus nor Red Hat has released gcc 2.95.2.
> 

I don't know on RedHat Linux, but cygnus deliver gcc-2.95.2-6 (that's the
sixth port of 2.95.2) on cygwin, and that's usually there that I get the
source code, as I need for a lot of tools to have them running under Win32
(using mingw32, not cygwin, but usually a lot of the port effort is already
done for cygwin).

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: Segmentation Fault sid&gdb

[norbert.c.esser]

Thanks for the quick response.

>>: But I now give the follwing command:
>>:
>>:       (gdb) cont
>>:
>>: Then I get the following message:
>>:       Program received signal SIGSEGV, Segmentation fault
>>: [...]

> This message indicates that the arm-elf program running
> on the simulator has encountered a SEGV.  hello-world of
> course shouldn't, but there are a few ways to find out
> what's happening:

To be a little more precise, the SEGV thing only happens to me
when I create breakpoints. Without any breakpoints the program
seems to runn correctly (i.e. it prints Hello world!) and gdb 
indicates that the program terminated normally.

>
> * when the first fault message comes from gdb, run
>   the gdb `backtrace' command to find out where the
>   crash occurred

Ok. compiled the program
#include <stdio.h>

int main() 
{ printf("Hello world!\n");
  return 0;
}

with: arm-elf-gcc -mlittle-endian -g hello.c -o hello.x

started sid with: arm-elf-sid --gdb:2000 -EL &

and then ran gdb as follows:

arm-elf-gdb -nw hello.x                    (Note I'm using Insight5.0 gdb)
GNU gdb 20010115
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"...
(gdb) target remote localhost:2000
Remote debugging using localhost:2000
0x00000000 in ?? ()
(gdb) load
Loading section .text, size 0x87d0 lma 0x8000
Loading section .rodata, size 0x22c lma 0x107d0
Loading section .data, size 0x854 lma 0x10afc
Loading section .ctors, size 0x8 lma 0x11350
Loading section .dtors, size 0x8 lma 0x11358
Start address 0x8000, load size 37472
Transfer rate: 149888 bits/sec, 302 bytes/write.
(gdb) break 4
Breakpoint 1 at 0x80e4: file hello.c, line 4. 

Note: that now break main for some reason sets the breakpoint at line 5 (after the return 0).
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000080e8 in main () at hello.c:4
4	{ printf("Hello world!\n"); 
(gdb) backtrace
#0  0x000080e8 in main () at hello.c:4

> * enable more simulator tracing options, for example by
>   adding "--trace-sem" and "--trace-core" and perhaps "--verbose"
>   to the arm-elf-sid command line; possibly, compare the
>   trace-sem disassembly to "arm-elf-objdump -d <your-hello-world.x>".
Ok. I added --trace-sem option. And this what I got:


Running without breakpoint (program runs and terminates normally):
0x80e4: MOV_REG_IMM_SHIFT
0x80e8: STMDB_WB	
0x80ec: SUB_IMM	
0x80f0: BL
....snip
0x80f4: LDR_PRE_INC_IMM_OFFSET
0x80f8: BL
....snip
0x80fc: MOV_IMM
0x8100: B
0x8108: LDMDB	

Running with breakpoint (program terminates with SEGV):
0x80e4: LDRB_PRE_INC_WB_REG_OFFSET	
0x80e8: STMDB_WB

arm-elf-objdump -d -S gives:
000080e4 <main>:
#include <stdio.h>

int main() 
{ printf("Hello world!\n");
    80e4:	e1a0c00d 	mov	r12, sp    
    80e8:	e92dd800 	stmdb	sp!, {r11, r12, lr, pc}
    80ec:	e24cb004 	sub	r11, r12, #4	; 0x4
    80f0:	eb000038 	bl	81d8 <__gccmain>
    80f4:	e59f0008 	ldr	r0, [pc, #8]	; 8104 <main+0x20>
    80f8:	eb000275 	bl	8ad4 <printf>
  return 0;
    80fc:	e3a00000 	mov	r0, #0	; 0x0
    8100:	ea000000 	b	8108 <main+0x24>
    8104:	000107d0 	streqsb	r0, [r1], -r0
}
    8108:	e91ba800 	ldmdb	r11, {r11, sp, pc}

It seems that the breakpoint causes the problems, but I have no idea
what is exactly going on. 

> * identify which arm-elf cross-compiler toolchain you are using
I'm using the following:

binutils-2.10.1
gcc-2.95.2
insight-5.0    (also tried gdb-5.0 with same results)
newlib-1.9.0

All configured with --target=arm-elf

> : [...]
> : I would for example like to be able to set multiple breakpoints and
> : if the program stops on a breakpoint continue the program until it
> : stops on another breakpoint.  Is this possible?   [...]

> Certainly.  This is a routine usage scenario, and should in general
> work.

Thats what I thought :-)

Hope this clears things up a bit and that you can help me further.

Greetings.

Re: Segmentation Fault sid&gdb

[Frank Ch. Eigler]

Hi -

On Tue, Jan 16, 2001 at 03:40:28PM +0100, norbert.c.esser@philips.com wrote:
: [..]
: To be a little more precise, the SEGV thing only happens to me
: when I create breakpoints. Without any breakpoints the program
: seems to runn correctly [..]

Interesting.


: [...]
: (gdb) break 4
: Breakpoint 1 at 0x80e4: file hello.c, line 4. 
: Note: that now break main for some reason sets the breakpoint at line 5 (after the return 0).

Debugging line numbers sometimes get confused when you put too many
statements on a line.   Try addding some whitespace or functional
filler.


: > * enable more simulator tracing options, for example by
: >   adding "--trace-sem" and "--trace-core" and perhaps "--verbose"
: >   to the arm-elf-sid command line; possibly, compare the
: >   trace-sem disassembly to "arm-elf-objdump -d <your-hello-world.x>".
: Ok. I added --trace-sem option. And this what I got:

: 0x80e4: MOV_REG_IMM_SHIFT
: 0x80e8: STMDB_WB	
: [...]

Right.  If you add "--engine=scache", you'll get a more informative trace.
The default for arm, "pbb", provides some optimization but at the cost of
limited tracing.  There is the possibility of interference with other
functions such as software breakpoints and exceptions, but that would be
a bug.

"--trace-core" will list simulated memory accesses.  It would show the
actual memory address that triggered the simulated SEGV.


: [...]
: I'm using the following:
: 
: binutils-2.10.1
: gcc-2.95.2
: insight-5.0    (also tried gdb-5.0 with same results)
: newlib-1.9.0
: 
: All configured with --target=arm-elf

Your gcc may be too old, but the others sound fine.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6ZIsWVZbdDOm/ZT0RArGnAJ9goGNaoVgL+DD7QjOku40XXQ2+HQCeO9eW
6Cc6rWZ6G3Gey+6Q0iO4h6I=
=YRnX
-----END PGP SIGNATURE-----

re: Segmentation Fault sid&gdb

[matthew green]

   
   
   : [...]
   : I'm using the following:
   : 
   : binutils-2.10.1
   : gcc-2.95.2
   : insight-5.0    (also tried gdb-5.0 with same results)
   : newlib-1.9.0
   : 
   : All configured with --target=arm-elf
   
   Your gcc may be too old, but the others sound fine.


FWIW, i've been compiling sid with gcc-2.95.2 for a year.


.mrg.

Segmentation Fault sid&gdb

[norbert.c.esser]

Hello,

I'm trying to use gdb in combination with sid.
I followed the example in the SID Faq-O-Matic on "how does one build and run sid".

I compiled the following program for the ARM

    #include <stdio.h>
    
    int main
    { printf("Hello world!\n");
       return 0;
     }

with arm-elf-gcc -mlittle-endian hello.c -o hello.x

And then started sid and gdb in the follwing way:

    arm-elf-sid --gdb=2000 -EL &
    arm-elf-gdb hello.x

I then gave the follwing gdb commands:

      (gdb) target remote localhost:2000
      (gdb) load
      (gdb) break main

Up to here everything seems to work
But I now give the follwing command:

      (gdb) cont

Then I get the following message:

      Program received signal SIGSEGV, Segmentation fault

Which I think is probably due to the way gdb handles breakpoints (am I correct?).
But I I then want to step or continue the program in which way what so ever, I get the
message

      Fault (memory, 0xfffffffc) pc=0x80e8

And then nothing happens anymore.

I would for example like to be able to set multiple breakpoints and if the program stops on a
breakpoint continue the program until it stops on another breakpoint.
Is this possible? If yes, what am I doing wrong?
Can anybody shed some light on this subject?

Thanks. 

Re: Segmentation Fault sid&gdb

[Frank Ch. Eigler]

Hi -

On Tue, Jan 16, 2001 at 10:24:47AM +0100, norbert.c.esser@philips.com wrote:
: I'm trying to use gdb in combination with sid.

Excellent, welcome!


: I followed the example in the SID Faq-O-Matic on "how does one build
: and run sid".
: I compiled [hello-world] for the ARM [...]
: with arm-elf-gcc -mlittle-endian hello.c -o hello.x
: And then started sid and gdb in the follwing way:
:     arm-elf-sid --gdb=2000 -EL &
:     arm-elf-gdb hello.x
: I then gave the follwing gdb commands:
:       (gdb) target remote localhost:2000
:       (gdb) load
:       (gdb) break main
: Up to here everything seems to work

Good.


: But I now give the follwing command:
: 
:       (gdb) cont
: 
: Then I get the following message:
:       Program received signal SIGSEGV, Segmentation fault
: [...]

This message indicates that the arm-elf program running
on the simulator has encountered a SEGV.  hello-world of
course shouldn't, but there are a few ways to find out
what's happening:

* when the first fault message comes from gdb, run
  the gdb `backtrace' command to find out where the
  crash occurred

* enable more simulator tracing options, for example by
  adding "--trace-sem" and "--trace-core" and perhaps "--verbose"
  to the arm-elf-sid command line; possibly, compare the
  trace-sem disassembly to "arm-elf-objdump -d <your-hello-world.x>".

* identify which arm-elf cross-compiler toolchain you are using


: [...]
: I would for example like to be able to set multiple breakpoints and
: if the program stops on a breakpoint continue the program until it
: stops on another breakpoint.  Is this possible?   [...]

Certainly.  This is a routine usage scenario, and should in general
work.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6ZEDxVZbdDOm/ZT0RAkKfAJ4mHXxjobGGdAoq98tAmT9boKsmDACghTmN
eKdX1EM9liyxt+TW1L39234=
=YJ6X
-----END PGP SIGNATURE-----