* [RFC] DW_AT_type missing from DW_TAG_subrange_type
@ 2007-04-03 13:24 Denis PILAT
2007-04-10 15:31 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: Denis PILAT @ 2007-04-03 13:24 UTC (permalink / raw)
To: gdb-patches
For the global variable declared like that
int array[] = {1, 2, 3, 4};
the dwarf information generated by our specific compiler is missing
DW_AT_type missing from DW_TAG_subrange_type.
Usually in dwarf2 information (ie like the bellow example for gcc4 under
linux), the DW_AT_type exists for subranges :
< 175 (0xaf) > DW_TAG_array_type
| DW_AT_sibling : < 191 (0xbf) >
| DW_AT_type : < 168 (0xa8) >
`--------------------------
< 184 (0xb8) > DW_TAG_subrange_type
* | DW_AT_type : < 191 (0xbf) >* <<<<<-------- missing from
my elf file
| DW_AT_upper_bound : DW_AT_upper_bound(DW_FORM_data1) : 3
`--------------------------
Therefore we go thru the code "base_type = alloc_type (NULL)" (in
read_subrange_type of dwarf2read.c) and gdb prints the following if "set
print array-indexes on": (all indexes are set to 0):
(gdb) p array
$1 = {[0] = 1, [0] = 2, [0] = 3, [0] = 4}
Could we have a *builtin_type_int* as the default type instead of
alloc_type (NULL) ?
*Attach is a patch in that sense.*
I'm also wondering about the code:
base_type = die_type (die, cu);
if (base_type == NULL)
{
complaint (&symfile_complaints,
_("DW_AT_type missing from DW_TAG_subrange_type"));
return;
}
It seems we'll never have (base_type == NULL). Am I right ?
May be it's time to remove that as well. The complaints seems to be in a
better place in my patch.
For information, this testcase is present in gdb.base/arrayidx.exp where
we have "set print array-indexes on"
No regression for this patch for i386-linux target
--
Denis
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.216
diff -u -p -r1.216 dwarf2read.c
--- dwarf2read.c 30 Mar 2007 17:21:47 -0000 1.216
+++ dwarf2read.c 3 Apr 2007 09:41:07 -0000
@@ -4921,7 +4921,11 @@ read_subrange_type (struct die_info *die
}
if (TYPE_CODE (base_type) == TYPE_CODE_VOID)
- base_type = alloc_type (NULL);
+ {
+ complaint (&symfile_complaints,
+ _("DW_AT_type missing from DW_TAG_subrange_type"));
+ base_type = builtin_type_int;
+ }
if (cu->language == language_fortran)
{
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type 2007-04-03 13:24 [RFC] DW_AT_type missing from DW_TAG_subrange_type Denis PILAT @ 2007-04-10 15:31 ` Daniel Jacobowitz 2007-04-18 12:55 ` Denis PILAT 0 siblings, 1 reply; 7+ messages in thread From: Daniel Jacobowitz @ 2007-04-10 15:31 UTC (permalink / raw) To: Denis PILAT; +Cc: gdb-patches On Tue, Apr 03, 2007 at 03:23:56PM +0200, Denis PILAT wrote: > For the global variable declared like that > int array[] = {1, 2, 3, 4}; > the dwarf information generated by our specific compiler is missing DW_AT_type > missing from DW_TAG_subrange_type. > > Usually in dwarf2 information (ie like the bellow example for gcc4 under > linux), the DW_AT_type exists for subranges : > > < 175 (0xaf) > DW_TAG_array_type > | DW_AT_sibling : < 191 (0xbf) > > | DW_AT_type : < 168 (0xa8) > > `-------------------------- > < 184 (0xb8) > DW_TAG_subrange_type > * | DW_AT_type : < 191 (0xbf) >* <<<<<-------- missing from my elf > file > | DW_AT_upper_bound : DW_AT_upper_bound(DW_FORM_data1) : 3 > `-------------------------- Conveniently, the DWARF 3 standard specifies what this means (DWARF 2 may also; I didn't check). From the standard: > If the subrange entry has no type attribute describing the basis type, > the basis type is assumed to be the same as the object described by > the lower bound attribute (if it references an object). If there is no > lower bound attribute, or that attribute does not reference an object, > the basis type is the type of the upper bound or count attribute (if > either of them references an object). If there is no upper bound or > count attribute, or neither references an object, the type is assumed > to be the same type, in the source language of the compilation unit > containing the subrange entry, as a signed integer with the same size > as an address on the target machine. Since we do not handle objects for bounds yet, we're only interested in that last case. So, we should use an integer type the size of an address. Try using dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT / 8, cu)? That function is, in fact, very buggy. We should fix it. It has hardcoded sizes of 1, 2, 4 for char, short, int and doesn't support long long at all. > I'm also wondering about the code: > base_type = die_type (die, cu); > if (base_type == NULL) > { > complaint (&symfile_complaints, > _("DW_AT_type missing from DW_TAG_subrange_type")); > return; > } > It seems we'll never have (base_type == NULL). Am I right ? > May be it's time to remove that as well. The complaints seems to be in a better > place in my patch. You're right; please do. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type 2007-04-10 15:31 ` Daniel Jacobowitz @ 2007-04-18 12:55 ` Denis PILAT 2007-04-18 13:06 ` Daniel Jacobowitz 0 siblings, 1 reply; 7+ messages in thread From: Denis PILAT @ 2007-04-18 12:55 UTC (permalink / raw) To: gdb-patches Daniel Jacobowitz wrote: > On Tue, Apr 03, 2007 at 03:23:56PM +0200, Denis PILAT wrote: > >> For the global variable declared like that >> int array[] = {1, 2, 3, 4}; >> the dwarf information generated by our specific compiler is missing DW_AT_type >> missing from DW_TAG_subrange_type. >> >> Usually in dwarf2 information (ie like the bellow example for gcc4 under >> linux), the DW_AT_type exists for subranges : >> >> < 175 (0xaf) > DW_TAG_array_type >> | DW_AT_sibling : < 191 (0xbf) > >> | DW_AT_type : < 168 (0xa8) > >> `-------------------------- >> < 184 (0xb8) > DW_TAG_subrange_type >> * | DW_AT_type : < 191 (0xbf) >* <<<<<-------- missing from my elf >> file >> | DW_AT_upper_bound : DW_AT_upper_bound(DW_FORM_data1) : 3 >> `-------------------------- >> > > Conveniently, the DWARF 3 standard specifies what this means (DWARF 2 > may also; I didn't check). From the standard: > > >> If the subrange entry has no type attribute describing the basis type, >> the basis type is assumed to be the same as the object described by >> the lower bound attribute (if it references an object). If there is no >> lower bound attribute, or that attribute does not reference an object, >> the basis type is the type of the upper bound or count attribute (if >> either of them references an object). If there is no upper bound or >> count attribute, or neither references an object, the type is assumed >> to be the same type, in the source language of the compilation unit >> containing the subrange entry, as a signed integer with the same size >> as an address on the target machine. >> > > Since we do not handle objects for bounds yet, we're only interested > in that last case. So, we should use an integer type the size of an > address. Try using dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT / > 8, cu)? > Tried, it works as well. > That function is, in fact, very buggy. We should fix it. It has > hardcoded sizes of 1, 2, 4 for char, short, int and doesn't support > long long at all. > And you want me to use it, thanks for the gift !-) >> I'm also wondering about the code: >> base_type = die_type (die, cu); >> if (base_type == NULL) >> { >> complaint (&symfile_complaints, >> _("DW_AT_type missing from DW_TAG_subrange_type")); >> return; >> } >> It seems we'll never have (base_type == NULL). Am I right ? >> May be it's time to remove that as well. The complaints seems to be in a better >> place in my patch. >> > > You're right; please do. > Done Here is the proposed patch. No regression in the testsuite for native linux target. Ok for commit ? -- Denis 2007-04-18 Denis Pilat <denis.pilat@st.com> * dwarf2read.c (read_subrange_type): Use of DW_ATE_signed default type when missing from DW_TAG_subrange_type. Remove the handling of null return from die_type(). Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.217 diff -u -p -r1.217 dwarf2read.c --- dwarf2read.c 11 Apr 2007 16:04:22 -0000 1.217 +++ dwarf2read.c 18 Apr 2007 12:42:20 -0000 @@ -4914,16 +4914,13 @@ read_subrange_type (struct die_info *die return; base_type = die_type (die, cu); - if (base_type == NULL) + if (TYPE_CODE (base_type) == TYPE_CODE_VOID) { complaint (&symfile_complaints, _("DW_AT_type missing from DW_TAG_subrange_type")); - return; + base_type = dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT /8, cu); } - if (TYPE_CODE (base_type) == TYPE_CODE_VOID) - base_type = alloc_type (NULL); - if (cu->language == language_fortran) { /* FORTRAN implies a lower bound of 1, if not given. */ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type 2007-04-18 12:55 ` Denis PILAT @ 2007-04-18 13:06 ` Daniel Jacobowitz 2007-04-18 13:17 ` Denis PILAT 0 siblings, 1 reply; 7+ messages in thread From: Daniel Jacobowitz @ 2007-04-18 13:06 UTC (permalink / raw) To: Denis PILAT; +Cc: gdb-patches On Wed, Apr 18, 2007 at 02:51:31PM +0200, Denis PILAT wrote: > 2007-04-18 Denis Pilat <denis.pilat@st.com> > > * dwarf2read.c (read_subrange_type): Use of DW_ATE_signed default type > when missing from DW_TAG_subrange_type. Remove the handling of null > return from die_type(). This is OK with two small changes. First, the changelog entry should be: * dwarf2read.c (read_subrange_type): Use DW_ATE_signed default type when missing from DW_TAG_subrange_type. Remove the handling of null return from die_type. (Grammar fix, two spaces between sentences, no parentheses after the name of a function - that's a recent change in the GNU standards, I think) > + base_type = dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT /8, cu); And a space on each side of the "/". Thanks! -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type 2007-04-18 13:06 ` Daniel Jacobowitz @ 2007-04-18 13:17 ` Denis PILAT 2007-04-18 13:30 ` Daniel Jacobowitz 0 siblings, 1 reply; 7+ messages in thread From: Denis PILAT @ 2007-04-18 13:17 UTC (permalink / raw) To: Daniel Jacobowitz, gdb-patches Daniel Jacobowitz wrote: > On Wed, Apr 18, 2007 at 02:51:31PM +0200, Denis PILAT wrote: > >> 2007-04-18 Denis Pilat <denis.pilat@st.com> >> >> * dwarf2read.c (read_subrange_type): Use of DW_ATE_signed default type >> when missing from DW_TAG_subrange_type. Remove the handling of null >> return from die_type(). >> > > This is OK with two small changes. First, the changelog entry should be: > > * dwarf2read.c (read_subrange_type): Use DW_ATE_signed default type > when missing from DW_TAG_subrange_type. Remove the handling of null > return from die_type. > > (Grammar fix, two spaces between sentences, no parentheses after the > name of a function - that's a recent change in the GNU standards, I > think) > > >> + base_type = dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT /8, cu); >> > > And a space on each side of the "/". > > Thanks! > > Ok, that means I did a mistake in my previous ChangeLog entry about target_terminal_ours ? Can I change it as well in the same commit, removing "()" ? Denis ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type 2007-04-18 13:17 ` Denis PILAT @ 2007-04-18 13:30 ` Daniel Jacobowitz 2007-04-18 14:21 ` Denis PILAT 0 siblings, 1 reply; 7+ messages in thread From: Daniel Jacobowitz @ 2007-04-18 13:30 UTC (permalink / raw) To: Denis PILAT; +Cc: gdb-patches On Wed, Apr 18, 2007 at 03:06:38PM +0200, Denis PILAT wrote: > Ok, that means I did a mistake in my previous ChangeLog entry about > target_terminal_ours ? > Can I change it as well in the same commit, removing "()" ? Yes please. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] DW_AT_type missing from DW_TAG_subrange_type 2007-04-18 13:30 ` Daniel Jacobowitz @ 2007-04-18 14:21 ` Denis PILAT 0 siblings, 0 replies; 7+ messages in thread From: Denis PILAT @ 2007-04-18 14:21 UTC (permalink / raw) To: Denis PILAT, gdb-patches Daniel Jacobowitz wrote: > On Wed, Apr 18, 2007 at 03:06:38PM +0200, Denis PILAT wrote: > >> Ok, that means I did a mistake in my previous ChangeLog entry about >> target_terminal_ours ? >> Can I change it as well in the same commit, removing "()" ? >> > > Yes please. > > Just committed. -- Denis 2007-04-18 Denis Pilat <denis.pilat@st.com> * dwarf2read.c (read_subrange_type): Use DW_ATE_signed default type when missing from DW_TAG_subrange_type. Remove the handling of null return from die_type. Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.217 retrieving revision 1.218 diff -u -p -r1.217 -r1.218 --- dwarf2read.c 11 Apr 2007 16:04:22 -0000 1.217 +++ dwarf2read.c 18 Apr 2007 13:25:04 -0000 1.218 @@ -4914,16 +4914,13 @@ read_subrange_type (struct die_info *die return; base_type = die_type (die, cu); - if (base_type == NULL) + if (TYPE_CODE (base_type) == TYPE_CODE_VOID) { complaint (&symfile_complaints, _("DW_AT_type missing from DW_TAG_subrange_type")); - return; + base_type = dwarf_base_type (DW_ATE_signed, TARGET_ADDR_BIT / 8, cu); } - if (TYPE_CODE (base_type) == TYPE_CODE_VOID) - base_type = alloc_type (NULL); - if (cu->language == language_fortran) { /* FORTRAN implies a lower bound of 1, if not given. */ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-04-18 13:30 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-04-03 13:24 [RFC] DW_AT_type missing from DW_TAG_subrange_type Denis PILAT 2007-04-10 15:31 ` Daniel Jacobowitz 2007-04-18 12:55 ` Denis PILAT 2007-04-18 13:06 ` Daniel Jacobowitz 2007-04-18 13:17 ` Denis PILAT 2007-04-18 13:30 ` Daniel Jacobowitz 2007-04-18 14:21 ` Denis PILAT
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox