RE: [ECOS] Breakpoint problem

RE: [ECOS] Breakpoint problem

[Andreas.Karlsson]

The problem was too small stacksizes.



> == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

> 

> Andreas> Hi, When I set breakpoints in my code the gdb crashes with a

> Andreas> 'Program received signal SIGTRAP, Trace/breakpoint trap'.

> 

> This happens if the target hits a breakpoint at an address where GDB

> didn't put one. And I'm sure you mean that the target crashes with

> that output, not GDB. Right?

> 

> What is the address? By any chance, is that the address you first see

> when connecting to the target? If so, the target was reset, which

> obviously confuses GDB.

> 

> Andreas> It is possible to set breakpoints early in the code.

> 

> Yes. No. Maybe. Hard to say without more information.

> 

> Jesper

> 

Re: [ECOS] Breakpoint problem

[Jonathan Larmour]

"N.Suresh" wrote:
>     *)  When we execute (gdb)  b main
>            It is just doing some memory access ('m' packets) and
> updating it's internal data structures.

Yes.

>     *)  When we execute (gdb) c
>            The host sends a 'Z' packet to actually put the breakpoint.
>            But we are not processing this inside the stub.

Why do you say that? Admittedly it does depend on whether the target
supports the Z packet. If it doesn't, then GDb should fall back to using
memory writes to set a breakpoint (i.e. 'M' packets).

> But even then
> the target stops at main and GDB prints the
>             line number properly.

So surely that shows that the breakpoint was set...

>     After hitting the breakpoint:
>     *)   When we execute (gdb) c     it is sending a 's' packet and our
> stub is executing the single_step function and
>      target gives some errors but if we continue the execution after
> that, "Hello World!" is printed. Any
>      breakpoints after that is not hit.
> 
>     My questions are :
> 
>      How the target is stopping even when we are not putting a
> breakpoint at the given location ?
>      Why is the host (gdb) sending 's' packet for the second continue
> command?

GDB always does that if you're stopped at a software breakpoint. It's so
that it can execute one instruction and *then* reinstate the breakpoint. If
it just set the breakpoint again immediately we would hit it immediately
and we execution wouldn't continue!

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] Breakpoint problem

[N.Suresh]

Hi all,
    I am testing GDB stubs on ADS8260 board. (I am downloading 'hello'
program using gdb)
    Following is the observations i made:

    *)  When we execute (gdb)  b main
           It is just doing some memory access ('m' packets) and
updating it's internal data structures.
    *)  When we execute (gdb) c
           The host sends a 'Z' packet to actually put the breakpoint.
           But we are not processing this inside the stub. But even then
the target stops at main and GDB prints the
            line number properly.
    After hitting the breakpoint:
    *)   When we execute (gdb) c     it is sending a 's' packet and our
stub is executing the single_step function and
     target gives some errors but if we continue the execution after
that, "Hello World!" is printed. Any
     breakpoints after that is not hit.

    My questions are :

     How the target is stopping even when we are not putting a
breakpoint at the given location ?
     Why is the host (gdb) sending 's' packet for the second continue
command?
     Any options to be enabled in the stub building or any version
mismatch ?

thanx in advance,


--
!============================================================================!
= Suresh N., Research Engineer, C-DoT, Bangalore.                            =
= Call me at : OFF: 2383951(Dir) / 2263399 (268)  RES: 3334248               =
= Alternate email :  nsur_mys@email.com                                      =
= QOT: For fast-acting relief, try slowing down.
!============================================================================!




Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

RE: [ECOS] Breakpoint problem

[Andreas.Karlsson]

The target is an AEB-1 revC. It have been working just fine for several
months so something has happened.



> -----Original Message-----
From: Jesper Skov [ mailto:jskov@redhat.com ]
Sent: den 19 oktober 2000 14:50
To: Karlsson Andre

> as
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] Breakpoint problem


>>>>> "Andreas" 

> == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

> 

> Andreas> Hi, When I set breakpoints in my code the gdb crashes with a

> Andreas> 'Program received signal SIGTRAP, Trace/breakpoint trap'.

> 

> This happens if the target hits a breakpoint at an address where GDB

> didn't put one. And I'm sure you mean that the target crashes with

> that output, not GDB. Right?

Yes, you are right the message pops up in GDB but GDB still run.



> What is the address? By any chance, is that the address you first see

> when connecting to the target? If so, the target was reset, which

> obviously confuses GDB.

The address changes every time. Sometimes it is inside a process stack,
sometimes in any function and sometimes way out of memory.

> Yes. No. Maybe. Hard to say without more information.

I download 187 Kb.



Well, while trying to reproduce the error (It has been there for two days) I
figured out that it seems to be gone... 

I don't know why but anyway:) I've been doing some bug-fixing, without
breakpoints so someway I solved my problem (I hope).

Thanks anyway!



brgs

Andreas

Re: [ECOS] Breakpoint problem

[Jonathan Larmour]

Jesper Skov wrote:
> 
> >>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:
> 
> Andreas> Hi, When I set breakpoints in my code the gdb crashes with a
> Andreas> 'Program received signal SIGTRAP, Trace/breakpoint trap'.
> 
> This happens if the target hits a breakpoint at an address where GDB
> didn't put one. And I'm sure you mean that the target crashes with
> that output, not GDB. Right?
> 
> What is the address? By any chance, is that the address you first see
> when connecting to the target? If so, the target was reset, which
> obviously confuses GDB.

If this is a MIPS target, as I think it is, it may be an issue with sign
extension. I have a fix but I haven't checked it in yet as I'm unhappy with
it coz I haven't tested it enough and I think it may be break other
targets.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Breakpoint problem

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

Andreas> Hi, When I set breakpoints in my code the gdb crashes with a
Andreas> 'Program received signal SIGTRAP, Trace/breakpoint trap'.

This happens if the target hits a breakpoint at an address where GDB
didn't put one. And I'm sure you mean that the target crashes with
that output, not GDB. Right?

What is the address? By any chance, is that the address you first see
when connecting to the target? If so, the target was reset, which
obviously confuses GDB.

Andreas> It is possible to set breakpoints early in the code.

Yes. No. Maybe. Hard to say without more information.

Jesper

[ECOS] Breakpoint problem

[Andreas.Karlsson]

Hi,

When I set breakpoints in my code the gdb crashes with a 'Program received
signal SIGTRAP, Trace/breakpoint trap'.

It is possible to set breakpoints early in the code.

Anyone has any idea of why, could short of memory be the reason?

brgs Andreas