Re: remote target => putpkt: write failed: Permission denied.

Re: remote target => putpkt: write failed: Permission denied.

[Fernando Nasser]

Grant Edwards wrote:
> 
> arm-elf-gdb
> Cygwin/WinNT
> remote target @ 57600
> 
> I'm using Insight 5.0 with an ARM7 board running gdb stubs.
> 
> Everything works fine if I run "-nw", but with the GUI enabled,
> I can't even connect.  When I do a "target remote COM1"
> 

Grant,

You should not be connecting from the simulated console, specially
in the 5.0 (old) version.

Use the GUI menus to connect.  There is a Target dialog for you
to configure how and to where you want to connect and also
menu options for connecting, disconnecting etc.

In the recent snapshots, after Keith's latest rewrites, it is
possible that this kind of command issued from the Console Window 
properly notify the rest of the GUI (I'm not sure though), but in
the version you are using it will just confuse it.

Regards,
Fernando



> I get the error:
> 
>   (gdb) target remote COM1
> 
>   Couldn't establish conenction to remote target
>   putpkt: write failed: Permission denied.
> 
>   Remote debuggin using COM1
> 
>   (gdb)
> 
> After that, nothing that accesses the target will work.
> 
> Any clues?
> 


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: remote target => putpkt: write failed: Permission denied.

[Grant Edwards]

On Mon, Nov 12, 2001 at 10:03:11AM -0500, Fernando Nasser wrote:

> You should not be connecting from the simulated console, specially
> in the 5.0 (old) version.
> 
> Use the GUI menus to connect.  

Yes, that's what I ended up doing (though I'm not keen on GUI menus, so I
generally just use "-nw" mode).

> There is a Target dialog for you to configure how and to where you want to
> connect and also menu options for connecting, disconnecting etc.

I see. The odd thing is that I've always connected via console commands when
I use the RDI target.  The main advantage is you can put the target commands
in the .gdbinit file so that you don't have to do the dialog business every
time.  You just type "gdb" and it connects to the target, downloads the
program, and gets everything ready to go.

> In the recent snapshots, after Keith's latest rewrites, it is
> possible that this kind of command issued from the Console Window 
> properly notify the rest of the GUI (I'm not sure though), but in
> the version you are using it will just confuse it.

Yes, it certainly seems to when you use the "remote" target.

-- 
Grant Edwards
grante@visi.com

Re: remote target => putpkt: write failed: Permission denied.

[Tom Tromey]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> I see. The odd thing is that I've always connected via console
Grant> commands when I use the RDI target.

I think it is important that Insight continue to support the habits of
those switching from the command-line gdb.  However, Insight hacking
time has historically been limited, so this doesn't always happen --
perfectly understandable imo.

Feel like doing some Insight hacking? :-)
Failing that maybe a PR is the best bet.

Grant> The main advantage is you can put the target commands in the
Grant> .gdbinit file so that you don't have to do the dialog business
Grant> every time.  You just type "gdb" and it connects to the target,
Grant> downloads the program, and gets everything ready to go.

Ideally we could extend sessions to capture this information.  I
rarely do any non-native debugging, so when I wrote the session code I
didn't add this feature.  There is some minimal support for it;
expanding it would make a lot of sense.  I think it would be best if
this work (or at least a specification for it) were done by someone
who is really familiar with non-native debugging.

Tom

remote target => putpkt: write failed: Permission denied.

[Grant Edwards]

arm-elf-gdb
Cygwin/WinNT
remote target @ 57600

I'm using Insight 5.0 with an ARM7 board running gdb stubs.

Everything works fine if I run "-nw", but with the GUI enabled,
I can't even connect.  When I do a "target remote COM1"

I get the error:

  (gdb) target remote COM1

  Couldn't establish conenction to remote target
  putpkt: write failed: Permission denied.

  Remote debuggin using COM1

  (gdb)
  
After that, nothing that accesses the target will work.

Any clues?

-- 
Grant Edwards
grante@visi.com

Re: remote target => putpkt: write failed: Permission denied.

[Fernando Nasser]

Grant Edwards wrote:
> 
> arm-elf-gdb
> Cygwin/WinNT
> remote target @ 57600
> 
> I'm using Insight 5.0 with an ARM7 board running gdb stubs.
> 
> Everything works fine if I run "-nw", but with the GUI enabled,
> I can't even connect.  When I do a "target remote COM1"
> 

Grant,

You should not be connecting from the simulated console, specially
in the 5.0 (old) version.

Use the GUI menus to connect.  There is a Target dialog for you
to configure how and to where you want to connect and also
menu options for connecting, disconnecting etc.

In the recent snapshots, after Keith's latest rewrites, it is
possible that this kind of command issued from the Console Window 
properly notify the rest of the GUI (I'm not sure though), but in
the version you are using it will just confuse it.

Regards,
Fernando



> I get the error:
> 
>   (gdb) target remote COM1
> 
>   Couldn't establish conenction to remote target
>   putpkt: write failed: Permission denied.
> 
>   Remote debuggin using COM1
> 
>   (gdb)
> 
> After that, nothing that accesses the target will work.
> 
> Any clues?
> 


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: remote target => putpkt: write failed: Permission denied.

[Grant Edwards]

On Mon, Nov 12, 2001 at 10:03:11AM -0500, Fernando Nasser wrote:

> You should not be connecting from the simulated console, specially
> in the 5.0 (old) version.
> 
> Use the GUI menus to connect.  

Yes, that's what I ended up doing (though I'm not keen on GUI menus, so I
generally just use "-nw" mode).

> There is a Target dialog for you to configure how and to where you want to
> connect and also menu options for connecting, disconnecting etc.

I see. The odd thing is that I've always connected via console commands when
I use the RDI target.  The main advantage is you can put the target commands
in the .gdbinit file so that you don't have to do the dialog business every
time.  You just type "gdb" and it connects to the target, downloads the
program, and gets everything ready to go.

> In the recent snapshots, after Keith's latest rewrites, it is
> possible that this kind of command issued from the Console Window 
> properly notify the rest of the GUI (I'm not sure though), but in
> the version you are using it will just confuse it.

Yes, it certainly seems to when you use the "remote" target.

-- 
Grant Edwards
grante@visi.com

Re: remote target => putpkt: write failed: Permission denied.

[Tom Tromey]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> I see. The odd thing is that I've always connected via console
Grant> commands when I use the RDI target.

I think it is important that Insight continue to support the habits of
those switching from the command-line gdb.  However, Insight hacking
time has historically been limited, so this doesn't always happen --
perfectly understandable imo.

Feel like doing some Insight hacking? :-)
Failing that maybe a PR is the best bet.

Grant> The main advantage is you can put the target commands in the
Grant> .gdbinit file so that you don't have to do the dialog business
Grant> every time.  You just type "gdb" and it connects to the target,
Grant> downloads the program, and gets everything ready to go.

Ideally we could extend sessions to capture this information.  I
rarely do any non-native debugging, so when I wrote the session code I
didn't add this feature.  There is some minimal support for it;
expanding it would make a lot of sense.  I think it would be best if
this work (or at least a specification for it) were done by someone
who is really familiar with non-native debugging.

Tom