Re: gdba probs

[Nick Roberts]

Stefan Monnier writes:

 > > Regarding the bunches of errors, they occur because you're using commands
 > > that stop/step at the instruction level (break *_start, stepi, etc).
 > > Handling these commands is on my TODO list. ;-)
 > 
 > I have no idea what this entails, but maybe it is related to another
 > wish of mine: to make it usable when running "gdb --fullname foo".
 > Right now, it seems that if gdb is not started with "--annotate=2"
 > gdba just "freezes" (typing stuff at gdb prompt leads nowhere).

I don't think they're related. The bunches of errors occur because
gdb-info-breakpoints-custom only parses the output of "info breakpoints"
properly when they are at a statement boundary (have a line no. associated
with them) to place to breakpoint icons. There will be similar problems with
"info frames".

I don't know exactly what happens if gdba starts without "--annotate=2" but
the annotations are needed to tell it the status of the prgram. "--fullname"
just gives line information for display of the source. 

Looking at it, gdba doesn't freeze but to seems expect its input to come from
the input/output buffer (try, for example, typing break main in there)

 > I understand that with "gdb --fullname foo" most things won't work, but I'd
 > like to slowly merge M-x gdb and M-x gdba, so I think that the gdba
 > code should be made to work even if the underlying gdb process is not
 > configured as expected: it should then behave more or less like M-x gdb does.

You could infer how gdb was running from the lack/type of annotations (=1, =2)
but I don't think this would be easy. At the moment I run two gdb commands
requiring annotations *before* the executable is run to find out in what
file main is stored.

 > C-h f replace-regexp ;-)

I've also used insert-buffer. C-h f gives :

  This function is meant for the user to run interactively.
  Don't call it from programs!

What should I use this time ?

Nick