Path: utzoo!telly!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!WSL.DEC.COM!bothner
From: bothner@WSL.DEC.COM
Newsgroups: gnu.gdb.bug
Subject: gdb suggestions
Message-ID: <8912190414.AA22958@gilroy.pa.dec.com>
Date: 19 Dec 89 04:14:58 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 97

Here are a number of suggestions for gdb. Most of
them are to make porting easier; a few are user-visible.

***
May I suggest the following change:
print_source_lines in source.c:
  error ("Line number out of range ...", ...)
  should probably be:
  error ("Line number %d out of range ...", line, ...)

***
call_function in valops.c uses value_push_arg to pass arguments.
This seems insufficiently flexible. It *almost* works
for the mips calling convention. (I just make the CALL_DUMMY
copy the pushed values to the correct registers.)
However, it does not handle correct alignment (double-precision
floats must be aligned on even words).
I also believe it will lose for machines whose stack
grows downwards.
Perhaps something like the following is reasonable:
#ifdef PUSH_ARGS
  PUSH_ARGS(args, nargs, sp);
#else
  for (i = nargs - 1; i >= 0; i--)
    sp = value_arg_push (sp, args[i]);
#endif

***
Consider the following machine pseudo-code for a function:
G:
  PROLOGUE
  CALL F
L:
  RETURN
Suppose the PC is in F, The user does an UP,
and tries to print a local variable in G.
This fails because the return PC is at L, which is
the end of the scope of locals of F.
Since gdb interprets this to mean that the PC
is outside the scope of G's locals, it complains
that the variable in not in the current context.
This seems very unfortunate, though I'm not sure
what the correct fix is.

***
I'm having some problems with the way find_pc_partial_function
is used in wait_for_inferior. The problem is that I don't use
partial symbol tables, and I only put non-statics in the
misc table. This means that all static procedures are the "same"
as whatever non-static function preceeds them (in memory).
I.e. next and nexti break.
Possible solutions:
+ Put static functions on the misc_function_list.
coffread.c does this, but it seems very ugly (would
arguably make print_address wrong).
+ Make dummy partial symbol tables. Again, ugly.
Also, doesn't work. But I believe it *would* work
if the indicated change were made. Any reason not to?
	  if (address)
	    *address = SYMBOL_VALUE (f);
  << add 'return 1;' here >>
	}
      /* Get the information from a combination of the pst
	 (static symbols), and the misc function vector (extern
+ Change implementation of find_pc_partial_function
to accept static functions. Again, changes print_address.
+ Change wait_for_inferior. The first find_pc_partial_function
could be replaced by get_pc_function_start. (This should be
just as good, since the start function's symtab has presumably
already been read in (?).) The only problem is handling _sigtrap;
one fix is to change get_pc_function_start to have the same
calling convention as find_pc_partial_function.
Another is to pre-compute the address bounds for _sigtramp
(just as gdb already does for _start).
+ Even better might be to avoid the second find_pc_partial_function
as well, by checking if the stop_pc is inside the prev_function.
This could speed things up quite a bit.

***
If we break somewhere at a breakpoint set with 'break*', or
if the previous command was 'stepi' or 'nexti',
then the current instruct should be dis-assembled and printed.
The source line should also be printed, but only once (i.e.
remember the previous source line, and don't print if it
is the same). Same if the current function has no source/symbols:
Only print "No such file or directory" *once* on
entering a file, not on every instruction.
Thus doing nexti followed by many '\n' prints out the source
instruction followed by the dis-assembled instructions, as they
are executed. (This would win even more if readline could accept
an option to just erase the prompt (instead of echoing '\n') when
the user returns an empty line. I did this for a V-system [V as
in Vee, not 5] port of gdb, and it was really nice.)

	--Per Bothner
bothner@wsl.dec.com Western Software Lab, 181 Lytton, Palo Alto CA 94301
After 90/1/7: bothner@cs.wisc.edu Comp.Sci., Univ. of Wisconsin, Madison WI