With this patch an array of integers is printed like this: $8 = {50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62} Without this patch it is printed as if it is a string: $23 = '23456789:;<=>' I like the first option better. ;) patch: --- a/gdb/p-valprint.c +++ b/gdb/p-valprint.c @@ -82,9 +85,8 @@ pascal_val_print (struct type *type, const gdb_byte *valaddr, } /* For an array of chars, print with string syntax. */ if ((eltlen == 1 || eltlen == 2 || eltlen == 4) - && ((TYPE_CODE (elttype) == TYPE_CODE_INT) - || ((current_language->la_language == language_pascal) - && (TYPE_CODE (elttype) == TYPE_CODE_CHAR))) + && ((current_language->la_language == language_pascal) + && (TYPE_CODE (elttype) == TYPE_CODE_CHAR)) && (options->format == 0 || options->format == 's')) { /* If requested, look for the first null char and only print
Hello Joost, Given that your bug is filed under the `archer' version, have you considered submiting your patch to the archer mailing-list? It's a better way to get your patch reviewed. Thanks.
Hello Sergio, Thanks for the suggestion, but I deliberately submitter it here. This patch is part of a larger array patch which I've send to archer, but as it is pascal-specific the archer-people do not know much of this. And this part of the patch is not archer-specific. So I posted it here so that the gnu-gdb-pascal maintainer can have a look at it. Thanks, Joost.
Assignment changed to me as this is pascal specific.
I agree with your bug report but not with the proposed patch, instead I propose this: The main difference is the the use of /s print format modifier will force the printing as a string, regardless of the element type. Please tell me if this patch is OK for you also. Pierre Muller Pascal language maintainer of GDB. Index: p-valprint.c =================================================================== RCS file: /cvs/src/src/gdb/p-valprint.c,v retrieving revision 1.68 diff -u -p -r1.68 p-valprint.c --- p-valprint.c 9 Mar 2010 08:30:54 -0000 1.68 +++ p-valprint.c 13 Apr 2010 09:19:55 -0000 @@ -80,12 +80,13 @@ pascal_val_print (struct type *type, con { print_spaces_filtered (2 + 2 * recurse, stream); } - /* For an array of chars, print with string syntax. */ - if ((eltlen == 1 || eltlen == 2 || eltlen == 4) - && ((TYPE_CODE (elttype) == TYPE_CODE_INT) - || ((current_language->la_language == language_pascal) - && (TYPE_CODE (elttype) == TYPE_CODE_CHAR))) - && (options->format == 0 || options->format == 's')) + /* If 's' format is used, try to print out as string. + If no format is given, print as string if element type + is of TYPE_CODE_CHAR and element size is 1,2 or 4. */ + if (options->format == 's' + || ((eltlen == 1 || eltlen == 2 || eltlen == 4) + && TYPE_CODE (elttype) == TYPE_CODE_CHAR + && options->format == 0)) { /* If requested, look for the first null char and only print elements up to it. */
(In reply to comment #4) > Please tell me if this patch is OK for you also. Even better
Subject: Bug 11492 CVSROOT: /cvs/src Module name: src Changes by: muller@sourceware.org 2010-04-21 09:54:59 Modified files: gdb : ChangeLog p-valprint.c gdb/testsuite : ChangeLog Added files: gdb/testsuite/gdb.pascal: gdb11492.exp gdb11492.pas Log message: gdb ChangeLog PR pascal/11492. * p-valprint.c (pascal_val_print): Fix default printing of integer arrays. gdb/testsuite ChangeLog PR pascal/11492. * gdb.pascal/gdb11492.pas: New file. * gdb.pascal/gdb11492.exp: New file. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.11659&r2=1.11660 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/p-valprint.c.diff?cvsroot=src&r1=1.68&r2=1.69 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2244&r2=1.2245 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.pascal/gdb11492.exp.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.pascal/gdb11492.pas.diff?cvsroot=src&r1=NONE&r2=1.1
The patches above should have fixed the problem reported here. Could you please try cvs GDB out and confirm that it is fixed?
*** Bug 11591 has been marked as a duplicate of this bug. ***
Has this problem been fixed already? Can we close the bug?
Patch in comments should have fixed the issue reported