* GDB printf command @ 2006-10-17 12:03 Andrew STUBBS 2006-10-17 13:24 ` Daniel Jacobowitz 0 siblings, 1 reply; 10+ messages in thread From: Andrew STUBBS @ 2006-10-17 12:03 UTC (permalink / raw) To: GDB List Hi, The %ll issue, recently discussed on the patches list, was originally reported to me against GDB 6.4. While testing my fix to GDB 6.5 I have discovered that the new version is even more broken than the old one (at least in some respects, no doubt whatever it set out to fix was achieved). Specifically '%lf' is not permitted. This used to work and is permitted by both C90 and C99. Can anybody tell me why this is the case - it seems deliberate - and what is the intended range of capabilities of this command? It would appear to me to be most useful if it can operate on any type the GDB expression parser is capable of handling, regardless of host system. Thanks Andrew Stubbs ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-17 12:03 GDB printf command Andrew STUBBS @ 2006-10-17 13:24 ` Daniel Jacobowitz 2006-10-17 14:10 ` Andrew STUBBS 0 siblings, 1 reply; 10+ messages in thread From: Daniel Jacobowitz @ 2006-10-17 13:24 UTC (permalink / raw) To: Andrew STUBBS; +Cc: GDB List On Tue, Oct 17, 2006 at 01:03:33PM +0100, Andrew STUBBS wrote: > Hi, > > The %ll issue, recently discussed on the patches list, was originally > reported to me against GDB 6.4. > > While testing my fix to GDB 6.5 I have discovered that the new version > is even more broken than the old one (at least in some respects, no > doubt whatever it set out to fix was achieved). Correct. It was deliberately made stricter, because the older version could crash or internal error in more ways. > Specifically '%lf' is not permitted. This used to work and is permitted > by both C90 and C99. I don't remember what reference I used, but in C99 I see that this is deliberately ignored and the same as %f. Seems dumb to me, but there you go. > Can anybody tell me why this is the case - it seems deliberate - and > what is the intended range of capabilities of this command? > > It would appear to me to be most useful if it can operate on any type > the GDB expression parser is capable of handling, regardless of host system. It seems to me, as I wrote earlier, that the right thing to do would be to change it to work on target types rather than host types. It also seems to me that the right way to do this would be to reuse the printf format string parser from gnulib. We will have to map target types on to host types to get that to work, which will be a little hokey, but it should be doable for all interesting cases. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-17 13:24 ` Daniel Jacobowitz @ 2006-10-17 14:10 ` Andrew STUBBS 2006-10-17 14:25 ` Daniel Jacobowitz 0 siblings, 1 reply; 10+ messages in thread From: Andrew STUBBS @ 2006-10-17 14:10 UTC (permalink / raw) To: GDB List Daniel Jacobowitz wrote: >> Specifically '%lf' is not permitted. This used to work and is permitted >> by both C90 and C99. > > I don't remember what reference I used, but in C99 I see that this is > deliberately ignored and the same as %f. Seems dumb to me, but there > you go. Sorry, I opened my C90 standard at the wrong page and read that '%lf' is accepted for scanf by mistake - C90 says it is undefined for printf. C99 however ignores it, as you say, but that is not 'bad' as defined by GDB at present. It should be either passed through or converted to '%f'. > It seems to me, as I wrote earlier, that the right thing to do would be > to change it to work on target types rather than host types. It also > seems to me that the right way to do this would be to reuse the printf > format string parser from gnulib. We will have to map target types on > to host types to get that to work, which will be a little hokey, but it > should be doable for all interesting cases. The expression parser/evaluator must use host types at some level. Does this not have similar horrors hidden away? If this can convert target types to host types (of at least the same precision) can the printf not be implemented with the same mapping somehow? Andrew ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-17 14:10 ` Andrew STUBBS @ 2006-10-17 14:25 ` Daniel Jacobowitz 2006-10-17 14:43 ` Andrew STUBBS 0 siblings, 1 reply; 10+ messages in thread From: Daniel Jacobowitz @ 2006-10-17 14:25 UTC (permalink / raw) To: gdb On Tue, Oct 17, 2006 at 03:09:03PM +0100, Andrew STUBBS wrote: > The expression parser/evaluator must use host types at some level. Does > this not have similar horrors hidden away? If this can convert target > types to host types (of at least the same precision) can the printf not > be implemented with the same mapping somehow? Well, I suppose all we need to do is appropriate widening. We can pass everything to the host code as LONGESTs and DOUBLESTs. Are you interested in working on this? If so, I can quickly pull together a patch to add the printf backend that I was thinking of; all it'll need is glue. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-17 14:25 ` Daniel Jacobowitz @ 2006-10-17 14:43 ` Andrew STUBBS 2006-10-17 14:54 ` Daniel Jacobowitz 0 siblings, 1 reply; 10+ messages in thread From: Andrew STUBBS @ 2006-10-17 14:43 UTC (permalink / raw) To: gdb Daniel Jacobowitz wrote: > On Tue, Oct 17, 2006 at 03:09:03PM +0100, Andrew STUBBS wrote: >> The expression parser/evaluator must use host types at some level. Does >> this not have similar horrors hidden away? If this can convert target >> types to host types (of at least the same precision) can the printf not >> be implemented with the same mapping somehow? > > Well, I suppose all we need to do is appropriate widening. We can pass > everything to the host code as LONGESTs and DOUBLESTs. > > Are you interested in working on this? If so, I can quickly pull > together a patch to add the printf backend that I was thinking of; > all it'll need is glue. I'm not really sure what you are suggesting I do exactly. What do you think ought to be done and where? How much effort do you think it will take? Like everyone else I don't have enormous amounts of time for projects I wasn't expecting. Assuming it isn't a big task I am certainly interested in getting it done right. Whatever that is, hopefully it does include the same target working the same on all hosts (or at least all the same features working, for some definition of 'work'). Andrew ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-17 14:43 ` Andrew STUBBS @ 2006-10-17 14:54 ` Daniel Jacobowitz 2006-10-18 11:24 ` Andrew STUBBS 0 siblings, 1 reply; 10+ messages in thread From: Daniel Jacobowitz @ 2006-10-17 14:54 UTC (permalink / raw) To: gdb [-- Attachment #1: Type: text/plain, Size: 1638 bytes --] On Tue, Oct 17, 2006 at 03:43:18PM +0100, Andrew STUBBS wrote: > I'm not really sure what you are suggesting I do exactly. What do you > think ought to be done and where? I think we ought to run a format string parser to break up the string, then look at what arguments we've got and their types, and squeeze the two together. This sounds like a fairly complicated solution, and I'd agree, except that we can steal most of the code for it from this "gnulib" project I keep talking about: a collection of GPL and LGPL utility routines, designed to be imported into other projects. For example, I've attached the headers which handle the parsing. There's no "take this argument and format set and print it" function; it's all wrapped up in a vasnprintf implementation. However, we could trivially split that out, and ask the gnulib maintainers to accept such a change; I bet they would accept such a patch. Once we have the structure in place, we could basically replace printf_fetchargs (which uses va_arg) with something that operated on our list of values and did appropriate type checking / casts, then hand it back to the gnulib printf routine. > How much effort do you think it will take? Like everyone else I don't > have enormous amounts of time for projects I wasn't expecting. This I can not predict, I'm afraid. > Assuming it isn't a big task I am certainly interested in getting it > done right. Whatever that is, hopefully it does include the same target > working the same on all hosts (or at least all the same features > working, for some definition of 'work'). Precisely. -- Daniel Jacobowitz CodeSourcery [-- Attachment #2: printf-args.h --] [-- Type: text/x-chdr, Size: 2859 bytes --] /* Decomposed printf argument list. Copyright (C) 1999, 2002-2003 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ #ifndef _PRINTF_ARGS_H #define _PRINTF_ARGS_H /* Get size_t. */ #include <stddef.h> /* Get wchar_t. */ #ifdef HAVE_WCHAR_T # include <stddef.h> #endif /* Get wint_t. */ #ifdef HAVE_WINT_T # include <wchar.h> #endif /* Get va_list. */ #include <stdarg.h> /* Argument types */ typedef enum { TYPE_NONE, TYPE_SCHAR, TYPE_UCHAR, TYPE_SHORT, TYPE_USHORT, TYPE_INT, TYPE_UINT, TYPE_LONGINT, TYPE_ULONGINT, #ifdef HAVE_LONG_LONG TYPE_LONGLONGINT, TYPE_ULONGLONGINT, #endif TYPE_DOUBLE, #ifdef HAVE_LONG_DOUBLE TYPE_LONGDOUBLE, #endif TYPE_CHAR, #ifdef HAVE_WINT_T TYPE_WIDE_CHAR, #endif TYPE_STRING, #ifdef HAVE_WCHAR_T TYPE_WIDE_STRING, #endif TYPE_POINTER, TYPE_COUNT_SCHAR_POINTER, TYPE_COUNT_SHORT_POINTER, TYPE_COUNT_INT_POINTER, TYPE_COUNT_LONGINT_POINTER #ifdef HAVE_LONG_LONG , TYPE_COUNT_LONGLONGINT_POINTER #endif } arg_type; /* Polymorphic argument */ typedef struct { arg_type type; union { signed char a_schar; unsigned char a_uchar; short a_short; unsigned short a_ushort; int a_int; unsigned int a_uint; long int a_longint; unsigned long int a_ulongint; #ifdef HAVE_LONG_LONG long long int a_longlongint; unsigned long long int a_ulonglongint; #endif float a_float; double a_double; #ifdef HAVE_LONG_DOUBLE long double a_longdouble; #endif int a_char; #ifdef HAVE_WINT_T wint_t a_wide_char; #endif const char* a_string; #ifdef HAVE_WCHAR_T const wchar_t* a_wide_string; #endif void* a_pointer; signed char * a_count_schar_pointer; short * a_count_short_pointer; int * a_count_int_pointer; long int * a_count_longint_pointer; #ifdef HAVE_LONG_LONG long long int * a_count_longlongint_pointer; #endif } a; } argument; typedef struct { size_t count; argument *arg; } arguments; /* Fetch the arguments, putting them into a. */ #ifdef STATIC STATIC #else extern #endif int printf_fetchargs (va_list args, arguments *a); #endif /* _PRINTF_ARGS_H */ [-- Attachment #3: printf-parse.h --] [-- Type: text/x-chdr, Size: 2160 bytes --] /* Parse printf format string. Copyright (C) 1999, 2002-2003 Free Software Foundation, Inc. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ #ifndef _PRINTF_PARSE_H #define _PRINTF_PARSE_H #include "printf-args.h" /* Flags */ #define FLAG_GROUP 1 /* ' flag */ #define FLAG_LEFT 2 /* - flag */ #define FLAG_SHOWSIGN 4 /* + flag */ #define FLAG_SPACE 8 /* space flag */ #define FLAG_ALT 16 /* # flag */ #define FLAG_ZERO 32 /* arg_index value indicating that no argument is consumed. */ #define ARG_NONE (~(size_t)0) /* A parsed directive. */ typedef struct { const char* dir_start; const char* dir_end; int flags; const char* width_start; const char* width_end; size_t width_arg_index; const char* precision_start; const char* precision_end; size_t precision_arg_index; char conversion; /* d i o u x X f e E g G c s p n U % but not C S */ size_t arg_index; } char_directive; /* A parsed format string. */ typedef struct { size_t count; char_directive *dir; size_t max_width_length; size_t max_precision_length; } char_directives; /* Parses the format string. Fills in the number N of directives, and fills in directives[0], ..., directives[N-1], and sets directives[N].dir_start to the end of the format string. Also fills in the arg_type fields of the arguments and the needed count of arguments. */ #ifdef STATIC STATIC #else extern #endif int printf_parse (const char *format, char_directives *d, arguments *a); #endif /* _PRINTF_PARSE_H */ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-17 14:54 ` Daniel Jacobowitz @ 2006-10-18 11:24 ` Andrew STUBBS 2006-10-18 13:53 ` Daniel Jacobowitz 2006-10-31 11:43 ` Andrew STUBBS 0 siblings, 2 replies; 10+ messages in thread From: Andrew STUBBS @ 2006-10-18 11:24 UTC (permalink / raw) To: gdb Daniel Jacobowitz wrote: > Once we have the structure in place, we could basically replace > printf_fetchargs (which uses va_arg) with something that operated on > our list of values and did appropriate type checking / casts, then > hand it back to the gnulib printf routine. So you're not talking about changing anything outside of printcmd.c, just adding a few files from another project and rewriting the relevant bits of the printf command? OK, that sounds like a plan. Where do we start? Andrew ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-18 11:24 ` Andrew STUBBS @ 2006-10-18 13:53 ` Daniel Jacobowitz 2006-10-31 11:43 ` Andrew STUBBS 1 sibling, 0 replies; 10+ messages in thread From: Daniel Jacobowitz @ 2006-10-18 13:53 UTC (permalink / raw) To: gdb On Wed, Oct 18, 2006 at 12:23:58PM +0100, Andrew STUBBS wrote: > Daniel Jacobowitz wrote: > >Once we have the structure in place, we could basically replace > >printf_fetchargs (which uses va_arg) with something that operated on > >our list of values and did appropriate type checking / casts, then > >hand it back to the gnulib printf routine. > > So you're not talking about changing anything outside of printcmd.c, > just adding a few files from another project and rewriting the relevant > bits of the printf command? Right. Our value infrastructure is more than adequate for what we need. We'll end up with more total code, but less of our own; gnulib will do most of the heavy lifting. > OK, that sounds like a plan. Where do we start? Well, the very first thing is going to be a version of gnulib that lets us reuse its printf this way. I'll contact the gnulib maintainers about that right now, and get back to you. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-18 11:24 ` Andrew STUBBS 2006-10-18 13:53 ` Daniel Jacobowitz @ 2006-10-31 11:43 ` Andrew STUBBS 2006-10-31 13:42 ` Daniel Jacobowitz 1 sibling, 1 reply; 10+ messages in thread From: Andrew STUBBS @ 2006-10-31 11:43 UTC (permalink / raw) To: gdb > Well, the very first thing is going to be a version of gnulib that lets > us reuse its printf this way. I'll contact the gnulib maintainers > about that right now, and get back to you. From what I can see in the bug-gnulib archives, this seems to have hit a problem. What's going on? Andrew ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB printf command 2006-10-31 11:43 ` Andrew STUBBS @ 2006-10-31 13:42 ` Daniel Jacobowitz 0 siblings, 0 replies; 10+ messages in thread From: Daniel Jacobowitz @ 2006-10-31 13:42 UTC (permalink / raw) To: gdb On Tue, Oct 31, 2006 at 11:43:39AM +0000, Andrew STUBBS wrote: > >Well, the very first thing is going to be a version of gnulib that lets > >us reuse its printf this way. I'll contact the gnulib maintainers > >about that right now, and get back to you. > > From what I can see in the bug-gnulib archives, this seems to have hit > a problem. > > What's going on? I didn't get an answer to one of my questions. I meant to come up with a patch to suggest, to restart the discussion, but you know how things are - I haven't had time. I will be back to it eventually; I'm afraid that's all I can promise :-( Maybe this week. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-10-31 13:42 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-10-17 12:03 GDB printf command Andrew STUBBS 2006-10-17 13:24 ` Daniel Jacobowitz 2006-10-17 14:10 ` Andrew STUBBS 2006-10-17 14:25 ` Daniel Jacobowitz 2006-10-17 14:43 ` Andrew STUBBS 2006-10-17 14:54 ` Daniel Jacobowitz 2006-10-18 11:24 ` Andrew STUBBS 2006-10-18 13:53 ` Daniel Jacobowitz 2006-10-31 11:43 ` Andrew STUBBS 2006-10-31 13:42 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox