Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Grant Edwards <grante@visi.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Joel Brenner <"\x03joel".brenner@tchip.com>, gdb@sourceware.cygnus.com
Subject: Re: Semihosting output on ARM7TDMI
Date: Tue, 14 Aug 2001 09:24:00 -0000	[thread overview]
Message-ID: <20010814112608.A8586@visi.com> (raw)
In-Reply-To: <3B794DA5.5020700@cygnus.com>

On Tue, Aug 14, 2001 at 12:11:17PM -0400, Andrew Cagney wrote:

> > The routines in rdi-remote/hsys.c have no idea that gdb is "up
> > there" somewhere.
> >
> > The RDI file table is in a structure defined like so:
> > 
> > typedef struct {
> >   FILE *FileTable[HSYS_FOPEN_MAX] ;
> >   char FileFlags[HSYS_FOPEN_MAX] ;
> >   char *TempNames[UNIQUETEMPS];
> >   } OSblock;
> 
> If you don't route the output from the target through
> gdb_stdtarg then people, using GUI's, will complain that their
> output disappears or turns up in the wrong place. gdb_stdtarg
> captures all output and then passes it through to things like
> the console.

I understand.

But, the RDI stuff isn't aware of gdb, and it would take some
work to make it aware.  It would be "a good thing" but somebody
would have to want it bad enough to actuallly do it.

> How you manage to get the output routed to gdb_stdtarg, er,
> isn't my problem :-)

Nor mine, since I don't use semi-hosting.  ;)

> > It would be possible to make these routines "gdb aware" but
> > they aren't at the moment -- semi-hosting requests are handled
> > below the gdb<->RDI interface.
> 
> It isn't so much GDB aware not assume that the world is a UNIX
> tty.

Right now, the RDI host-end stuff assumes the world is a Unix
filesystem and that you have to open any files before you
access them.  The client-end stuff appears to assume that fd 0
is pre-opened. My three-line hack will (maybe) make accesses to
fd 0, 1, 2 translate into accesses to stdin, stdout, and
stderr.

Whether the user wants to access stdin/stdout/stderr verses the
the gdb console is another question.

> The theory is the same.  remote.c contains a working example of
> correctly wired output.  It also contains a nasty hack, from
> Cygnus/Cisco, to both co-ordinate target output and GDB input.
> 
> How much of that you need for tty UNIX I don't know.  I do know
> that and a lot more are needed to get GDB handling this
> correctly in a GUI environment.

It would be nice if the RDI code were made gdb-aware, but I'm
aware of no plans to do it.

-- 
Grant Edwards
grante@visi.com


  reply	other threads:[~2001-08-14  9:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-14  4:51 Joel Brenner
2001-08-14  7:56 ` Grant Edwards
2001-08-14  8:33   ` Andrew Cagney
2001-08-14  8:46     ` Grant Edwards
2001-08-14  9:11       ` Andrew Cagney
2001-08-14  9:24         ` Grant Edwards [this message]
2001-08-14  9:31           ` Keith Seitz
2001-08-14 11:43             ` Grant Edwards

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=20010814112608.A8586@visi.com \
    --to=grante@visi.com \
    --cc="\x03joelbrenner"@tchip.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb@sourceware.cygnus.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