This is the mail archive of the gdb-patches@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


Thanks Joel, I think the idea that you told is very good.

But I think we have know the type of the val that we want output, the
string we want it as string, the number we want it to be number.
Are you sure we need point out the type of val to be output?

And this idea is out of my ability.  Sorry about it.

Best regards,
Hui

On Sun, Jan 10, 2010 at 13:43, Joel Brobecker <brobecker@adacore.com> wrote:
>
> > The current eval doesn't like shell. ?It just use " point out the
> > simple string. ?And if the string is outside out ", eval will try to
> > convert it to val.
>
> OK, I think I understand, now. I see pros and cons to your approach.
> The approach I suggested (where we only expand convenience variables
> by detecting the $ sign) is limited because it does not handle
> expressions in general. ?Your proposal, does, which is more powerful.
>
> If the other maintainers like your syntax, then that'll be fine with me.
>
> I have a counter proposal: Have eval follow the same syntax as the
> printf command. ?In other words:
>
> ? ?(gdb) eval "gcore filename.%s.%d", suffix, $counter++
>
> That way, you save yourself having to implement yet-another-parser
> in GDB, however simple. All you have to do, is factorize the
> printf_command implementation into a function that stores the
> string in a memory ui_file, and have both printf_command and
> eval_command call that function.
>
> And we save ourselves the trouble of have to explain the syntax
> followed by the eval command, as it is identical to the syntax
> used by the printf command.
>
> How does that sound?
>
> --
> Joel


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