From: DJ Delorie <dj@redhat.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [sim] new port: Renesas RL78
Date: Wed, 16 Nov 2011 19:36:00 -0000 [thread overview]
Message-ID: <201111161936.pAGJaKfW006960@greed.delorie.com> (raw)
In-Reply-To: <201111161409.19823.vapier@gentoo.org> (message from Mike Frysinger on Wed, 16 Nov 2011 14:09:18 -0500)
Replying only to the things that don't require a code change ("yet"
perhaps):
> > + $(ENDLIST)
>
> this $(ENDLIST) business looks like dead code ?
I've been brainwashed to end lists like this so that new lines always
end with a continuation char, which - in ancient and possibly modern
source control systems - prevents two independent additions from
becoming dependent on each other. It also allows you to sort or
otherwise mess with the list, without worrying about which lines have
continuation characters and which don't.
> > + printf("%s", buf);
>
> debug code ?
trace code.
> > + printf ("PSW: \033[31m");
> > + psw_string (old_psw);
> > + printf (" \033[32m");
>
> yikes, unavoidable ascii escapes ?
Yup. I'm a big fan of color when I'm sifting through at megabytes of
machine traces.
> > +#include <setjmp.h>
>
> doesn't seem to be used here
A jmp_buf is declared in that file.
> > +int
> > +main (int argc, char **argv)
> > +{
> > ...
> > + setbuf(stdout, NULL);
>
> doesn't this hurt performance ? especially when tracing ?
Very important when emulating the target serial port, though. I
suppose I could rework that logic, but so far I've mostly been worried
about "runs correctly" and not "runs fast".
> > --- /dev/null 1 Jan 1970 00:00:00 -0000
> > +++ sim/rl78/mem.c 16 Nov 2011 05:44:54 -0000
>
> seems like much of the utility of this file is duplicating the core mapping=
> s=20
> logic in like common/sim-core.c :/
It's mostly about emulating memory-mapped hardware and the weird RL78
mapping rules, though. The common parts are a small part of it.
> > + fprintf (stack_tty, "\033[1;1H\033[J");
> > +}
> > +#endif
>
> in general though, yikes ... looks like this would be better as a command l=
> ine=20
> option specifying the output ...
Perhaps. I'm used to being able to just tweak the sources as needed ;-)
And again, that's probably not code you *want* the average person to
use. What it does is maintain a LIVE stack trace on a tty while the
sim is running, so you can spot "stuck" patterns.
> > +#if 0
> > + if (trace)
> > + {
> > + int i;
> > + skip_init ++;
> > + for (i=3D0; i<8; i++)
> > + printf(" %02x", mem_get_qi (0xf0000 | (a + i)) & 0xff);
> > + skip_init --;
> > + }
> > +#endif
>
> just delete then ?
No, I keep chunks like this around if they're useful for exotic
debugging needs that don't warrant a command line option. This chunk,
for example, dumps the on-stack arguments to the trace for each CALL
insn.
next prev parent reply other threads:[~2011-11-16 19:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 6:07 DJ Delorie
2011-11-16 19:09 ` Mike Frysinger
2011-11-16 19:36 ` DJ Delorie [this message]
2011-11-16 19:47 ` Mike Frysinger
2011-11-16 21:45 ` Mike Frysinger
2011-11-17 19:16 ` DJ Delorie
2011-11-17 19:39 ` Mike Frysinger
2011-11-17 19:48 ` DJ Delorie
2011-11-17 19:53 ` Mike Frysinger
2011-11-17 21:34 ` DJ Delorie
2011-11-17 21:44 ` Mike Frysinger
2011-11-28 20:03 ` DJ Delorie
2011-11-28 20:13 ` Mike Frysinger
2011-11-28 21:01 ` Stan Shebs
2011-11-28 21:16 ` DJ Delorie
2011-11-29 3:50 ` DJ Delorie
2011-11-29 4:08 ` Eli Zaretskii
2011-11-29 1:38 ` Mike Frysinger
2012-03-23 4:33 ` Mike Frysinger
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=201111161936.pAGJaKfW006960@greed.delorie.com \
--to=dj@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=vapier@gentoo.org \
/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