Re: Designs for better debug info in GCC
Alexandre Oliva writes: > On Dec 21, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > > > Alexandre, I have to say that in my opinion absurd arguments like this > > do not strengthen your position. > > I'm sorry that you feel that way, but I don't understand why you and > so many others apply different compliance standards to debug > information. We know you don't understand, but that isn't likely to change. Would it not surely be better to cease this pointless argument and get on with the job of improving debuginfo? This absolutist position you seem to have adopted isn't helping. If we could talk about "better" and "worse" rather than "correct" and "incorrrect" we'd get much further. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Designs for better debug info in GCC
Andrew Haley wrote: We know you don't understand, but that isn't likely to change. Would it not surely be better to cease this pointless argument and get on with the job of improving debuginfo? This absolutist position you seem to have adopted isn't helping. If we could talk about "better" and "worse" rather than "correct" and "incorrrect" we'd get much further. I very much agree. Everyone is in favor of better debug information if it is not too costly, we won't really see whether it is too costly until we get some real data. But trying to argue for this in terms of standards and conformance is a real red herring, the proper argument for any improvement to debug information is utility.
glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk
Hi all, I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day and I see 3 tests fail : math/test-float math/test-ildoubl math/test-ifloat The erorrs are all similar : Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i Result: is: 0.e+00 0x0.p+0 should be: 1.57079637050628662109e+00 0x1.921fb600p+0 difference: 1.57079637050628662109e+00 0x1.921fb600p+0 ulp : 13176795. max.ulp : 0. All of the imaginary part checks fail, with the help of GFortran maintainers we identified 2 testcases which fail with glibc 2.7 when compiled with gcc 4.3 trunk [0] . This problem also causes 32 unexpected failures on gfortran regression tests. So I wonder if you guys can help me debug this, I checked out libc sources but its mostly assembly stuff for math functions. Maybe Jakub has an idea, not sure. Any help/comment appreciated. [0] http://sourceware.org/bugzilla/show_bug.cgi?id=5490 Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Designs for better debug info in GCC
Chris Lattner <[EMAIL PROTECTED]> writes: > If debug info size and link time is really such a serious problem for > so many users, perhaps people developing the gnu toolchain should > investigate an extension like this. I'm in favor of implementing this. As I'm sure you know, the GNU binutils and gdb already support using a single separate file for debugging information. But these approaches do not solve all problems. The technique works well during development for a program which is normally run on the same system on which it is developed. It doesn't help much when the program must be run on a different system--it's possible to use gdbserver, but awkward. And it doesn't help at all when it is sometimes necessary to debug executables which have been built and distributed widely. Ian
Re: Strange error message from gdb
On Thu, 20 Dec 2007 15:33:14 +0100, Andrew Haley wrote: > Alexandre Oliva writes: > > > > How about this patch, instead? It will restore debuggability to Java > > while at the same time maintaining the progress of using the > > long-supported-by-GDB DW_TAG_class_type in both C++ and Java. > > > > for gcc/java/ChangeLog > > from Alexandre Oliva <[EMAIL PROTECTED]> > > > > * lang.c (java_classify_record): Don't return > > RECORD_IS_INTERFACE for now. > > > > OK, thanks. FYI GDB HEAD supports it now (just the backward compatible way, no new info extracted from it so far). http://sourceware.org/ml/gdb-cvs/2007-12/msg00123.html Regards, Jan
Re: Designs for better debug info in GCC
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I'm in favor of implementing this. Yes it would be great. > As I'm sure you know, the GNU > binutils Actually binutils only barely supports debuginfo. AFAIK objcopy is the tool tool that knows anything about them. > and gdb already support using a single separate file for > debugging information. That does not solve that problem because all that data still has to be copied. In the current setup even two times (.o -> exe -> objcopy to debuginfo and then another strip which is another partial write). I assume that copying phase is the problem people are complaining about and debuginfo makes it even worse now. > well during development for a program which is normally run on the > same system on which it is developed. It doesn't help much when the > program must be run on a different system--it's possible to use > gdbserver, but awkward. And it doesn't help at all when it is > sometimes necessary to debug executables which have been built and > distributed widely. The Linux distributions have debuginfo rpms that work fine for that. But it does not solve the link time IO problem. -Andi
Regarding WITH_CLEANUP_EXPR
Dear All, This is Anju from IU, Bloomington. I am trying to inject some code into the program and encountered a strange error enroute. Essentially, I am trying to create an std::vector and then call "resize()" on it. "T" is program dependent. When "T" is a primitive type, everything seems to work fine. However, when "T" is a record such as an std::string, I get an error during gimplification: internal compiler error: in lower_stmt, at gimple-low.c:282. The gimple ouput reads thus: <<< Unknown tree: with_cleanup_expr __comp_dtor (&D.109215) >>> Any suggestions as to why this happens? I am working on a branch off of 4.3. Thanks, Anju
Re: Designs for better debug info in GCC
On Sat, Dec 22, 2007 at 11:49:23PM +0100, Andi Kleen wrote: > > As I'm sure you know, the GNU > > binutils > > Actually binutils only barely supports debuginfo. AFAIK > objcopy is the tool tool that knows anything about them. I don't know why you say that. ld knows a bit about debugging sections, and how to read .debug_line for errors; objdump knows how to decode debug info, as does readelf; strip knows how to remove it; objcopy how to copy and separate it. > The Linux distributions have debuginfo rpms that work > fine for that. But it does not solve the link time IO problem. FWIW, in the paragraph you were responding to Ian was talking about the Darwin system, not the GNU one. -- Daniel Jacobowitz CodeSourcery
Re: Designs for better debug info in GCC
> I don't know why you say that. ld knows a bit about debugging > sections, and how to read .debug_line for errors; objdump knows how to > decode debug info, as does readelf; strip knows how to remove it; > objcopy how to copy and separate it. Sorry I mean separate debuginfo, as Ian was refering too. I actually had a patch once to hack it into objdump for -S and also into addr2line but it was somewhat ugly and still had some problems and I didn't submit it. -Andi
Re: Designs for better debug info in GCC
On Sun, Dec 23, 2007 at 02:33:44AM +0100, Andi Kleen wrote: > > I don't know why you say that. ld knows a bit about debugging > > sections, and how to read .debug_line for errors; objdump knows how to > > decode debug info, as does readelf; strip knows how to remove it; > > objcopy how to copy and separate it. > > Sorry I mean separate debuginfo, as Ian was refering too. > > I actually had a patch once to hack it into objdump for -S and > also into addr2line but it was somewhat ugly and still > had some problems and I didn't submit it. Oh, I see. Yes, only BFD and GDB know much about it. -- Daniel Jacobowitz CodeSourcery
Re: Designs for better debug info in GCC
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > [...] Because a compiler that generates incorrect instructions is > completely useless for all users. Surely you overstate this: gcc has always included a generous serving of incorrect-code-generation bugs. > A compiler that generates incorrect debug information, or no debug > information at all, or debug information which is randomly correct > and incorrect, is still quite useful for many users. Evidence: gcc > today. Indeed. > [...] Like it or not, the large size of debug information is a > serious issue for many people. It is profoundly ironic that, despite the great bulk of this data, its quality has severe enough blemishes that people can't justify installing/using it. If it were a little larger but significantly more complete/correct, perhaps the cost/benefit judgemment would swing around. Coincidentally, we (several RH engineers) are working on dwarf data compression. - FChE
