[ECOS] breakpoint () support locking app

[ECOS] breakpoint () support locking app

[Trenton D. Adams]

I try and start the application the usual way by downloading over the
network with gdb, and then running it.  It doesn't do anything at all.
The program just locks right off the get go.  Any idea why this might
happen?

RE: [ECOS] breakpoint () support locking app

[Gary Thomas]

On 10-Jul-2001 Trenton D. Adams wrote:
> I try and start the application the usual way by downloading over the
> network with gdb, and then running it.  It doesn't do anything at all.
> The program just locks right off the get go.  Any idea why this might
> happen?

What does this behaviour have to do with the subject of your email?

Have you tried setting a breakpoint within your code?  If so, what
happens?

RE: [ECOS] breakpoint () support locking app

[Trenton D. Adams]

Sorry, I forgot to mention that I'm using the GDB stub support with the
breakpoint () function.  With this support added the code won't run, it
hangs right off the bat.

  > -----Original Message-----
  > From: gary@chez-thomas.org [ mailto:gary@chez-thomas.org ] On 
  > Behalf Of Gary Thomas
  > Sent: Wednesday, July 11, 2001 6:08 AM
  > To: Trenton D. Adams
  > Cc: eCos discussion
  > Subject: RE: [ECOS] breakpoint () support locking app
  > 
  > 
  > 
  > On 10-Jul-2001 Trenton D. Adams wrote:
  > > I try and start the application the usual way by 
  > downloading over the 
  > > network with gdb, and then running it.  It doesn't do 
  > anything at all. 
  > > The program just locks right off the get go.  Any idea 
  > why this might 
  > > happen?
  > 
  > What does this behaviour have to do with the subject of your email?
  > 
  > Have you tried setting a breakpoint within your code?  If 
  > so, what happens?
  > 

RE: [ECOS] breakpoint () support locking app

[Gary Thomas]

On 11-Jul-2001 Trenton D. Adams wrote:
> Sorry, I forgot to mention that I'm using the GDB stub support with the
> breakpoint () function.  With this support added the code won't run, it
> hangs right off the bat.

How are you downloading the code?

> 
>   > -----Original Message-----
>   > From: gary@chez-thomas.org [ mailto:gary@chez-thomas.org ] On 
>   > Behalf Of Gary Thomas
>   > Sent: Wednesday, July 11, 2001 6:08 AM
>   > To: Trenton D. Adams
>   > Cc: eCos discussion
>   > Subject: RE: [ECOS] breakpoint () support locking app
>   > 
>   > 
>   > 
>   > On 10-Jul-2001 Trenton D. Adams wrote:
>   > > I try and start the application the usual way by 
>   > downloading over the 
>   > > network with gdb, and then running it.  It doesn't do 
>   > anything at all. 
>   > > The program just locks right off the get go.  Any idea 
>   > why this might 
>   > > happen?
>   > 
>   > What does this behaviour have to do with the subject of your email?
>   > 
>   > Have you tried setting a breakpoint within your code?  If 
>   > so, what happens?
>   > 

RE: [ECOS] breakpoint () support locking app

[Trenton D. Adams]

  > On 11-Jul-2001 Trenton D. Adams wrote:
  > > Sorry, I forgot to mention that I'm using the GDB stub 
  > support with 
  > > the breakpoint () function.  With this support added the 
  > code won't 
  > > run, it hangs right off the bat.
  > 
  > How are you downloading the code?

I'm using GDB to do it over the network.  It's the same way I've been
doing it right from the start of the project.


target remote 172.16.1.240:9000
load
continue

RE: [ECOS] breakpoint () support locking app

[Gary Thomas]

On 11-Jul-2001 Trenton D. Adams wrote:
>   > On 11-Jul-2001 Trenton D. Adams wrote:
>   > > Sorry, I forgot to mention that I'm using the GDB stub 
>   > support with 
>   > > the breakpoint () function.  With this support added the 
>   > code won't 
>   > > run, it hangs right off the bat.
>   > 
>   > How are you downloading the code?
> 
> I'm using GDB to do it over the network.  It's the same way I've been
> doing it right from the start of the project.
> 
> 
> target remote 172.16.1.240:9000
> load
> continue

As I expected.  Sorry, but this can't work because as soon as the target
application tries to run, the GDB debug channel will break.  In fact, if
you have a 'minicom' session open to the board, you'll probably see GDB
come up there.

Network debugging is only supported using RedBoot - it cannot be done
with builtin stubs (when stubs are included in the application).

RE: [ECOS] breakpoint () support locking app

[Trenton D. Adams]

  > 
  > As I expected.  Sorry, but this can't work because as soon 
  > as the target application tries to run, the GDB debug 
  > channel will break.  In fact, if you have a 'minicom' 
  > session open to the board, you'll probably see GDB come up there.
  > 
  > Network debugging is only supported using RedBoot - it 
  > cannot be done with builtin stubs (when stubs are included 
  > in the application).
  > 

Ok, I thought that might be the case because when I opened the com port
while trying to connect through the network it gave me a bunch of
garbage.  

So, will the GDB stub watch on port 9000 too if I was to start it on
it's own?

RE: [ECOS] breakpoint () support locking app

[Gary Thomas]

On 11-Jul-2001 Trenton D. Adams wrote:
>   > 
>   > As I expected.  Sorry, but this can't work because as soon 
>   > as the target application tries to run, the GDB debug 
>   > channel will break.  In fact, if you have a 'minicom' 
>   > session open to the board, you'll probably see GDB come up there.
>   > 
>   > Network debugging is only supported using RedBoot - it 
>   > cannot be done with builtin stubs (when stubs are included 
>   > in the application).
>   > 
> 
> Ok, I thought that might be the case because when I opened the com port
> while trying to connect through the network it gave me a bunch of
> garbage.  
> 
> So, will the GDB stub watch on port 9000 too if I was to start it on
> it's own?

No - you'd need the whole network stack included with the application.
Once you have GDB stubs in your application, they take over the GDB debug
operation.  Since our stubs only know how to handle serial, unless they
are extended via RedBoot, you'd pretty much be stuck here.

It would be possible to build a stand-alone application which supports
GDB debugging via the network.  However, you'd pretty much end up with
everything from RedBoot (you'd need the RedBoot network stack, not the
generic TCP/IP stack from eCos) tucked into your application.

... probably not what you really wanted.

RE: [ECOS] breakpoint () support locking app

[Trenton D. Adams]

Oops, sorry dumb question.  I already said no.  I just thought you meant
it wouldn't work with RedBoot running.

  > -----Original Message-----
  > From: Trenton D. Adams [ mailto:tadams@extremeeng.com ] 
  > Sent: Wednesday, July 11, 2001 9:03 AM
  > To: 'Gary Thomas'
  > Cc: 'eCos discussion'
  > Subject: RE: [ECOS] breakpoint () support locking app
  > 
  > 
  >   > 
  >   > As I expected.  Sorry, but this can't work because as soon 
  >   > as the target application tries to run, the GDB debug 
  >   > channel will break.  In fact, if you have a 'minicom' 
  >   > session open to the board, you'll probably see GDB come 
  > up there.
  >   > 
  >   > Network debugging is only supported using RedBoot - it 
  >   > cannot be done with builtin stubs (when stubs are included 
  >   > in the application).
  >   > 
  > 
  > Ok, I thought that might be the case because when I opened 
  > the com port while trying to connect through the network it 
  > gave me a bunch of garbage.  
  > 
  > So, will the GDB stub watch on port 9000 too if I was to 
  > start it on it's own?
  >