|
From: Julian S. <js...@ac...> - 2002-10-21 18:03:40
|
On Monday 21 October 2002 4:35 pm, Josef Weidendorfer wrote: > [This is about a problem in the DWARF2 line info reader (this is CCed to > the valgrind developers list)] You sure? I don't see it in the Cc: field of this msg. Josef, You are much more expert about DWARF2 than I am (you debugged it recently, I have never messed with it and I didn't write it; Daniel Berlin (IIRC) provided it originally). Therefore, you are much better able to make a good decision about this than I am -- so please do so! I would only say that if we have to make a decision between good DWARF2 support for the GNU compilers and good support for the Intel compiler, we should of course choose in favour of the GNU compilers. Ideally we can give good support for both, but maybe that is not possible? Understand that valgrind is now pretty much too large for any one person to fully understand (well, it's too big for me really), so if you become the "center of expertise" for DWARF2 stuff and whatever else, that's fine by me! I just understand the core JIT, the threading library and generally keeping it working. J > > Hi Arnaud, > > I created a similar C file, and put the ".debug_line" section from your > assembler into the assembler of my small C prog to get a runnable program > for valgrind, enabling debug output for the DWARF2 line info reader... > > It seems to me that the Intel Fortran compiler generates bad DWARF2 line > info code: It sets "is_stmt" of the state machine in the the line info > reader to be always false. Thus, there is never a statement boundary > generated and therefore never a instruction range/line number mapping > generated for valgrind. > > Please have a look at the DWARF2 specification, Ch. 6.2 > (x86.ddj.com/ftp/manuals/tools/dwarf.pdf). > Perhaps I understand this wrong, but I don't think so. > > I just had a look at the GDB DWARF2 reader... > They completly ignore "is_stmt" when recording line info ;-) > That's the reason "objdump -S" works on files from the the intel fortran > compiler. > > Nevertheless, I think you should write a bug report to Intel regarding > this. I would be very interested in the response. > > (this is CCed to the valgrind developers list:) > Julian, should we ignore the setting of "is_stmt", too? > > This would mean to always override the "default_is_stmt" with "true" in the > line info debug header: In vg_symtab2.c, search the line > > info.li_default_is_stmt = * ((UChar > *)(external->li_default_is_stmt)); > > and replace it with > > info.li_default_is_stmt = true; > > > Josef > > On Monday 21 October 2002 15:15, you wrote: > > Hi Josef, > > > > I noticed your patch to vg_symtab2.c which is very useful as valgrind was > > fairly > > unusable with recent versions of gcc. Thanks for that ! > > A friend of mine is using the Intel Fortran compiler ifc 6.0 and mailed > > me a while > > ago that valgrind couldn't get the line number in some situations. I > > tried valgrind 1.0.4 > > this morning and it turns out that, while a vast improvement with gcc, > > the line number is > > not read anymore for executable generated by ifc. > > > > To summarize the situation related to line number: > > g77 3.2 and later ifc 6.0 > > valgrind 1.0.3 No Sometines > > valgrind 1.0.4 Yes ! No > > > > I realised that ifc is not very easily available (although it can be use > > freely for > > non commerical purpose > > http://www.intel.com/software/products/compilers/f60l/noncom.htm). > > > > However, you may know why it goes wrong: > > >cat tt1.f > > > > program tt1 > > integer i, j > > if (i .gt. 1) j = 1 ! i not set > > end > > > > >ifc -g -O0 tt1.f > > > > program TT1 > > > > 4 Lines Compiled > > > > >valgrind ./a.out > > > > ==5376== valgrind-1.0.4, a memory error detector for x86 GNU/Linux. > > ==5376== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. > > ==5376== Estimated CPU clock rate is 801 MHz > > ==5376== For more details, rerun with: -v > > ==5376== > > ==5376== Conditional jump or move depends on uninitialised value(s) > > ==5376== at 0x804A0FA: main (in /miami/academic/arnaud/tmp/tmp/a.out) > > ==5376== by 0x402F96F7: __libc_start_main > > (../sysdeps/generic/libc-start.c:129) > > ==5376== by 0x8049FA1: __fxstat64@@GLIBC_2.2 (in > > /miami/academic/arnaud/tmp/tmp/a.out) > > ==5376== > > ==5376== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > > ==5376== malloc/free: in use at exit: 0 bytes in 0 blocks. > > ==5376== malloc/free: 1 allocs, 1 frees, 32 bytes allocated. > > ==5376== For a detailed leak analysis, rerun with: --leak-check=yes > > ==5376== For counts of detected errors, rerun with: -v > > > > >~/valgrind-1.0.3/bin/valgrind ./a.out > > > > ==5402== valgrind-1.0.3, a memory error detector for x86 GNU/Linux. > > ==5402== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. > > ==5402== Estimated CPU clock rate is 802 MHz > > ==5402== For more details, rerun with: -v > > ==5402== > > ==5402== Conditional jump or move depends on uninitialised value(s) > > ==5402== at 0x804A0FA: main (tt1.f:3) > > ==5402== by 0x402FC6F7: __libc_start_main > > (../sysdeps/generic/libc-start.c:129) > > ==5402== by 0x8049FA1: __fxstat64@@GLIBC_2.2 (in > > /miami/academic/arnaud/tmp/tmp/a.out) > > ==5402== > > ==5402== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > > ==5402== malloc/free: in use at exit: 0 bytes in 0 blocks. > > ==5402== malloc/free: 1 allocs, 1 frees, 32 bytes allocated. > > ==5402== For a detailed leak analysis, rerun with: --leak-check=yes > > ==5402== For counts of detected errors, rerun with: -v > > > > I attach the assembler generated by "ifc -g -O0 -S". > > > > Best regards, > > Arnaud |