This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [sim] new port: Renesas RL78


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]