On Fri, Mar 21, 2014 at 12:47:10PM +0100, Eric Botcazou wrote: > > So the patch below makes it so that if HOST_WIDE_INT is wide enough then, > > depending on whether the range type is signed or not, add_AT_unsigned or > > add_AT_int is used. This is more efficient for small ranges. And makes it > > so that the value can be deduced from the DW_FORM by the consumer (which > > can assume again that DW_FORM_data[1248] are simply zero-extended and > > that negative constant values are represented by DW_FORM_sdata). > > FWIW this looks an improvement to me.
Thanks. I'll propose it as a real patch with ChangeLog. > > I tested this on x86_64 with --enable-languages=c,ada,c++,fortran,java,objc > > without regressions. I also made sure that the example ada program range > > is recognized correctly by gdb with this patch. > > > > A couple of questions: > > > > - Are there more ada DWARF tests? Something like guality used for c/fortran? > > In the compiler proper no, but there is (of course) the GDB testsuite. Of course, thanks. I ran gdb make check against a gcc with and without this patch without any test result changes. > > - What values of HOST_BITS_PER_WIDE_INT are actually supported in GCC? The > > dwarf2out.c code tries to handle 8, 16, 32 and 64 bits for > > dw_val_class_const_double. > > 32 and 64 Phew. OK, that makes things simpler. I was afraid we had to handle much more combinations. > > - Which setups use 32bit (or lower?) HOST_BITS_PER_WIDE_INT? > > i686 seems to require 64BIT HOST_WIDE_INTs too these days. > > Right, pure 32-bit hosted compilers are an endangered species and GNAT is > probably not fully functional for these architectures. > > How did you run into the problem? Can't you conduct some minimal testing on > 64-bit platforms by using 128-bit integers (not in Ada unfortunately)? I admit that the problem was somewhat theoretical. I tried to convince Joel that he didn't have to lookup the type each time in a GDB patch. But he pointed out GCC sometimes outputs constant values as DW_FORM_data that had to be sign-extended to be interpreted correctly. In other cases GCC expects consumers to just zero-extend the value when DW_FORM_data is used. I also work on another DWARF consumer (elfutils/libdw) that does have that expectation. So I wanted to make GCC consistent. It now is for 64 HOST_BITS_PER_WIDE_INT arches, but not yet for Using 128-bit integers on 64-bit platforms doesn't expose the same issue. On 64 HOST_BITS_PER_WIDE_INT arches a dw_val_class_const_double is encoded as a DW_FORM_BLOCK (which would actually be an invalid encoding for a DW_AT_higher or DW_AT_lower bound, but I don't know any language/construct that would generate such 128-bit bounds ranges). Cheers, Mark > > -- > Eric Botcazou
