[Bug c/45695] New: -O1 wrong-code by cmove
FSF GDB HEAD by FSF GCC 4.5.HEAD errors on `print 0|0' with -O1 and higher.
source below compiles to:
00400455 f:
400455: 53 push %rbx
400456: 39 fa cmp%edi,%edx
400458: 0f 44 decmove %esi,%ebx
but $ebx is left uninitialized for not-equal comparison.
Compilation flags: -O1
it passes = exit code 0 = with -O0
it fails = exit code 1 = with -O1
PASS: gcc (GCC) 4.4.5 20100916 (prerelease)
FAIL: gcc (GCC) 4.5.2 20100916 (prerelease)
PASS: gcc (GCC) 4.6.0 20100916 (experimental)
FAIL: gcc-4.5.1-3.fc14.x86_64
not re-verified but PASS: gcc-4.5.1-1.fc14.x86_64
__attribute__((noinline, noclone)) void
g (int x)
{
asm volatile ();
}
__attribute__((noinline, noclone)) int
f (int a, int b, int d)
{
int r = -1;
b += d;
if (d == a)
r = b - d;
g (b);
return r;
}
int
main (void)
{
asm volatile (mov $42, %%rbx : : : rbx);
return f (0, 1, 4) == 42 ? 1 : 0;
}
--
Summary: -O1 wrong-code by cmove
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45695
[Bug debug/45103] New: DW_OP_reg* has too large valid range for noreturn funcs
Use -g -O2.
DW_OP_reg5 is there valid for each PC, despite there si a `call' and reg5 is
caller-saved register. Its value therefore gets corrupted in the callee.
FAIL all these:
gcc (GCC) 4.6.0 20100724 (experimental)
gcc (GCC) 4.5.1 20100728 (prerelease)
gcc (GCC) 4.4.5 20100724 (prerelease)
gcc-4.4.4-10.fc13.x86_64
GNU gdb (GDB) 7.2.50.20100724-cvs
#0 breakat (q=0) at 1.c:7
#1 0x0040053b in f (a1=value optimized out, a2=2, a3=3, a4=4, a5=5,
a6=6, a7=7) at 2.c:6
#2 0x004004fc in g (x=0) at 1.c:14
^^^ x=10 here, it should be value optimized out
#3 0x0040051e in main () at 2.c:14
== 1.c ==
#include stdlib.h
extern __attribute__((noreturn)) void f (long a1, long a2, long a3, long a4,
long a5, long a6, long a7);
__attribute__((noreturn)) void
breakat (long q)
{
exit (0);
}
__attribute__((noinline)) void
g (long x)
{
f (x, 2, 3, 4, 5, 6, 7);
}
== 2.c ==
extern __attribute__((noreturn)) void breakat (long q);
__attribute__((noreturn)) void
f (long a1, long a2, long a3, long a4, long a5, long a6, long a7)
{
breakat (0);
}
extern __attribute__((noinline)) void g (long x);
int
main (void)
{
g (10);
return 0;
}
--
Summary: DW_OP_reg* has too large valid range for noreturn funcs
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45103
[Bug debug/45103] DW_OP_reg* has too large valid range for noreturn funcs
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-07-28 09:54 --- Created an attachment (id=21331) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21331action=view) .s files for x86_64-unknown-linux-gnu. GDB bug (probably invalid): http://sourceware.org/bugzilla/show_bug.cgi?id=11838 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45103
[Bug middle-end/44690] -fzero-initialized-in-bss does not work
--- Comment #3 from jan dot kratochvil at redhat dot com 2010-07-23 11:11
---
(In reply to comment #1)
const int i; -fno-zero-initialized-in-bss - .bss= FAIL
You need -fno-common also to get it out of the BSS.
-fno-common now at least correctly reports:
echo 'const int i;'|gcc -fno-common -c -o k.o -x c -;echo 'const int
i;main(){}'|gcc -fno-common -c -o l.o -x c -;gcc -fno-common -o k k.o l.o
l.o:(.bss+0x0): multiple definition of `i'
k.o:(.bss+0x0): first defined here
So it is no longer SHN_COMMON, thanks.
But reopening the Bug as it is still in .bss, not in .rodata.
echo 'const int i;int main(){return *(int *)i = 0;}'|gcc -fno-common -Wall -o
1 -x c -;./1;echo $?
0
[25] .bss NOBITS 00600818 0814
0018 WA 0 0 8
Num:Value Size TypeBind Vis Ndx Name
55: 00600828 4 OBJECT GLOBAL DEFAULT 25 i
It should SEGV but it does not.
-f{,no-}zero-initialized-in-bss has no effect on it.
--
jan dot kratochvil at redhat dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44690
[Bug middle-end/44690] New: -fzero-initialized-in-bss does not work
const int i; -fno-zero-initialized-in-bss - .bss= FAIL const int i;-fzero-initialized-in-bss - .bss const int i = 0; -fno-zero-initialized-in-bss - .rodata const int i = 0;-fzero-initialized-in-bss - .rodata = FAIL const int i = 1; -fno-zero-initialized-in-bss - .rodata const int i = 1;-fzero-initialized-in-bss - .rodata gcc (GCC) 4.6.0 20100627 (experimental) (gcc-4.4+ behaves the same) -fzero-initialized-in-bss is the default now. (a) Creating .robss would solve it all but OK, there isn't any. (b) At least -O0 -g should default to -fno-zero-initialized-in-bss as it better catches bugs of modified const zeroed variables. -- Summary: -fzero-initialized-in-bss does not work Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44690
[Bug debug/44664] New: CU DW_AT_low_pc, DW_AT_entry_pc are 0x0
Unaware of any current (GDB) problems from it.
echo 'class C { public: C () {} }; int main() { C c; }' | g++ -Wall -g -x c++ -
FAIL g++ (GCC) 4.4.5 20100625 (prerelease)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
FAIL g++ (GCC) 4.6.0 20100625 (experimental) [under the test below]
Compilation Unit @ offset 0x0:
Version: 2
0b: Abbrev Number: 1 (DW_TAG_compile_unit)
c DW_AT_producer: (indirect string, offset: 0x16): GNU C++ 4.6.0
20100625 (experimental)
10 DW_AT_language: 4(C++)
15 DW_AT_low_pc : 0x0
DW_AT_low_pc DW_FORM_addr
1d DW_AT_entry_pc: 0x0
DW_AT_entry_pc DW_FORM_addr
25 DW_AT_ranges : 0x0
DW_AT_ranges DW_FORM_data4
29 DW_AT_stmt_list : 0x0
Contents of the .debug_ranges section:
Offset BeginEnd
004004b4 004004cf
004004d0 004004da
End of list
4004ce: c3 retq
4004cf: 90 nop
004004d0 _ZN1CC1Ev:
4004d0: 55 push %rbp
(a) DW_AT_low_pc and DW_AT_entry_pc are set to 0, this is incorrect.
- this BZ
DWARF4 does not define DW_TAG_compile_unit-DW_AT_entry_pc
DWARF4 2.17 does not IMO define DW_AT_low_pc when DW_AT_ranges is present.
minor ones:
(b) DW_AT_ranges (which is DWARF3+) is used with DWARF version 2. Consumer
capable of only DWARF2 will most probably fail on such program.
(c) inter-function padding is excluded from DW_AT_ranges, does not it only
needlessly increase the debug info size?
(d) In some cases there the .debug_info ranges are not merged (suboptimal
size).
0040063c 0040066a
0040066a 00400690
--
Summary: CU DW_AT_low_pc, DW_AT_entry_pc are 0x0
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44664
[Bug debug/44668] New: class-DW_TAG_typedef is missing DW_AT_accessibility
echo 'class C { protected: typedef int t; t v; } c;' | g++ -Wall -c -g -x c++ -
233: Abbrev Number: 3 (DW_TAG_typedef)
34 DW_AT_name: t
38 DW_AT_type: 0x4a
23c: Abbrev Number: 4 (DW_TAG_member)
3d DW_AT_name: v
41 DW_AT_type: 0x33
45 DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst:
0)
48 DW_AT_accessibility: 2 (protected)
DIE 0x33 should have DW_AT_accessibility.
FAIL g++ (GCC) 4.6.0 20100625 (experimental)
FAIL g++ (GCC) 4.5.1 20100625 (prerelease)
SKIP g++ (GCC) 4.4.5 20100625 (prerelease) - C::t is missing there.
FAIL gcc-c++-4.4.4-8.fc14.x86_64
G++ properly respects the access control:
.C:3: error: âtypedef int C::tâ is protected
.C:11: error: within this context
But GDB cannot display the access control during `ptype C'.
GDB does not and probably should not respect the access control, though.
--
Summary: class-DW_TAG_typedef is missing DW_AT_accessibility
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44668
[Bug debug/44668] class-DW_TAG_typedef is missing DW_AT_accessibility
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-06-25 16:31 --- Dependent GDB Bug: http://sourceware.org/bugzilla/show_bug.cgi?id=11757 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44668
[Bug other/43480] build: random timestamps have multilib conflicts
--- Comment #2 from jan dot kratochvil at redhat dot com 2010-06-21 11:22 --- Checked-in. Forgot to place the PR # there. r161066 | jkratoch | 2010-06-21 13:16:18 +0200 (Mon, 21 Jun 2010) | 7 lines gcc/ * Makefile.in (POD2MAN): Provide --date from $(DATESTAMP). libjava/classpath/ * doc/Makefile.am (POD2MAN): Provide --date from ChangeLog. * doc/Makefile.in: Regenerate. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
[Bug other/43480] build: random timestamps have multilib conflicts
--- Comment #3 from jan dot kratochvil at redhat dot com 2010-06-21 11:29 --- The fastjar part filed as: https://sourceforge.net/tracker/?func=detailaid=3019015group_id=426atid=100426 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
[Bug other/43480] build: random timestamps have multilib conflicts
--- Comment #4 from jan dot kratochvil at redhat dot com 2010-06-21 11:46 --- http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01999.html Wrongly patched libjava/classpath/ChangeLog , therefore fixed it up: r161069 | jkratoch | 2010-06-21 13:40:02 +0200 (Mon, 21 Jun 2010) | 3 lines Move the entry from libjava/classpath/ ChangeLog to ChangeLog.gcj as it is a local change. Reported by Jakub Jelinek, approved by Mark Wielaard. Index: libjava/classpath/ChangeLog Index: libjava/classpath/ChangeLog.gcj -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use
--- Comment #23 from jan dot kratochvil at redhat dot com 2010-06-07 20:03
---
(In reply to comment #9)
In debug info we could use DW_OP_call{2,4} to refer to those
DIEs' DW_AT_location, but AFAIK gdb doesn't handle those 2 yet.
FYI FSF GDB HEAD supports them now:
http://sourceware.org/bugzilla/show_bug.cgi?id=10640
DW_OP_call_ref is still not supported, though:
http://sourceware.org/bugzilla/show_bug.cgi?id=11674
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343
[Bug debug/44367] New: -O0 -g wrong DW_AT_location on c++ class retval
struct a
{
int i;
int j;
};
static void g (int j)
{
}
static struct a f()
{
struct a a;
a.i = 42;
g (a.i); /* line 13 */
return a;
}
int
main ()
{
f();
return 0;
}
--
28a: Abbrev Number: 8 (DW_TAG_variable)
8b DW_AT_name: a
93 DW_AT_location: 2 byte block: 73 0 (DW_OP_breg3: 0)
296: Abbrev Number: 9 (DW_TAG_lexical_block)
97 DW_AT_low_pc : 0x80483d3
9b DW_AT_high_pc : 0x80483e3
39f: Abbrev Number: 8 (DW_TAG_variable)
a0 DW_AT_name: a
a8 DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20)
- but `a' is never located in the frame.
--
g++ -m32 -o a a.C -Wall -g
gdb -nx -ex 'b 13' -ex r -ex 'p/x $pc' -ex 'p a.i' ./a
Actual:
$2 = 5823984
Expected:
$2 = 42
--
FAIL:
g++ (GCC) 4.6.0 20100601 (experimental)
g++ (GCC) 4.5.1 20100601 (prerelease)
g++ (GCC) 4.4.5 20100601 (prerelease)
It affects also x86_64 when it cannot return the whole class in registers.
Failed to reproduce it with plain C.
--
Summary: -O0 -g wrong DW_AT_location on c++ class retval
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: i386-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44367
[Bug debug/44113] bad debugging information for unrolled loops
--- Comment #10 from jan dot kratochvil at redhat dot com 2010-05-24 19:49 --- GDB counterpart (no patch now): http://sourceware.org/bugzilla/show_bug.cgi?id=11631 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
[Bug debug/42801] C VLAs should use DW_AT_allocated
--- Comment #4 from jan dot kratochvil at redhat dot com 2010-05-24 19:53 --- Archer counterpart (no patch now): http://sourceware.org/bugzilla/show_bug.cgi?id=11632 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42801
[Bug debug/44205] Wrong .debug_line for -O0 -g
--- Comment #3 from jan dot kratochvil at redhat dot com 2010-05-20 16:03 --- No regressions for FSF GDB HEAD x86_64-linux-gnu with FSF GCC HEAD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44205
[Bug debug/44205] New: Wrong .debug_line for -O0 -g
extern int i;
void
f (void)
{
if (i)
{
if (i)
i = 0;
else
i = 1;
}
else
i = 2;
}
gcc -c -g
objdump -dS
i = 0;
18: c7 05 00 00 00 00 00movl $0x0,0x0(%rip)# 22 f+0x22
1f: 00 00 00
else
i = 1;
22: eb 16 jmp3a f+0x3a
24: c7 05 00 00 00 00 01movl $0x1,0x0(%rip)# 2e f+0x2e
2b: 00 00 00
2e: eb 0a jmp3a f+0x3a
jmp at offset 22 should belong to the i = 0; line.
Problem reproduced on:
gcc (GCC) 4.4.5 20100519 (prerelease)
gcc (GCC) 4.5.1 20100519 (prerelease)
gcc (GCC) 4.6.0 20100519 (experimental)
gcc-4.4.3-4.fc12.x86_64
Correct output on:
gcc-4.1.2-48.el5.x86_64
This will cause GDB to skip the line on `step' (which is a workaround in GDB
for missing is_stmt info).
Can GCC use its own new gdb guality framework to test it on its own?
There was before: PR debug/29609, PR debug/36690, PR debug/37616
--
Summary: Wrong .debug_line for -O0 -g
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44205
[Bug debug/43950] New: fortran: Use DW_AT_identifier_case
Fortran currently lowercases all the identifiers for DWARF. In such case it should set DW_AT_identifier_case = DW_ID_down_case. GDB currently assumes DW_ID_down_case for DW_LANG_Fortran* which is incorrect, consumer should always default to DW_ID_case_sensitive according to DWARF4. Fortran should preserve source file case and set DW_AT_identifier_case = DW_ID_case_insensitive GDB currently does not support it though, it is filed as: http://sourceware.org/bugzilla/show_bug.cgi?id=11560 -- Summary: fortran: Use DW_AT_identifier_case Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43950
[Bug testsuite/43482] Fix *.log tests merged output containing ===
--- Comment #4 from jan dot kratochvil at redhat dot com 2010-04-22 18:09 --- Comment 3 has a typo, it should have been for: PR tree-optimization/43842 -- jan dot kratochvil at redhat dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
[Bug testsuite/43482] Fix *.log tests merged output containing ===
--- Comment #5 from jan dot kratochvil at redhat dot com 2010-04-22 18:10 --- But this Bug has been already fixed in Comment 2. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #7 from jan dot kratochvil at redhat dot com 2010-04-20 09:14 --- Created an attachment (id=20436) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20436action=view) Preliminary GDB patch. Tobias, could you add DW_AT_MIPS_linkage name? You say in Comment 3 the debugger cannot guess the linkage name from DW_AT_namespace hierarchy as it is not standardized across Fortran compilers. If DW_AT_external is true the GDB patch ignores DW_AT_location and relies on the ELF symbols which would work. It should IMHO follow Roland's Re: Cross-CU C++ DIE references vs. mangling http://sourceware.org/ml/archer/2010-q1/msg00092.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #9 from jan dot kratochvil at redhat dot com 2010-04-20 12:24
---
(In reply to comment #8)
BTW, should DW_AT_{,MIPS_}linkage_name be also present on DW_TAG_common_block?
[...]
for DW_AT_linkage_name to be allowed on DW_TAG_common_block.
For DW_TAG_common_block:
+ /* SYMBOL_VALUE_ADDRESS never gets used as all its fields are static.
*/
There is only important the user-visible DW_AT_name of DW_TAG_common_block.
Then there are child DIEs DW_TAG_variable. Good point there should be
DW_AT_*linkage_name present the same way as normal variables should have it.
http://cvs.fedoraproject.org/viewvc/rpms/gdb/F-13/gdb-fortran-common.patch?content-type=text%2Fplainview=co
24a: Abbrev Number: 3 (DW_TAG_common_block)
4b DW_AT_name: (indirect string, offset: 0xd3): fo_o
51 DW_AT_location: 9 byte block: 3 50 c 60 0 0 0 0 0
(DW_OP_addr: 600c50)
35f: Abbrev Number: 4 (DW_TAG_variable)
60 DW_AT_name: ix
65 DW_AT_type: 0x114
69 DW_AT_external: 1
6a DW_AT_location: 9 byte block: 3 50 c 60 0 0 0 0 0
(DW_OP_addr: 600c50)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug debug/43762] New: VLA artificial length var loclist is missing DW_OP_stack_value
gcc (GCC) 4.6.0 20100415 (experimental)
-O2 -g
-
void __attribute__((noinline))
f (int l)
{
char s[l];
}
int
main (void)
{
f (5);
return 0;
}
-
263: Abbrev Number: 5 (DW_TAG_variable)
64 DW_AT_name: s
68 DW_AT_type: 0x74
174: Abbrev Number: 7 (DW_TAG_array_type)
27d: Abbrev Number: 8 (DW_TAG_subrange_type)
82 DW_AT_upper_bound : 0x59
259: Abbrev Number: 4 (DW_TAG_variable)
5a DW_AT_artificial : 1
5b DW_AT_type: 0x8a
5f DW_AT_location: 0x83 (location list)
18a: Abbrev Number: 10 (DW_TAG_const_type)
8b DW_AT_type: 0x87
187: Abbrev Number: 9 (DW_TAG_base_type)
88 DW_AT_byte_size : 8
89 DW_AT_encoding: 7(unsigned)
24c: Abbrev Number: 3 (DW_TAG_formal_parameter)
4d DW_AT_name: l
51 DW_AT_type: 0x6d
55 DW_AT_location: 0x60 (location list)
16d: Abbrev Number: 6 (DW_TAG_base_type)
6e DW_AT_byte_size : 4
6f DW_AT_encoding: 5(signed)
70 DW_AT_name: int
Contents of the .debug_loc section:
Offset BeginEnd Expression
0060 00400460 00400468 (DW_OP_reg5)
0060 End of list
0083 00400460 00400463 (DW_OP_breg5: 0; DW_OP_const1u:
32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_const1s: -1; DW_OP_plus)
0083 00400463 00400468 (DW_OP_breg5: -1)
0083 00400468 0040046c (DW_OP_breg5: -31)
0083 End of list
-
I believe the loclist at 0x83 should have DW_OP_stack_value on each line.
Even according to recent (offlist) mail by Jakub these are location
expressions.
I do not see in the DWARF spec. an explicit description what should mean a DIE
reference for DW_AT_upper_bound, currently generated by GCC as:
82 DW_AT_upper_bound : 0x59
I believe it was designed to supply there the real variable l holding the
value such as if it would be:
82 DW_AT_upper_bound : 0x4c
If an artificial variable calculating the same value is used the artificial
variable should simulate it has such _value_ (and not such its _address_).
(This problem is also affecting Fortran dynamic arrays with -O2 -g.)
--
Summary: VLA artificial length var loclist is missing
DW_OP_stack_value
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43762
[Bug debug/43628] New: [4.5 Regression] in-class func-ptr type parameter has unspecified DW_AT_type
Both these testcases:
--
class C {
public:
typedef void (*t) (C);
};
C::t f;
--
class C {
public:
typedef void (*t) (C);
t v;
} c;
--
produce on
g++ (GCC) 4.4.4 20100402 (prerelease)
144: Abbrev Number: 4 (DW_TAG_subroutine_type)
249: Abbrev Number: 5 (DW_TAG_formal_parameter)
4a DW_AT_type: 0x2d
but on
g++ (GCC) 4.5.0 20100402 (experimental)
153: Abbrev Number: 6 (DW_TAG_subroutine_type)
258: Abbrev Number: 7 (DW_TAG_formal_parameter)
--
Summary: [4.5 Regression] in-class func-ptr type parameter has
unspecified DW_AT_type
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43628
[Bug debug/43478] New: Missing DW_AT_location for a variable
gcc (GCC) 4.5.0 20100322 (experimental)
---
int h (void);
int f (void)
{
int x, y;
x = h () * 2;
y = h () * 2;
return x + y;
}
---
-c -Wall -g -O2
---
250: Abbrev Number: 3 (DW_TAG_variable)
51 DW_AT_name: x
55 DW_AT_type: 0x67
59 DW_AT_location: 0x4c (location list)
25d: Abbrev Number: 4 (DW_TAG_variable)
5e DW_AT_name: y
62 DW_AT_type: 0x67
... but no DW_AT_location
--
Summary: Missing DW_AT_location for a variable
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43478
[Bug debug/43479] New: Missing DW_TAG_lexical_block+DW_TAG_variable
gcc (GCC) 4.5.0 20100322 (experimental)
---
int f (void)
{
int x;
{
int y = 1;
x = y;
}
return x;
}
---
-c -Wall -g -O2
---
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: f
24e: Abbrev Number: 3 (DW_TAG_variable)
4f DW_AT_name: x
53 DW_AT_type: 0x59
57 DW_AT_const_value : 1
... but neither DW_TAG_lexical_block nor DW_TAG_variable(y)
--
Summary: Missing DW_TAG_lexical_block+DW_TAG_variable
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43479
[Bug other/43480] New: build: random timestamps have multilib conflicts
The problem I am trying to solve is: Transaction Check Error: file /usr/share/man/man1/gcj-dbtool.1.gz conflicts between attempted installs of libgcj-4.4.3-8.fc13.x86_64 and libgcj-4.4.3-8.fc13.i686 file /usr/share/man/man1/gij.1.gz conflicts between attempted installs of libgcj-4.4.3-8.fc13.x86_64 and libgcj-4.4.3-8.fc13.i686 file /usr/share/man/man1/grmic.1.gz conflicts between attempted installs of libgcj-4.4.3-8.fc13.x86_64 and libgcj-4.4.3-8.fc13.i686 file /usr/share/man/man1/jv-convert.1.gz conflicts between attempted installs of libgcj-4.4.3-8.fc13.x86_64 and libgcj-4.4.3-8.fc13.i686 It is due to: gzip -dc ./libgcj-4.4.3-8.fc13.i686/usr/share/man/man1/gij.1.gz gij-i686 gzip -dc ./libgcj-4.4.3-8.fc13.x86_64/usr/share/man/man1/gij.1.gz gij-x86_64 diff -u gij-* --- gij-i6862010-03-22 10:17:59.0 +0100 +++ gij-x86_64 2010-03-22 10:18:07.0 +0100 @@ -124,7 +124,7 @@ .\ .\ .IX Title GIJ 1 -.TH GIJ 1 2010-02-27 gcc-4.4.3 GNU +.TH GIJ 1 2010-02-26 gcc-4.4.3 GNU .\ For nroff, turn off justification. Always turn off hyphenation; it makes .\ way too many mistakes in technical documents. .if n .ad l One host built that file a different time (day) then a different host. Moreover the files content should not depend on their time of build. Patch applies to both GCC HEAD SVN and fastjar CVS. fastjar/ 2010-03-22 Jan Kratochvil jan.kratoch...@redhat.com * Makefile.am (fastjar.pod, grepjar.pod): Preserve modification time. * Makefile.in: Regenerate. gcc/java/ 2010-03-22 Jan Kratochvil jan.kratoch...@redhat.com * Make-lang.in (gcj.pod, jcf-dump.pod, gij.pod, jv-convert.pod) (grmic.pod, gcj-dbtool.pod, gc-analyze.pod, aot-compile.pod) (rebuild-gcj-db.pod): Preserve modification time. gcc/fortran/ 2010-03-22 Jan Kratochvil jan.kratoch...@redhat.com * Make-lang.in (gfortran.pod): Preserve modification time. gcc/ 2010-03-22 Jan Kratochvil jan.kratoch...@redhat.com * Makefile.in (%.pod, gcc.pod, gfdl.pod, fsf-funding.pod, gpl.pod): Preserve modification time. libjava/classpath/ 2010-03-22 Jan Kratochvil jan.kratoch...@redhat.com * doc/Makefile.am (gappletviewer.pod, gjarsigner.pod, gjar.pod) (gcjh.pod, gjavah.pod, gkeytool.pod, gnative2ascii.pod, gorbd.pod) (grmid.pod, grmiregistry.pod, gserialver.pod, gtnameserv.pod) (gjdoc.pod): Preserve modification time. * doc/Makefile.in: Regenerate. -- Summary: build: random timestamps have multilib conflicts Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
[Bug other/43480] build: random timestamps have multilib conflicts
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-03-22 16:03 --- Created an attachment (id=20159) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20159action=view) Fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
[Bug testsuite/43482] New: Fix *.log tests merged output containing ===
Posted at, creating PR as its tracker: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00309.html while *.sum files were OK the *.log files sometimes miss the content present in *.sum results. For example [GDB gdb.base/bitfields.exp output was missing while gdb.base/bitfields.exp output was present]. It got broken if arbitrary === string has appeared in the tests output. Grepped dejagnu the proposed more strict pattern should match fine: $ grep === `rpm -ql dejagnu` /usr/share/dejagnu/framework.exp: clone_output \n\t\t=== $tool Summary for $current_target_name ===\n /usr/share/dejagnu/framework.exp: clone_output \n\t\t=== $tool Summary ===\n /usr/share/dejagnu/runtest.exp:clone_output \n\t\t=== $tool tests ===\n For GDB `grep '^Running ' gdb.log | wc -l' changes 1770 - 1818. For GCC `cat *.log | wc -l' changes 444633 - 482178. (checked the output change looks OK for both cases) I am not aware why there was /\===/ instead of just /===/. contrib/ 2010-03-08 Jan Kratochvil jan.kratoch...@redhat.com Fix *.log tests output containing ===. * dg-extract-results.sh (/\===/): Rename to ... (/^\t\t=== .* ===$/): ... this pattern. -- Summary: Fix *.log tests merged output containing === Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
[Bug testsuite/43482] Fix *.log tests merged output containing ===
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-03-22 16:30 --- Created an attachment (id=20162) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20162action=view) Fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
[Bug testsuite/43482] Fix *.log tests merged output containing ===
--- Comment #2 from jan dot kratochvil at redhat dot com 2010-03-22 17:55 --- Checked-in: http://gcc.gnu.org/viewcvs?view=revisionrevision=157645 2010-03-22 Jan Kratochvil jan.kratoch...@redhat.com Fix *.log tests output containing ===. * dg-extract-results.sh (/\===/): Rename to ... (/^\t\t=== .* ===$/): ... this pattern. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
[Bug debug/43325] New: C++ external inner reference does not override outer scope
namespace S
{
int f ()
{
int i = 42;
{
extern int i;
return i;
}
}
}
generates DWARF:
# Grossly simplified.
12d: Abbrev Number: 2 (DW_TAG_namespace)
2e DW_AT_name: S
236: Abbrev Number: 3 (DW_TAG_subprogram)
37 DW_AT_external: 1
38 DW_AT_name: f
3c DW_AT_MIPS_linkage_name: (indirect string, offset: 0x49): _ZN1S1fEv
61 DW_AT_low_pc : 0x0
69 DW_AT_high_pc : 0x13
71 DW_AT_frame_base : 0x0 (location list)
375: Abbrev Number: 7 (DW_TAG_lexical_block)
76 DW_AT_low_pc : 0x4
7e DW_AT_high_pc : 0x11
486: Abbrev Number: 8 (DW_TAG_variable)
87 DW_AT_name: i
8f DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20)
492: Abbrev Number: 9 (DW_TAG_lexical_block)
93 DW_AT_low_pc : 0xb
9b DW_AT_high_pc : 0x11
245: Abbrev Number: 4 (DW_TAG_variable)
46 DW_AT_name: i
4a DW_AT_MIPS_linkage_name: (indirect string, offset: 0x40): _ZN1S1iE
52 DW_AT_external: 1
53 DW_AT_declaration : 1
But the last DIE should have been 545 being in inner DW_TAG_lexical_block
so that debugger would display external variable S::i in the inner block.
(I have inlined the DW_AT_specification reference in the dump above.)
Similar case in C works OK:
int
f (void)
{
int i = 42;
{
extern int i;
return i;
}
}
--
Summary: C++ external inner reference does not override outer
scope
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43325
[Bug debug/42939] Location list ending address should not be one-less
--- Comment #2 from jan dot kratochvil at redhat dot com 2010-02-08 14:59 --- Sorry, I agree now this Bug is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42939
[Bug debug/42939] New: Location list ending address should not be one-less
FAIL: gcc (GCC) 4.5.0 20100202 (experimental)
FAIL: gcc-4.4.3-4.fc12.x86_64
2c2: Abbrev Number: 8 (DW_TAG_variable)
c3 DW_AT_name: x
cb DW_AT_location: 0x92 (location list)
0092 00400509 0040050f (DW_OP_reg0)
0092 00400510 00400517 (DW_OP_lit0; DW_OP_stack_value)
0092 End of list
40050b: e8 d8 fe ff ff callq 4003e8 al...@plt
400510: 31 c0 xor%eax,%eax
Why is x valid on 40050b, 40050c, 40050d, 40050e but optimized-out on 40050f?
:-)
Unfortunately GDB pretends exactly this PC-1 address at the caller frames.
DWARF3 Page 26:
2. An ending address offset. [...] It marks the first address past the end of
the address range over which the location is valid.
The bug is introduced by revision 151312 dwarf2out.c line:
sprintf (loclabel, %s-1, last_label);
which causes:
(gdb) s
alarm () at ../sysdeps/unix/syscall-template.S:82
82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) up
#1 0x00400510 in main (argc=value optimized out, argv=value
optimized out)
at /home/jkratoch/t/zero.c:9
9 alarm (x);
(gdb) p/x $pc
$1 = 0x400510
(gdb) p x
$2 = value optimized out
after a fix:
sprintf (loclabel, %s, last_label);
the loclist is now:
0092 00400509 00400510 (DW_OP_reg0)
0092 00400510 00400517 (DW_OP_lit0; DW_OP_stack_value)
0092 End of list
and GDB prints:
(gdb) p x
$2 = 1804289383
Compiled this testcase with -Wall -g -O2; #includes were not inlined but I hope
it is not a problem for this Bug.
#include stdlib.h
#include unistd.h
int
main (int argc, char **argv)
{
int x = rand ();
alarm (x);
x = 0;
return x;
}
--
Summary: Location list ending address should not be one-less
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42939
[Bug debug/42800] New: VLA DW_AT_upper_bound is no longer emitted
FAIL: gcc (GCC) 4.5.0 20100119 (experimental)
PASS: gcc (GCC) 4.4.3 20100119 (prerelease)
PASS: gcc-4.4.2-20.fc12.x86_64 (Fedora 12)
---
gcc -c -o vla.o vla.c -Wall -g
---
This is a 4.4 - 4.5 debug regression.
---
int
f (int i)
{
char a[i];
return a[0];
}
---
FAIL:
c DW_AT_producer: (indirect string, offset: 0x11): GNU C 4.5.0
20100119 (experimental)
25c: Abbrev Number: 4 (DW_TAG_variable)
5d DW_AT_name: a
61 DW_AT_type: 0x71
65 DW_AT_location: 3 byte block: 91 60 6(DW_OP_fbreg: -32;
DW_OP_deref)
171: Abbrev Number: 6 (DW_TAG_array_type)
72 DW_AT_type: 0x83
27a: Abbrev Number: 7 (DW_TAG_subrange_type)
7b DW_AT_type: 0x80
---
PASS:
c DW_AT_producer: (indirect string, offset: 0x17): GNU C 4.4.3
20100119 (prerelease)
25c: Abbrev Number: 4 (DW_TAG_variable)
5d DW_AT_name: a
61 DW_AT_type: 0x71
65 DW_AT_location: 3 byte block: 91 68 6(DW_OP_fbreg: -24;
DW_OP_deref)
171: Abbrev Number: 6 (DW_TAG_array_type)
72 DW_AT_type: 0x87
27a: Abbrev Number: 7 (DW_TAG_subrange_type)
7b DW_AT_type: 0x84
7f DW_AT_upper_bound : 3 byte block: 91 60 6(DW_OP_fbreg: -32;
DW_OP_deref)
--
Summary: VLA DW_AT_upper_bound is no longer emitted
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
[Bug debug/42801] New: C VLAs should use DW_AT_allocated
FAIL: gcc (GCC) 4.4.3 20100119 (prerelease)
FAIL: gcc-4.4.2-20.fc12.x86_64 (Fedora 12)
SKIP: gcc (GCC) 4.5.0 20100119 (experimental) - N/A - blocked by PR debug/42800
--
Currently the type of a VLA (Variable Length Array) contains incorrect bounds
before the specific variable is allocated. Fortran uses DW_AT_allocated in
such case and GDB with archer-jankratochvil-vla patch properly avoids
evaluating the invalid bounds printing:
(gdb) ptype varx
type = object is not allocated
Currently with -O0 its DW_AT_location is defined even before it is allocated.
With -O2 its DW_AT_location is never defined (suboptimal VTA?). Offtopic here.
Still IMO the type should have DW_AT_allocated indicator and not depend on
never being evaluated when its variable has DW_AT_location undefined
(=optimized out).
This is not a regression bug.
--
static long
f (void)
{
long l = 0x7ffe; /* Pre-fill DW_AT_upper_bound of `a'. */
long unused = l;
return l | unused;
}
static int
g (long l)
{
char a[l];/* gdb -ex 'b 13' -ex r -ex 'ptype a' */
return a[0];
}
int
main (void)
{
f ();
return g (5);
}
--
(gcc -o 1 1.c -m64 -Wall -g; ulimit -v 50; gdb -nx -ex 'b 13' -ex r -ex
'ptype a' ./1)
--
Breakpoint 1, g (l=5) at 1.c:13
13char a[l];/* gdb -ex 'b 13' -ex r -ex 'ptype a' */
../../gdb/utils.c:1205: internal-error: virtual memory exhausted: can't
allocate 2147483647 bytes.
The problem is GDB internally allocates the type being printed (which is
suboptimal). Still it shows the type is valid but with incorrect bounds there.
Reducing the size will print the incorrect bound:
type = char [134217727]
--
Summary: C VLAs should use DW_AT_allocated
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42801
[Bug debug/42801] C VLAs should use DW_AT_allocated
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-01-19 10:57 --- Maybe properly limiting DW_AT_location even in -O0 -g mode would be the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42801
[Bug debug/42782] New: VTA missed location: parameter via stack
gcc (GCC) 4.5.0 20100117 (experimental)
x86_64-unknown-linux-gnu running -m32
Reproduced on Fedora 12: gcc-4.4.2-20.fc12.x86_64
extern void g (void);
int
f (int a)
{
g ();
return a;
}
gcc -o 1.o -c -Wall 1.c -m32 -O1 -g -Wall
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 ec 08sub$0x8,%esp
6: e8 fc ff ff ff call 7 f+0x7
b: 8b 45 08mov0x8(%ebp),%eax
e: c9 leave
f: c3 ret
Contents of the .debug_info section:
240: Abbrev Number: 3 (DW_TAG_formal_parameter)
41 DW_AT_name: a
49 DW_AT_location: 0x38 (location list)
Contents of the .debug_loc section:
Offset BeginEnd Expression
0038 000a (DW_OP_fbreg: 0)
0038 End of list
Offsets 0xb .. 0xf miss the A location.
The function must know it when it returns A.
Practical impact:
Backtrace missed parameters of elf_lookup_lib_symbol() in:
https://bugzilla.redhat.com/show_bug.cgi?id=556310
--
Summary: VTA missed location: parameter via stack
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: i386-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42782
[Bug debug/42782] VTA missed location: parameter via stack
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-01-17 23:23 --- Noticed it is a regression against: gcc (GCC) 4.4.3 20100117 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42782
[Bug debug/42065] New: DWARF .debug_macinfo contains unused macros
-g3 currently produces huge objects as it contains many unused macros.
-g2 produces no macros debug info so GDB cannot provide its expansion.
There is no way to store just the used macros.
(debuginfo compression driven by Roland McGrath may eliminate them but
still...)
While even a macro never used by a program can be helpful in most cases IMO it
is enough to provide the macro definitions touched by the code being debugged.
-feliminate-unused-debug-symbols -feliminate-unused-debug-types have no effect.
---
#define NOT used
#define USED(x) x
int main (void) { return USED (0); }
---
Getting:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 1 macro : NOT used
DW_MACINFO_define - lineno : 2 macro : USED(x) x
or:
gcc -g2 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
nothing printed
Expected output:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 2 macro : USED(x) x
--
Summary: DWARF .debug_macinfo contains unused macros
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
[Bug debug/42065] DWARF .debug_macinfo contains unused macros
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-11-16 14:49 --- (In reply to comment #1) -g3 currently produces huge objects as it contains many unused macros. -g2 produces no macros debug info so GDB cannot provide its expansion. That is by design and the reason why -g is -g2 by default OK, thanks for info, still IMO there should be such an additional option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
[Bug debug/41558] gfortran -O code excessive DW_OP_deref's
--- Comment #3 from jan dot kratochvil at redhat dot com 2009-10-06 15:28 --- (In reply to comment #1) BTW, gdb 7.0.50.20091005-cvs doesn't work with the guality.exp testcases well, something broke in it recently. 6.8.91.20090917-1.fc12 works fine. There is an array with variable size: integer :: a(n), n VLA support is still missing in FSF GDB, it is present in Archer (+Fedora) branch archer-jankratochvil-vla: http://sourceware.org/gdb/wiki/ArcherBranchManagement -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41558
[Bug debug/41558] New: gfortran -O code excessive DW_OP_deref's
GNU Fortran (GCC) 4.5.0 20091003 (experimental)
subroutine f(s)
character*3 s
s = s
end
call f ('foo')
end
gdb -nx -ex 'b 3' -ex r -ex 'p s' ./file
-
Cannot access memory at address 0x6f6f66
24a: Abbrev Number: 3 (DW_TAG_formal_parameter)
4b DW_AT_name: s
4f DW_AT_type: 0x64
53 DW_AT_location: 4 byte block: 75 0 6 6 (DW_OP_breg5: 0;
DW_OP_deref; DW_OP_deref)
If I patch those two DW_OP_deref - DW_OP_nop then GDB prints:
$1 = 'foo'
gfortran -o 1 1.f90 -Wall -g -O1
currently:
.LC0:
.ascii foo
...
movl$.LC0, %edi
...
.byte 0x4 # DW_AT_location
.byte 0x75# DW_OP_breg5
.sleb128 0
.byte 0x6 # DW_OP_deref
.byte 0x6 # DW_OP_deref
--
Summary: gfortran -O code excessive DW_OP_deref's
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41558
[Bug c/41469] New: -fexceptions ICE in expand_gimple_stmt_1, at cfgexpand.c:1947
void
af (void *a)
{
}
void
bf (void)
{
int i = 1;
char v[i];
af (v);
}
.../xgcc (-B...) -fexceptions -c -o 1.o 1.c
1.c: In function âbfâ:
1.c:6:1: internal compiler error: in expand_gimple_stmt_1, at cfgexpand.c:1947
xgcc (GCC) 4.5.0 20090925 (experimental)
--
Summary: -fexceptions ICE in expand_gimple_stmt_1, at
cfgexpand.c:1947
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41469
[Bug c/41470] New: -fexceptions ICE in partition_view_bitmap, at tree-ssa-live.c:331
void *
af (void *a)
{
return a;
}
void
bf (void)
{
void *p;
{
int i = 1;
char v[i];
p = af (v);
}
cf (p);
}
.../xgcc (-B...) -fexceptions -c -o 1.o 1.c
1.c: In function âbfâ:
1.c:7:1: internal compiler error: in partition_view_bitmap, at
tree-ssa-live.c:331
xgcc (GCC) 4.5.0 20090925 (experimental)
Expecting it is a duplicate of similar Bug 41469.
--
Summary: -fexceptions ICE in partition_view_bitmap, at tree-ssa-
live.c:331
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41470
[Bug debug/41065] New: DW_TAG_enumeration_type+DW_TAG_enumerator is sometimes missing
GCC omits the enumeration type if only its enumeration values get used.
The type with its enumerator is described by DWARF if the type itself is used.
enum { a, b };
int v = a;
char s[b];
No a or b is put in DWARF. Some other variants can be created.
Workaround:
enum { a, b } dummy;
int v = a;
char s[b];
Tested as buggy:
GNU C 4.5.0 20090814 (experimental)
GNU C 4.4.2 20090806 (prerelease)
GNU C 4.4.0 20090506 (Red Hat 4.4.0-4)
--
Summary: DW_TAG_enumeration_type+DW_TAG_enumerator is sometimes
missing
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41065
[Bug debug/40040] New: gfortran invalid DW_AT_location for overridable variables
Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-05-06 10:54 --- (In reply to comment #1) If DW_AT_location isn't provided, how would gdb find that address out? Using DW_AT_MIPS_linkage_name (currently not emitted) and symbol lookup? The GDB patch now assembles the symbol name from its parent DW_TAG_module as `__modulename_MOD_varname'. As GDB also has to know the C++ mangling rules I believe this Fortran mangling is can be also used from GDB. If GDB should never guess the fully qualified names I will have to file at least one more GCC fortran debug/ PR for DW_TAG_imported_declaration which already uses only DW_TAG_variable with DW_AT_declaration and no DW_AT_location. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #5 from jan dot kratochvil at redhat dot com 2009-05-06 20:12 --- (In reply to comment #4) I don't know how ready GDB et al are to cope with this, (For GDB the local definitions containing an address expression are even less problematic than the current declarations requiring mangled symbols resolving.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug debug/35462] anonymous struct in c++ has wrong name in -gdwarf-2
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-04-30 07:52 --- Please close it as DUPLICATE of PR debug/35463. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35462
[Bug debug/35463] typedef missing in debug information with -gdwarf-2 for c++
--- Comment #5 from jan dot kratochvil at redhat dot com 2009-04-30 15:15 --- Just that I agree this Bug looks to me fixed in g++-4.5. The sample code like what is Comment 0 here from: http://gcc.gnu.org/ml/gcc-help/2009-04/msg00393.html gives DW_TAG_structure_type DW_AT_name anonymous struct on: g++ (GCC) 4.4.0 20090427 (Red Hat 4.4.0-3) and gives DW_TAG_structure_type DW_AT_name type27 on: g++ (GCC) 4.5.0 20090430 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
[Bug debug/39563] C block scopes have no DW_TAG_lexical_block
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-04-02 21:09 --- Fixed in FSF GDB HEAD: http://sourceware.org/ml/gdb-patches/2009-03/threads.html#00595 http://sourceware.org/ml/gdb-patches/2009-04/threads.html#00040 http://sourceware.org/ml/gdb-cvs/2009-04/msg00021.html gdb/ * dwarf2read.c (new_symbol DW_TAG_variable !DW_AT_location DW_AT_external): Create the symbol in local scope. * symtab.h (cu-list_in_scope LOC_UNRESOLVED): New comment part. gdb/testsuite/ * gdb.dwarf2/dw2-unresolved-main.c, gdb.dwarf2/dw2-unresolved.S, gdb.dwarf2/dw2-unresolved.exp: New. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
[Bug debug/39267] [4.4/4.5 Regression] gdb testsuite regressions
--- Comment #6 from jan dot kratochvil at redhat dot com 2009-04-02 21:26 --- No real regressions. Formally: +FAIL: gdb.base/stack-checking.exp: continue to breakpoint: breakpoint for big frame +FAIL: gdb.base/stack-checking.exp: bt which is PR middle-end/13757: -fstack-check In gcc-4.3.2 it had no effect and printed: warning: frame size too large for reliable stack checking In gcc 4.5.0 20090328 it produces no warnings and code not shifting down %rsp and thus crashing under Linux kernel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39267
[Bug debug/39563] C block scopes have no DW_TAG_lexical_block
--- Comment #6 from jan dot kratochvil at redhat dot com 2009-03-28 21:34
---
No regressions for GDB.
GDB requires the extra patch otherwise it still does not work with patched GCC:
http://sourceware.org/ml/gdb-patches/2009-03/msg00595.html
FYI the patch generates one extra file-scope declaration:
int f (void) { extern int var; return var; }
c DW_AT_producer: (indirect string, offset: 0x0): GNU C 4.5.0
20090328 (experimental)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: f
[...]
250: Abbrev Number: 3 (DW_TAG_variable)
51 DW_AT_name: var
55 DW_AT_decl_file : 1
56 DW_AT_decl_line : 1
57 DW_AT_type: 0x5e
5b DW_AT_external: 1
5c DW_AT_declaration : 1
[...]
165: Abbrev Number: 3 (DW_TAG_variable)
66 DW_AT_name: var
6a DW_AT_decl_file : 1
6b DW_AT_decl_line : 1
6c DW_AT_type: 0x5e
70 DW_AT_external: 1
71 DW_AT_declaration : 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
[Bug debug/39563] New: C block scopes have no DW_TAG_lexical_block
GNU C 4.4.0 20090326 (experimental)
GDB variables lookup does not match the C code lookup.
Similiar C++ code in PR debug/39524 uses DW_TAG_lexical_block.
$ gdb -q ./externvar
(gdb) l 1
1 #include stdlib.h
2
3 int var = 2;
4
5 int
6 main (void)
7 {
8 int var = 1;
9
10if (var != 1)
11 abort ();
12
13{
14 extern int var;
15
16 if (var != 2)
17abort ();
18}
19
20return 0;
21 }
(gdb) b 16
Breakpoint 1 at 0x4004d2: file externvar.c, line 16.
(gdb) r
Starting program: /tmp/externvar
Breakpoint 1, main () at externvar.c:16
16 if (var != 2)
(gdb) p var
$1 = 1
(gdb) c
Continuing.
Program exited normally.
(gdb) q
--
c DW_AT_producer: (indirect string, offset: 0xe): GNU C 4.4.0
20090326 (experimental)
17d: Abbrev Number: 5 (DW_TAG_subprogram)
7f DW_AT_name: (indirect string, offset: 0x63): main
8a DW_AT_low_pc : 0x4004b8
92 DW_AT_high_pc : 0x4004e9
2a2: Abbrev Number: 6 (DW_TAG_variable)
a3 DW_AT_name: var
a9 DW_AT_type: 0x34
ad DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20)
1b1: Abbrev Number: 7 (DW_TAG_variable)
b2 DW_AT_name: var
b8 DW_AT_type: 0x34
bc DW_AT_external: 1
bd DW_AT_location: 9 byte block: 3 70 8 60 0 0 0 0 0
(DW_OP_addr: 600870)
Missing there something like:
2c0: Abbrev Number: 6 (DW_TAG_lexical_block)
c1 DW_AT_low_pc : 0x4005b2
c9 DW_AT_high_pc : 0x4005c2
3b1: Abbrev Number: 7 (DW_TAG_variable)
b2 DW_AT_name: var
b8 DW_AT_type: 0x34
bc DW_AT_external: 1
bd DW_AT_location: 9 byte block: 3 70 8 60 0 0 0 0 0
(DW_OP_addr: 600870)
--
Summary: C block scopes have no DW_TAG_lexical_block
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
[Bug debug/39563] C block scopes have no DW_TAG_lexical_block
--- Comment #1 from jan dot kratochvil at redhat dot com 2009-03-26 22:57 --- As DW_AT_external-DW_TAG_variable in the inner block is incompatible with current GDB http://sourceware.org/ml/gdb-patches/2009-03/msg00595.html the current C++ method of DW_TAG_imported_declaration referencing the file-level DW_AT_external-DW_TAG_variable may be more appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
[Bug debug/39524] New: Duplicite C++ DW_TAG_variable breaking its DW_AT_location resolution
Tested on: GNU C++ 4.4.0 20090323 (experimental)
Testcase:
--
namespace A
{
static int var2 = 2;
}
int
func (void)
{
using A::var2;
return var2;
}
--
will generate (reduced):
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x42): func
3d DW_AT_low_pc : 0x0
45 DW_AT_high_pc : 0xc
4d DW_AT_frame_base : 0x0 (location list)
255: Abbrev Number: 3 (DW_TAG_lexical_block)
56 DW_AT_low_pc : 0x4
5e DW_AT_high_pc : 0xa
366: Abbrev Number: 4 (DW_TAG_imported_declaration)
69 DW_AT_import : 0x7f [Abbrev Number: 7 (DW_TAG_variable)]
176: Abbrev Number: 6 (DW_TAG_namespace)
77 DW_AT_name: A
27f: Abbrev Number: 7 (DW_TAG_variable)
80 DW_AT_name: (indirect string, offset: 0x34): var2
84 DW_AT_decl_file : 1
85 DW_AT_decl_line : 3
86 DW_AT_type: 0x6f
8a DW_AT_declaration : 1
28b: Abbrev Number: 7 (DW_TAG_variable)
8c DW_AT_name: (indirect string, offset: 0x34): var2
84 DW_AT_decl_file : 1
85 DW_AT_decl_line : 3
92 DW_AT_type: 0x6f
96 DW_AT_declaration : 1
198: Abbrev Number: 8 (DW_TAG_variable)
99 DW_AT_specification: 0x8b
9d DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0)
You can see the code references the 7f var instance but DW_AT_location is
given by the 98 completion only for the 8b var instance.
Also 7f and 8b have a name conflict as being in the same naming scope.
This problem causes a wrong evaluation by Archer archer-keiths-expr-cumulative
branch (which is IMO right) for the more complex testcase - as it cannot find
the right DW_AT_location there:
--
# archer-keiths-expr-cumulative=35ca449e9f1a4cd477df644f717bbe4e3362c486/gdb -q
./outer
(gdb) l 1
1 #include stdlib.h
2
3 namespace A
4 {
5 static int var = 2;
6 }
7
8 int
9 main (void)
10 {
11int var = 1;
12
13if (var != 1) /* var-is-1 */
14 abort ();
15
16{
17 using A::var;
18
19 if (var != 2) /* var-is-2 */
20abort ();
21}
22
23return 0; /* break-here */
24 }
(gdb) b 13
Breakpoint 1 at 0x4005a7: file outer.C, line 13.
(gdb) r
Starting program: /tmp/outer
Breakpoint 1, main () at outer.C:13
13if (var != 1) /* var-is-1 */
(gdb) p var
$1 = 1
(gdb) adv 19
main () at outer.C:19
19 if (var != 2) /* var-is-2 */
(gdb) p var
$2 = 1
^^ Wrong GDB evaluation.
(gdb) adv 23
main () at outer.C:23
23return 0; /* break-here */
(gdb) q
--
--
Summary: Duplicite C++ DW_TAG_variable breaking its
DW_AT_location resolution
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
[Bug debug/39524] Duplicate C++ DW_TAG_variable breaking its DW_AT_location resolution
--- Comment #3 from jan dot kratochvil at redhat dot com 2009-03-23 11:32 --- One fix should be enough next time, thanks. Going to gdb-regression test both the patches (in Fedora GCC on Fedora 11). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39524
[Bug debug/39485] -O0 -g still puts whole object to a register
--- Comment #3 from jan dot kratochvil at redhat dot com 2009-03-18 18:01 --- I see I messed it up, in some way was gcc-4.4 more correct than gcc-4.3 Thanks for the fix although now I would not probably bugreport it at all. It turned PASS-XFAIL. But in fact PASS means SKIP(not-testable) and XFAIL means PASS - for GDB. gdb.cp/classes.exp: # This class is so small that an instance of it can fit in a register. # When gdb tries to call a method, it gets embarrassed about taking # the address of a register. # # TODO: I think that message should be a PASS, not an XFAIL. # gdb prints an informative message and declines to do something # impossible. # # The method call actually succeeds if the compiler allocates very # small classes in memory instead of registers. So this test does # not tell us anything interesting if the call succeeds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39485
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-03-17 10:05 --- I no longer see any DWARF problem there but Archer C++ still does not work with g++-4.4. Assuming an Archer bug due to the new DW_TAG_lexical_block block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39474] DW_AT_location missing for unused variables even at -O0
--- Comment #3 from jan dot kratochvil at redhat dot com 2009-03-17 10:03 --- It works for the gdb.python/python-template.exp test, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
[Bug debug/39485] New: -O0 -g still puts whole object to a register
A regression from 4.3 for GNU C++ 4.4.0 20090317 (experimental)
-PASS: gdb.cp/classes.exp: calling method for small class
+XFAIL: gdb.cp/classes.exp: calling method for small class (PRMS 2972)
---
Breakpoint 1, main () at small.C:36
36return v.x + 5; /* break-here */
(gdb) p v.method()
Address requested for identifier v which is in register $rbx
---
from gcc-4.3:
(gdb) p v.method()
$1 = 82
---
/* from gdb.cp/classes.cc */
/* Try to get the compiler to allocate a class in a register. */
class small {
public:
int x;
int method ();
};
int
small::method ()
{
return x + 5;
}
void marker_reg1 () {}
int
main ()
{
/* We don't call any methods for v, so gcc version cygnus-2.3.3-930220
might put this variable in a register. This is a lose, though, because
it means that GDB can't call any methods for that variable. */
register small v;
int i;
/* Perform a computation sufficiently complicated that optimizing compilers
won't optimized out the variable. If some compiler constant-folds this
whole loop, maybe using a parameter to this function here would help. */
v.x = 0;
for (i = 0; i 13; ++i)
v.x += i;
--v.x; /* v.x is now 77 */
marker_reg1 ();
return v.x + 5; /* break-here */
}
---
c DW_AT_producer: (indirect string, offset: 0x19): GNU C++ 4.4.0
20090317 (experimental)
3ed: Abbrev Number: 14 (DW_TAG_variable)
ee DW_AT_name: v
f2 DW_AT_type: 0x2d
f6 DW_AT_location: 1 byte block: 53 (DW_OP_reg3)
Formerly the class was left in memory:
c DW_AT_producer: (indirect string, offset: 0x31): GNU C++ 4.3.2
20081105 (Red Hat 4.3.2-7)
2dc: Abbrev Number: 13 (DW_TAG_variable)
dd DW_AT_name: v
e1 DW_AT_type: 0x2d
e5 DW_AT_location: 2 byte block: 76 6c (DW_OP_breg6: -20)
Moreover small::method() expects the object to be in memory so GDB cannot just
pass it in the %ebx register as is:
c DW_AT_producer: (indirect string, offset: 0x19): GNU C++ 4.4.0
20090317 (experimental)
245: Abbrev Number: 4 (DW_TAG_subprogram)
46 DW_AT_external: 1
47 DW_AT_name: (indirect string, offset: 0xc): method
51 DW_AT_type: 0x5e
55 DW_AT_declaration : 1
356: Abbrev Number: 5 (DW_TAG_formal_parameter)
57 DW_AT_type: 0x65
5b DW_AT_artificial : 1
16b: Abbrev Number: 8 (DW_TAG_subprogram)
6c DW_AT_specification: 0x45
81 DW_AT_frame_base : 0x0 (location list)
289: Abbrev Number: 9 (DW_TAG_formal_parameter)
8a DW_AT_name: (indirect string, offset: 0x52): this
8e DW_AT_type: 0x97
92 DW_AT_artificial : 1
93 DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24)
GDB could probably use a (trivial=memcpy in this case) copy constructor (+later
destructor) from %ebx to a memory location.
--
Summary: -O0 -g still puts whole object to a register
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39485
[Bug debug/37890] Incorrect nesting for DW_TAG_imported_declaration
--- Comment #1 from jan dot kratochvil at redhat dot com 2009-03-16 14:24 --- Verified as the problem exists on GNU C++ 4.4.0 20090315 (experimental). Tried also non-main function and slightly complicated function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37890
[Bug debug/39471] New: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
Regression from g++-4.3 for GNU C++ 4.4.0 20090315 (experimental)
(+also for 4.4.0 20090313 (Red Hat 4.4.0-0.26))
For full namespace import one should use DW_TAG_imported_module.
1:namespace A
2:{
3: int i = 1;
4:}
5:
6:int
7:main ()
8:{
9: using namespace A;
10: i = 2;
11: return 0;
12:}
Using g++-4.4 DWARF one must use `A::i' at `main' in the debugger.
The whole namespace `A' should be imported there instead.
WRONG g++-4.4 debuginfo:
c DW_AT_producer: (indirect string, offset: 0x0): GNU C++ 4.4.0
20090315 (experimental)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x7d): main
251: Abbrev Number: 3 (DW_TAG_lexical_block)
52 DW_AT_low_pc : 0x4
5a DW_AT_high_pc : 0x13
362: Abbrev Number: 4 (DW_TAG_imported_declaration)
65 DW_AT_name: A
67 DW_AT_import : 0x74 [Abbrev Number: 6 (DW_TAG_namespace)]
174: Abbrev Number: 6 (DW_TAG_namespace)
75 DW_AT_name: A
27d: Abbrev Number: 7 (DW_TAG_variable)
7e DW_AT_name: i
82 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x74): _ZN1A1iE
Correct g++-4.3 debuginfo:
c DW_AT_producer: (indirect string, offset: 0x0): GNU C++ 4.3.2
20081105 (Red Hat 4.3.2-7)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x80): main
251: Abbrev Number: 3 (DW_TAG_imported_module)
54 DW_AT_import : 0x60 [Abbrev Number: 5 (DW_TAG_namespace)]
160: Abbrev Number: 5 (DW_TAG_namespace)
61 DW_AT_name: A
269: Abbrev Number: 6 (DW_TAG_variable)
6a DW_AT_name: i
6e DW_AT_MIPS_linkage_name: (indirect string, offset: 0x77): _ZN1A1iE
72 DW_AT_type: 0x59
It causes regressions on gdb.cp/namespace-using.exp for the GDB project Archer.
--
Summary: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39474] New: DW_AT_location missing for unused variables even at -O0
It is a regression since gcc-4.3 but it was found only at artificial (GDB)
testcase. Also at -O2 such behavior is even expected.
The variable is considered as optimized-out which should not happen on -O0.
Testcase:
--
int
main (void)
{
int var;
return 0;
}
--
gcc -Wall -g
WRONG gcc-4.4:
c DW_AT_producer: (indirect string, offset: 0xb): GNU C 4.4.0
20090315 (experimental)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x39): main
252: Abbrev Number: 3 (DW_TAG_variable)
53 DW_AT_name: var
59 DW_AT_type: 0x5e
Correct gcc-4.3:
c DW_AT_producer: (indirect string, offset: 0xf): GNU C 4.3.2
20081105 (Red Hat 4.3.2-7)
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2f DW_AT_name: (indirect string, offset: 0x36): main
252: Abbrev Number: 3 (DW_TAG_variable)
53 DW_AT_name: var
59 DW_AT_type: 0x61
5d DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20)
--
Summary: DW_AT_location missing for unused variables even at -O0
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39474
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-03-16 21:37 --- Thanks although there is still excessive DW_AT_name: 3422: Abbrev Number: 12 (DW_TAG_imported_module) 425 DW_AT_name: A 427 DW_AT_import : 0x113 [Abbrev Number: 2 (DW_TAG_namespace)] DW_AT_name looks as undefined for me for DW_TAG_imported_module and it certainly breaks the current Archer C++ implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #13 from jan dot kratochvil at redhat dot com 2009-02-12 09:35 --- The flat (so far no namespacing) DW_TAG_module support is now in GDB CVS. http://sourceware.org/ml/gdb-cvs/2009-02/msg00073.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-02-02 13:48 --- Confirming it is a GDB bug, DW_TAG_module is completely ignored by dwarf2read.c. Older GCCs did not support module namespaces so it may look as a regression. I hope to patch it soon although I have no such patch right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug debug/7081] DWARF enhancements for C++
--- Comment #13 from jan dot kratochvil at redhat dot com 2008-12-21 19:33 --- Please make this Bug CLOSED as the point 1 has been fixed by Alexandre Oliva and the point 2 is already filed as PR debug/11208. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7081
[Bug debug/36748] scev const-prop pass adds bad line numbers
--- Comment #2 from jan dot kratochvil at redhat dot com 2008-12-06 13:22 --- It looks fixed in 4.4 for me, tested on: GNU C (GCC) version 4.4.0 20081202 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081202 (experimental), GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Line 13 in .line_debug is now assigned only to the main address (in Fedora gcc-4.3.2-7.x86_64 it was assigned also to the factorial address). Expecting it got fixed by Jakub Jelinek as a part of the Bug 36690. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug debug/38390] New: Missing DW_TAG_imported_module
It works on Fedora gcc-c++-4.3.2-7.x86_64 but on 4.4-HEAD DIEs for
DW_TAG_imported_module are just missing.
import.C
--
namespace A
{
int v;
}
int
f ()
{
using namespace A;
return v;
}
--
g++ -c -o import.o import.C -Wall -g
From gcc-c++-4.3.2-7.x86_64:
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2e DW_AT_external: 1
2f DW_AT_name: f
31 DW_AT_decl_file : 1
32 DW_AT_decl_line : 7
33 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x37): _Z1fv
37 DW_AT_type: 0x5b
3b DW_AT_low_pc : 0x0
43 DW_AT_high_pc : 0xc
4b DW_AT_frame_base : 0x0 (location list)
4f DW_AT_sibling : 0x5b
253: Abbrev Number: 3 (DW_TAG_imported_module)
54 DW_AT_decl_file : 1
55 DW_AT_decl_line : 9
56 DW_AT_import : 0x62 [Abbrev Number: 5 (DW_TAG_namespace)]
From
GNU C++ (GCC) version 4.4.0 20081202 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20081202 (experimental), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
12d: Abbrev Number: 2 (DW_TAG_subprogram)
2e DW_AT_external: 1
2f DW_AT_name: f
31 DW_AT_decl_file : 1
32 DW_AT_decl_line : 7
33 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x2b): _Z1fv
37 DW_AT_type: 0x4f
3b DW_AT_low_pc : 0x0
43 DW_AT_high_pc : 0xc
4b DW_AT_frame_base : 0x0 (location list)
(other DIEs exactly the same, DW_TAG_imported_module is missing here)
--
Summary: Missing DW_TAG_imported_module
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38390
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #7 from jan dot kratochvil at redhat dot com 2008-11-29 00:23 --- (In reply to comment #6) I ran into this issue because gdb was only reading die 0x86 for variable 'elsewhere' (I have not looked into why). The problem is that without proper scoping on an abstract_origin attribute, so the correct canonical name for this variable cannot be constructed (without relying on DW_AT_MIPS_linkage_name that is). Therefore a 'print A::elsewhere' command fails DW_AT_MIPS_linkage_name should be removed from GCC only after the DW_AT_name scoping/qualification will get fully fixed. GDB currently already contains the DW_AT_MIPS_linkage_name reader and there is probably no need to disable it (except for testing purposes). On GDB CVS HEAD for gdb.cp/m-static.exp a command `print gnu_obj_4::elsewhere' works for me as it can find (presumably) the corrent .symtab mangled symbol. Sure it would be good to get DW_AT_name fixed in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #5 from jan dot kratochvil at redhat dot com 2008-11-28 01:36 --- (In reply to comment #4) First, I think the DIE representing the defining declaration of A::elsewhere in class2.c should have a DW_AT_specification pointing back to the DIE representing the declaration or A::elsewhere in class.h. Already present: non-defining declaration is cf, the defining declaration is ed. ed properly points by DW_AT_specification to its cf. Second, I think the DIE of the defining declaration of A::elsewhere in class2 should have a DW_AT_const_value attribute whose value should be the constant 211. This can be deduced from the dwarf2 spec, section [4.1 Data Object Entries], point 9, pdf page 35, spec page 33 that reads: 9. An entry describing a variable whose value is constant and not represented by an object in the address space of the program, or an entry describing a named constant, does not have a location attribute. DW_AT_const_value is more for Fortran constants which are an equivalent of C #define. In the sample code here `static const int' is in .rodata, it has its address (DW_AT_location) and can be tracked by `rwatch' (read-watchpoint). [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [15] .rodata PROGBITS 00400658 0658 0014 A 0 0 8 Symbol table '.symtab' contains 73 entries: Num:Value Size TypeBind Vis Ndx Name 55: 00400668 4 OBJECT GLOBAL DEFAULT 15 _ZN1A9elsewhereE It should be sufficient the type entry at 0xe1 (not shown in the sample dump here) is already correctly DW_TAG_const_type. And third, as you pointed out, the DIE of the declaration of A::elsewhere should not appear twice in the class.c compilation unit. It should only appear once, in the scope of the A class. Two vs. one DIE is not a mistake but more a minor optimization (such optimization is already Bug debug/37941). With single DIE it would look OK to me. With two DIEs there are currently these problems: (1) DW_AT_name is now `elsewhere' while it should be either `A::elsewhere' or whole DW_TAG_variable should be enclosed by DW_TAG_class_type for `A'. It may be Bug c++/37590. (Non-standard DW_AT_MIPS_linkage_name should be removed in the future.) (2) Defining declaration 86 should point by DW_AT_specification to its non-defining declaration 37. (The DWARF citation is here from Dodji.) (But I do not see these two problems as real issues for debugging.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug fortran/38248] New: Fatal Error: Reading module mmm: Expected left parenthesis
Minimal testcase to `use' some module cannot be compiled. Compilation works fine on Fedora gcc-gfortran-4.3.2-7.x86_64. GNU Fortran (GCC) version 4.4.0 20081124 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081124 (experimental), GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 $ gcc-build/gcc/f951 -o gccmod.s gccmod.f90 -Wall -ggdb2 initFatal Error: Reading module mmm at line 16 column 65: Expected left parenthesis $ cat gccmod.f90 module mmm contains subroutine init end subroutine init end module mmm program main use mmm end program main $ _ (In fact no `module mmm' part needs to be present there.) -- Summary: Fatal Error: Reading module mmm: Expected left parenthesis Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug fortran/38248] Ignored temporary module files manipulation errors
-- jan dot kratochvil at redhat dot com changed: What|Removed |Added Severity|blocker |normal Summary|Fatal Error: Reading module |Ignored temporary module |mmm: Expected left |files manipulation errors |parenthesis | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug fortran/38248] Ignored temporary module files manipulation errors
--- Comment #3 from jan dot kratochvil at redhat dot com 2008-11-24 16:40
---
Created an attachment (id=16759)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16759action=view)
Check the file manipulations errors.
Thanks Tobias B.,
unlink(mmm.mod) = -1 EPERM (Operation not permitted)
rename(mmm.mod0, mmm.mod) = -1 EPERM (Operation not permitted)
write(2, init..., 5) = 5
stat(mmm.mod, {st_mode=S_IFREG|0644, st_size=547, ...}) = 0
open(mmm.mod, O_RDONLY) = 4
With the attached patch the same command now fails for me:
Fatal Error: Can't delete module file 'mmm.mod': Operation not permitted
I have no GCC SVN write permissions.
Left one unchecked unlink() in an error recovery path there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug debug/37941] Too many DW_TAG_Subprogram tags generated
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-11-24 20:08 --- The excessive item 53 is really still present in Fedora gcc-c++-4.3.2-7.x86_64 but not in HEAD - 4.4.0 20081124: 12d: Abbrev Number: 2 (DW_TAG_namespace) 2e DW_AT_name: D 30 DW_AT_decl_file : 1 31 DW_AT_decl_line : 7 32 DW_AT_sibling : 0x48 236: Abbrev Number: 3 (DW_TAG_subprogram) 37 DW_AT_external: 1 38 DW_AT_name: foo 3c DW_AT_decl_file : 1 3d DW_AT_decl_line : 8 3e DW_AT_MIPS_linkage_name: (indirect string, offset: 0x3c): _ZN1D3fooEv 42 DW_AT_type: 0x48 46 DW_AT_declaration : 1 [...] 14f: Abbrev Number: 5 (DW_TAG_subprogram) 50 DW_AT_specification: 0x36 54 DW_AT_low_pc : 0x0 5c DW_AT_high_pc : 0x17 64 DW_AT_frame_base : 0x0 (location list) As D::foo() has no extra declaration as it is defined in the class definition 36 and 4f could be merged but it is only a minor optimization now as for common separate declaration and definition two DIEs still have to exist to have distinct DW_AT_decl_line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37941
[Bug debug/29628] unused argc/argv missing their DW_AT_location
--- Comment #3 from jan dot kratochvil at redhat dot com 2008-10-13 14:34 --- Fedora gcc-4.3.2-6.x86_64 with -m32 is still buggy as described in the Comment 0. But HEAD works OK now (-m32) so closing, thanks for the test: GNU C (GCC) version 4.4.0 20081007 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081007 (experimental), GMP version 4.2.2, MPFR version 2.3.1. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29628
[Bug libstdc++/37718] Demangling of variadic functions
--- Comment #3 from jan dot kratochvil at redhat dot com 2008-10-07 23:10 --- FYI I find at least this specific reported testcase as already fixed by Jason: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00729.html http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00189.html GCC now even produces different mangled names: GNU C++ (GCC) version 4.4.0 20081007 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081007 (experimental), GMP version 4.2.2, MPFR version 2.3.1. 004005c3 w F .text 003f _Z1fIdIiEEiT_DpT0_ 00400602 w F .text 0012 _Z1fIiIEEiT_DpT0_ 00400584 w F .text 003f _Z1fIiIdiEEiT_DpT0_ 004005c3 w F .text 003f int fdouble, int(double, int) 00400602 w F .text 0012 int fint, (int, ) 00400584 w F .text 003f int fint, double, int(int, double, int) -- jan dot kratochvil at redhat dot com changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37718
[Bug debug/37738] New: Fortran DW_TAG_common_block has incorrect placement/scope
(DW_TAG_subprogram) dd DW_AT_name: c 1f5: Abbrev Number: 8 (DW_TAG_subprogram) f7 DW_AT_name: abc 111 DW_AT_calling_convention: 2 (program) -- Summary: Fortran DW_TAG_common_block has incorrect placement/scope Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug debug/37738] Fortran DW_TAG_common_block has incorrect placement/scope
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-10-05 15:33 --- Saw there also needless DW_OP_plus_uconst - it could be single DW_OP_addr for all the common block variables (which would make the GDB support a bit easier). program a2 INTEGER*4 a INTEGER*4 b common /block/a,b a = 1 a = 2 end program a2 24d: Abbrev Number: 3 (DW_TAG_common_block) 4e DW_AT_name: (indirect string, offset: 0x46): block 54 DW_AT_location: 9 byte block: 3 e0 a 60 0 0 0 0 0 (DW_OP_addr: 600ae0) 35e: Abbrev Number: 4 (DW_TAG_variable) 5f DW_AT_name: a 68 DW_AT_location: 9 byte block: 3 e0 a 60 0 0 0 0 0 (DW_OP_addr: 600ae0) 372: Abbrev Number: 4 (DW_TAG_variable) 73 DW_AT_name: b 7c DW_AT_location: 11 byte block: 3 e0 a 60 0 0 0 0 0 23 4 (DW_OP_addr: 600ae0; DW_OP_plus_uconst: 4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37738
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #6 from jan dot kratochvil at redhat dot com 2008-09-22 15:32 --- Tom, could you elaborate why x1 and x2 should be printed differently? I do not say they should not but I do not see a clear reason for either way. Should we also try to record the source name of this variable? #define OBJECT_VAR(object, var) object ## _ ## var int OBJECT_VAR (window, width); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug debug/37410] New: DW_TAG_imported_module is not in its DW_TAG_lexical_block
DW_TAG_imported_module (c++ `using namespace') has validity only in the same block in which they are stated. It works right for the compiled code but it gets defined for the whole function in DWARF. DW_TAG_imported_module should be located in DW_TAG_lexical_block. Without the `int block_create;' declaration the whole DW_TAG_lexical_block is missing there so it should be created when needed. The testcase produces: 1 2 Tests on Fedora: compat-gcc-34-c++-3.4.6-9.x86_64 has no DW_TAG_imported_module there at all. gcc-4.3.2-3.x86_64 and gcc-4.1.2-33.x86_64 produce the output below. 16f: Abbrev Number: 5 (DW_TAG_subprogram) 70 DW_AT_external: 1 71 DW_AT_name: (indirect string, offset: 0x7f): main 75 DW_AT_decl_file : 1 76 DW_AT_decl_line : 13 77 DW_AT_type: 0x57 7b DW_AT_low_pc : 0x4005ac 83 DW_AT_high_pc : 0x4005fc 8b DW_AT_frame_base : 0x0 (location list) 8f DW_AT_sibling : 0xf2 293: Abbrev Number: 6 (DW_TAG_imported_module) 94 DW_AT_decl_file : 1 95 DW_AT_decl_line : 19 96 DW_AT_import : 0xf2 [Abbrev Number: 11 (DW_TAG_namespace)] 29a: Abbrev Number: 6 (DW_TAG_imported_module) 9b DW_AT_decl_file : 1 9c DW_AT_decl_line : 27 9d DW_AT_import : 0x10e [Abbrev Number: 11 (DW_TAG_namespace)] 2a1: Abbrev Number: 7 (DW_TAG_variable) a2 DW_AT_name: x a4 DW_AT_decl_file : 1 a5 DW_AT_decl_line : 15 a6 DW_AT_type: 0x57 aa DW_AT_location: 2 byte block: 91 64 (DW_OP_fbreg: -28) 2ad: Abbrev Number: 8 (DW_TAG_lexical_block) ae DW_AT_low_pc : 0x4005b4 b6 DW_AT_high_pc : 0x4005d2 be DW_AT_sibling : 0xd1 3c2: Abbrev Number: 9 (DW_TAG_variable) c3 DW_AT_name: (indirect string, offset: 0x32): block_create c7 DW_AT_decl_file : 1 c8 DW_AT_decl_line : 18 c9 DW_AT_type: 0x57 cd DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24) 2d1: Abbrev Number: 10 (DW_TAG_lexical_block) d2 DW_AT_low_pc : 0x4005d2 da DW_AT_high_pc : 0x4005f0 3e2: Abbrev Number: 9 (DW_TAG_variable) e3 DW_AT_name: (indirect string, offset: 0x32): block_create e7 DW_AT_decl_file : 1 e8 DW_AT_decl_line : 26 e9 DW_AT_type: 0x57 ed DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20) -- Summary: DW_TAG_imported_module is not in its DW_TAG_lexical_block Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com GCC build triplet: x86_64-fedora-linux-gnu GCC host triplet: x86_64-fedora-linux-gnu GCC target triplet: x86_64-fedora-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-09-07 17:56 --- Created an attachment (id=16249) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16249action=view) Testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff
--- Comment #3 from jan dot kratochvil at redhat dot com 2008-08-18 08:24 --- The fix was posted at: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01857.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35998
[Bug debug/36690] New: .debug_line first line is behind the first instruction
So far -O0 code could be safely debugged. With 4.3.1 and HEAD if you `break
func' in GDB the breakpoint can be missed despite the function got executed.
The line number info is wrong and as GCC does not produce prologue-end GDB is
using the line number information to skip the prologue.
Version-Release number of selected component (if applicable):
gcc-4.3.1-3.x86_64 (Fedora 9, broken)
Fedora 8 was correct: gcc-4.1.2-33.x86_64
Verified as broken on:
GNU C (GCC) version 4.4.0 20080701 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-9), GMP version
4.2.2, MPFR version 2.3.0-p2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Steps to Reproduce:
cat whilemain.c EOH
int i;
void func (void)
{
while (i == 1)
i = 0;
}
EOH
gcc -c -o whilemain.o whilemain.c -Wall -g
new broken gccs:
0040047c func:
int i;
void func (void)
{
40047c: 55 push %rbp
40047d: 48 89 e5mov%rsp,%rbp
400480: eb 0a jmp40048c func+0x10
while (i == 1)
i = 0;
400482: c7 05 fc 03 20 00 00movl $0x0,0x2003fc(%rip)#
600888 i
400489: 00 00 00
gcc-4.1.2-33.x86_64 (Fedora 8):
00400468 func:
int i;
void func (void)
{
400468: 55 push %rbp
400469: 48 89 e5mov%rsp,%rbp
while (i == 1)
40046c: eb 0a jmp400478 func+0x10
i = 0;
40046e: c7 05 fc 03 20 00 00movl $0x0,0x2003fc(%rip)#
600874 i
400475: 00 00 00
--
Summary: .debug_line first line is behind the first instruction
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690
[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff
--- Comment #2 from jan dot kratochvil at redhat dot com 2008-05-19 22:19 --- Created an attachment (id=15654) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15654action=view) GCC fix. Omit the whole attribute DW_AT_byte_size 0x. GCC testsuite ran on x86 and x86_64. GDB with this patch still produces invalid output on packed_tagged.exp but at least GDB does not crash. Sure the right way would be for GNAT to output the full DWARF2 expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35998
[Bug ada/35998] New: debug info invalid x86_64 DW_AT_byte_size 0xffffffff
The source:
procedure AdaFF is
type rec is
record
null;
end record;
X : rec;
begin
null;
end AdaFF;
produces output by:
$ rm -f adaff{,.o,.ali};gnatmake -g adaff.adb ;readelf -a --debug-dump adaff |
grep 'DW_AT_byte_size.*0x'
30b DW_AT_byte_size : 0x
1306: Abbrev Number: 20 (DW_TAG_structure_type)
307 DW_AT_name: (indirect string, offset: 0x3c8):
ada_main__main__TsehB___XUT
30b DW_AT_byte_size : 0x
30f DW_AT_decl_file : 1
310 DW_AT_decl_line : 105
311 DW_AT_sibling : 0x33b
A more complicated testcase
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.ada/packed_tagged/comp_bug.adb?rev=1.1cvsroot=src
crashes GDB eating all the memory on `print x' there.
--
Summary: debug info invalid x86_64 DW_AT_byte_size 0x
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC build triplet: x86_64-fedora-linux-gnu
GCC host triplet: x86_64-fedora-linux-gnu
GCC target triplet: x86_64-fedora-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35998
[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-04-21 12:40 --- Created an attachment (id=15503) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15503action=view) GDB workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35998
[Bug debug/33537] [4.1/4.2 regression] C++ arguments passed by invisible reference have wrong type
--- Comment #8 from jan dot kratochvil at redhat dot com 2007-11-01 17:37 --- ptype testcase is now in GDB as: gdb/testsuite/gdb.cp/arg-reference.exp (GDB still does not create the temporary copy during a call from GDB itself.) -- jan dot kratochvil at redhat dot com changed: What|Removed |Added CC||jan dot kratochvil at redhat ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33537
[Bug driver/30292] New: ICE on compiling .java by gcc(1)
Compilation by naive gcj usage results in ICE instead of a complaint. gcc-4.1.1, sources are the same in HEAD. $ gcc -o hello hello.java hello.java:1: internal compiler error: in uses_jv_markobj_p, at java/boehm.c:245 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. Without ICE the result would be still confusing: /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' /tmp/cc4WVJmk.o: In function `hello::main(JArrayjava::lang::String**)': hello.java:(.text+0x12): undefined reference to `_Jv_InitClass' hello.java:(.text+0x20): undefined reference to `java::lang::System::class$' hello.java:(.text+0x25): undefined reference to `_Jv_InitClass' hello.java:(.text+0x2c): undefined reference to `java::lang::System::out' /tmp/cc4WVJmk.o: In function `hello::hello()': hello.java:(.text+0x61): undefined reference to `java::lang::Object::Object()' /tmp/cc4WVJmk.o:(.data+0x80): undefined reference to `java::lang::Object::finalize()' /tmp/cc4WVJmk.o:(.data+0x88): undefined reference to `java::lang::Object::hashCode()' /tmp/cc4WVJmk.o:(.data+0x90): undefined reference to `java::lang::Object::equals(java::lang::Object*)' /tmp/cc4WVJmk.o:(.data+0x98): undefined reference to `java::lang::Object::toString()' /tmp/cc4WVJmk.o:(.data+0xa0): undefined reference to `java::lang::Object::clone()' /tmp/cc4WVJmk.o:(.data+0xa8): undefined reference to `java::lang::Object::throwNoSuchMethodError()' /tmp/cc4WVJmk.o:(.data+0x120): undefined reference to `vtable for java::lang::Class' /tmp/cc4WVJmk.o:(.data+0x148): undefined reference to `java::lang::Object::class$' /tmp/cc4WVJmk.o:(.eh_frame+0x12): undefined reference to `__gcj_personality_v0' collect2: ld returned 1 exit status Aware now the right way is to call: gcj -o hello --main=hello hello.java Attached patch errors out by: 'hello.java' must be compiled by the java gcj(1) driver but maybe some more spec-friendly solution would exist? Originally submitted as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208454 -- Summary: ICE on compiling .java by gcc(1) Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30292
[Bug driver/30292] ICE on compiling .java by gcc(1)
--- Comment #1 from jan dot kratochvil at redhat dot com 2006-12-26 05:38 --- Created an attachment (id=12843) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12843action=view) Fix using a new gcc.c variable. 4.1.1 testsuite results not affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30292
[Bug debug/29628] New: [32bit] unused argc/argv missing their DW_AT_location
`main' function (the function with specific prologue/epilogue) is missing DWARF
`DW_AT_location' for its `argc' and `argv' on 32-bit targets - only if these
arguments are never unused.
affected: x86_64-redhat-linux with -m32, i386-redhat-linux
not affected: x86_64-redhat-linux (-m64)
32-bit broken for: gcc-4.1.1, SVN snapshot 4.3.0
always works: gcc-3.4.6
It causes gdb(1) to hide the arguments during backtrace:
#0 main () at test.c:3
correct [i386]:
echo 'int main (int argc, char **argv) { return argc + (int) argv; }' main.c
;gcc -o main.o main.c -ggdb3;readelf -a --debug main.o|grep -A5 -w argc
incorrect [i386]:
echo 'int main (int argc, char **argv) { return 0; }' main.c ;gcc -o main.o
main.c -ggdb3;readelf -a --debug main.o|grep -A5 -w argc
correct (gcc-3.4.6):
1ee3: Abbrev Number: 33 (DW_TAG_subprogram)
DW_AT_sibling : f63
DW_AT_external: 1
DW_AT_name: main
DW_AT_decl_file : 46
DW_AT_decl_line : 267
DW_AT_prototyped : 1
DW_AT_type: c4
DW_AT_low_pc : 0x8048c0f
DW_AT_high_pc : 0x8048e26
DW_AT_frame_base : 616(location list)
2f02: Abbrev Number: 34 (DW_TAG_formal_parameter)
DW_AT_name: argc
DW_AT_decl_file : 46
DW_AT_decl_line : 267
DW_AT_type: c4
DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0)
2f12: Abbrev Number: 34 (DW_TAG_formal_parameter)
DW_AT_name: argv
DW_AT_decl_file : 46
DW_AT_decl_line : 267
DW_AT_type: f63
DW_AT_location: 2 byte block: 91 4 (DW_OP_fbreg: 4)
incorrect (gcc-4.1.1; appropriately for SVN snapshot - ~4.3.0):
164: Abbrev Number: 2 (DW_TAG_subprogram)
DW_AT_external: 1
DW_AT_name: main
DW_AT_decl_file : 1
DW_AT_decl_line : 2
DW_AT_prototyped : 1
DW_AT_type: 9b
DW_AT_low_pc : 0x8048324
DW_AT_high_pc : 0x804833d
DW_AT_frame_base : 0 (location list)
DW_AT_sibling : 9b
282: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: argc
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type: 9b
28e: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: argv
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type: a2
dwarf2.out.c mem_loc_descriptor () GET_CODE (rtl):
`case REG:' for i386 `argc'; it will fail on:
if (REGNO (rtl) FIRST_PSEUDO_REGISTER)
Checked there:
REGNO (rtl) == 61 /* Therefore pseudoreg. */
ORIGINAL_REGNO (rtl) == REGNO (rtl)
reg_renumber [61] == -1
On i386 with the arguments used it is fine as:
REGNO (rtl) == 1 /* Therefore hard register. */
On x86_64 it goes the `case PLUS:' way, not `case REG:'.
Could you advice where to find the location information for pseudoregisters
there?
--
Summary: [32bit] unused argc/argv missing their DW_AT_location
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29628
