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] |
Hello, We are currently working on transitioning from GCC 3.4 to GCC 4.1, and we found an issue with character types. For a program like this: procedure P is A : Character := 'A'; begin A := 'B'; -- START end; The debugging info produced for the character is: .uleb128 0x2 # (DIE (0x62) DW_TAG_base_type) .long .LASF0 # DW_AT_name: "__unknown__" .byte 0x1 # DW_AT_byte_size .byte 0x7 # DW_AT_encoding The DW_AT_name used to be "character", and ada-lang.c was using the name to identify character types. After a small discussion with the company engineer for GCC debug info production, he agreed that the name is wrong, and should be changed back. However, he also suggested that the debugger should avoid relying on the type name, and use the encoding if available. In the case above, 0x7 is DW_ATE_unsigned but it should be DW_ATE_unsigned_char (0x8), so he will change that. I looked at the GDB side and came up with a few changes here and there that implement his suggestion. I discovered that we rely quite a bit on the type name to identify characters, and I guessed that it was historical because of debugging format shortcomings (with stabs for instance). I think the attached patch improves the situation in terms of making things cleaner in the case of dwarf2, without impacting targets that still use older debugging format like stabs. 2006-05-05 Joel Brobecker <brobecker@adacore.com> * dwarf2read.c (read_base_type): Set code to TYPE_CODE_CHAR for char and unsigned char types. * ada-lang.c (ada_is_character_type): Always return true if the type code is TYPE_CODE_CHAR. * c-valprint.c (c_val_print): Print arrays whose element type code is TYPE_CODE_CHAR as strings. Tested on x86-linux, with GCC 3.4 (dwarf2, stabs+), GCC 4.1 (dwarf2). No regression. What do you guys think? Wouldn't that be a step forward? Thanks, -- Joel
Attachment:
char.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |