public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: norbert.c.esser@philips.com
Cc: sid@sources.redhat.com
Subject: Re: Segmentation Fault sid&gdb
Date: Tue, 16 Jan 2001 09:55:00 -0000	[thread overview]
Message-ID: <20010116125534.G17998@redhat.com> (raw)
In-Reply-To: <0056890019114738000002L982*@MHS>

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-----

  reply	other threads:[~2001-01-16  9:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-16  6:38 norbert.c.esser
2001-01-16  9:55 ` Frank Ch. Eigler [this message]
2001-01-16 14:26   ` matthew green
  -- strict thread matches above, loose matches on Subject: below --
2001-01-17  0:37 Bernard Dautrevaux
2001-01-16 11:04 Bernard Dautrevaux
2001-01-16 13:09 ` Frank Ch. Eigler
2001-01-16 14:46 ` Ben Elliston
2001-01-16  1:23 norbert.c.esser
2001-01-16  4:39 ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010116125534.G17998@redhat.com \
    --to=fche@redhat.com \
    --cc=norbert.c.esser@philips.com \
    --cc=sid@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).