gdb: target remote in detached state...

gdb: target remote in detached state...

[Mukesh]

Hello.
I am currently writing a gdbserver stub for an embedded environment.

So, when firing up gdb and doing target remote or extended-remote, I
noticed gdb assumes the remote is connected and has a context etc. I was
wondering if it was possible to somehow tell gdb that is not the case, and
force my user to attach to a process on the remote side. Of course I could
fake all that in the beginning, and tell users to ignore and make them run
"attach" first thing.. but I wondered if there was some way to do it
automatically. IOW,
   gdb target remote/extended-remote : just hand shake
   gdb> info threads:   send gdb/user list of threads
   gdb> attach n: attach now to thread n
   gdb> regular reason, context, etc...

Kindly cc me as I am not subscribed. Thank you!

-Mukesh

Re: gdb: target remote in detached state...

[Hannes Domani]

 Am Mittwoch, 29. Dezember 2021, 00:51:56 MEZ hat Mukesh via Gdb-patches <gdb-patches@sourceware.org> Folgendes geschrieben:

> Hello.
> I am currently writing a gdbserver stub for an embedded environment.
>
> So, when firing up gdb and doing target remote or extended-remote, I
> noticed gdb assumes the remote is connected and has a context etc. I was
> wondering if it was possible to somehow tell gdb that is not the case, and
> force my user to attach to a process on the remote side. Of course I could
> fake all that in the beginning, and tell users to ignore and make them run
> "attach" first thing.. but I wondered if there was some way to do it
> automatically. IOW,
>   gdb target remote/extended-remote : just hand shake
>   gdb> info threads:  send gdb/user list of threads
>   gdb> attach n: attach now to thread n
>   gdb> regular reason, context, etc...
>
> Kindly cc me as I am not subscribed. Thank you!

"target extended-remote" does not assume that the remote already has a context.
Because if you start gdbserver with the "--multi" argument, you can then
(on gdb side, after "target extended-remote") use "attach", and it will attach
the specified process on the remote side.

For the list of available threads/processes, "info os threads"/
"info os processes" (qXfer:osdata:read) needs to be implemented by gdbserver.


Hannes

Re: gdb: target remote in detached state...

[Mukesh]

> "target extended-remote" does not assume that the remote already has a
context.
Actually, it does ask send '?' and 'g', and does not like error or null
response.

> Because if you start gdbserver with the "--multi" argument
Problem is gdbservers is also in an embedded environment where it is not
possible to pass arguments. It is custom.

It appears just returning fake context and stop reason seems to make it
happy. I can then force user to attach to a target.

Thanks
Mukesh


On Tue, Dec 28, 2021 at 4:53 PM Hannes Domani <ssbssa@yahoo.de> wrote:

>  Am Mittwoch, 29. Dezember 2021, 00:51:56 MEZ hat Mukesh via Gdb-patches <
> gdb-patches@sourceware.org> Folgendes geschrieben:
>
> > Hello.
> > I am currently writing a gdbserver stub for an embedded environment.
> >
> > So, when firing up gdb and doing target remote or extended-remote, I
> > noticed gdb assumes the remote is connected and has a context etc. I was
> > wondering if it was possible to somehow tell gdb that is not the case,
> and
> > force my user to attach to a process on the remote side. Of course I
> could
> > fake all that in the beginning, and tell users to ignore and make them
> run
> > "attach" first thing.. but I wondered if there was some way to do it
> > automatically. IOW,
> >   gdb target remote/extended-remote : just hand shake
> >   gdb> info threads:  send gdb/user list of threads
> >   gdb> attach n: attach now to thread n
> >   gdb> regular reason, context, etc...
> >
> > Kindly cc me as I am not subscribed. Thank you!
>
> "target extended-remote" does not assume that the remote already has a
> context.
> Because if you start gdbserver with the "--multi" argument, you can then
> (on gdb side, after "target extended-remote") use "attach", and it will
> attach
> the specified process on the remote side.
>
> For the list of available threads/processes, "info os threads"/
> "info os processes" (qXfer:osdata:read) needs to be implemented by
> gdbserver.
>
>
> Hannes
>