Re: [PATCH] testsuite: Record all gdb input to gdb.in

[Alan Hayward <Alan.Hayward@arm.com>]

> On 30 Apr 2019, at 16:06, Tom Tromey <tom@tromey.com> wrote:
> 
>>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
> 
> Alan> Once a test has been run, the .in file can be used to re-run the test in the
> Alan> following way:
> 
> Alan>   gdb -x outputs/gdb.store/gdb.in outputs/gdb.store/store
> 
> Alan> Note, this functionality is ALWAYS on when running a test.  I considered this
> Alan> would be more useful than making it optional.
> 
> I think it probably makes sense to delete the existing TRANSCRIPT code
> when doing this.

Ok. I hadn’t realised this was more or less doing the same thing. 

> 
> Alan> +      # First time opening.
> Alan> +      set in_file_count 0
> Alan> +      set logfile [standard_output_file gdb.in]
> 
> Does anything ever reset in_file_count?
> Or if you run a bunch of test cases, will the number just keep incrementing?

I was running -j55, which was wide enough to ensure most things were starting
fresh at 0.  I’ll add something to fix this up.

> 
> Alan> +    switch -regexp -- $type {
> 
> Why -regexp?

I’ll remove.

> 
> Alan> +    #Write to the log
> 
> Space after the "#”.

Ok.

> 
> Alan> +    puts -nonewline $in_file "$message"
> 
> It may be good for this code to catch errors, not sure though.

Not sure if you mean test case errors or file write errors.
If the former, my motivation was so that the .in file could be used with
“gdb -x gdb.in”. Anything that’s not a command will break this.

I’ve been working on some additional stuff today, including gdbserver 
replaylog and a script to easily re-run tests using the .in file and/or
replay.  I’ll throw the update to this together with that as a new series
(might not be until next week as I’ve got some vacation).

Thanks for the review.


Alan.