command_line_input() not re-entrant

[Andrew STUBBS <andrew dot stubbs at st dot com>]

Hi,

I have discovered a problem in the GDB command line reading code.

command_line_input() uses a static buffer to hold the current command. 
This means that it is not properly re-entrant - commands that contain 
other commands, such as user defined commands, are not handled safely.

In practice the only real trouble I have observed is with user defined 
commands that use $arg0 etc. because these parameters are never copied 
out of the original string, so are overwritten the next time 
command_line_input() is invoked. Even then, this is not normally a 
problem because command_line_input() is not normally needed within a 
user-defined command - it has already been read. It is only a problem 
when the user defined command contains a source command.

The problem may be reproduced as follows:

Create three files:

a1
---8<---------->8-----
source a2
abcdef qwerty
---8<---------->8-----

a2
---8<---------->8-----
define abcdef
  echo 1: <<<$arg0>>>\n
  source a3
  echo 2: <<<$arg0>>>\n
end
---8<---------->8-----

a3
---8<---------->8-----
#################################################################
---8<---------->8-----

Then run the following command:

$ gdb -nx -q -x a1 -batch
1: <<<qwerty>>>
2: <<<######>>>

Both 1: and 2: should have been the same. As you can see the contents of 
a3 have overwritten the value of $arg0 in abcdef. For some reason I 
haven't discovered (and probably boils down to dumb luck) I can't 
reproduce the problem when entering a1 interactively - I have to source it.

I am happy to write the patch to fix this but I am wondering how. There 
seem to be two possible ways:

1. Make command_line_input() re-entrant. Perhaps drop the static buffer 
and malloc a new string each time. Free it through a clean-up.

2. Have setup_user_args() copy the data and adjust the clean up to free 
the copied data.

Any preferences or other suggestions?

Andrew Stubbs