This is the mail archive of the gdb@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: [RFC] Let "gcore" command accept a suffix argument


I think if each command can support $v directly is better.

For example:
set $a=0
gcore $a
Saved corefile 0

Thanks,
Hui

On Sun, Nov 29, 2009 at 10:19, Michael Snyder <msnyder@vmware.com> wrote:
> I can't find the reference message, but I have a recollection
> about somebody asking why some gdb command (may have been 'gcore')
> couldn't accept a gdb internal variable so that the filename could
> in effect be "computed", or disambiguated, to avoid overwriting.
>
> Having just done this for "record save", I thought I'd float the
> idea of generalizing it.
>
> 1) So -- what if 'gcore' were to accept an optional second argument
> which, if present, would be treated as an integer and suffixed to
> the gcore filename? ?So for instance:
>
> (gdb) set $a = 0
> (gdb) gcore foo $a++
> (gdb) step
> (gdb) gcore foo $a++
> (gdb) step
> (gdb) gcore foo $a++
>
> would result in three files: foo.0, foo.1, and foo.2.
>
> 2) Similarly, what if we were to do the same thing with
> add_setshow_filename_cmd, which is used for commands such
> as "set logging filename". ?Then a series of logging files
> could be created, each with a unique filename.
>
> Yes, I know, we could do the same thing with Python, but
> I'm not convinced that that is an argument against doing it
> stand alone (maybe for users who don't want to learn python).
>
> I'm prepared to submit a patch for 1 and 2, separately or together.
>
>
>
>


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