http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
--- Comment #12 from Roland McGrath roland at redhat dot com 2010-10-05
19:24:56 UTC ---
Preprocessing stuff is probably best left to the -g3 info instead. cc1*
options make sense for DW_AT_producer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
--- Comment #10 from Roland McGrath roland at redhat dot com 2010-10-05
00:41:45 UTC ---
(In reply to comment #9)
Wouldn't be appropriate to append these flags also/instead to DW_AT_producer?
This way they get easily associated
--- Comment #8 from roland at redhat dot com 2010-08-13 08:08 ---
I think you've confused static variables (file scope) with C++ static members
(global scope). At any rate, this is not the place to get an education about
DWARF. You can use the dwarf-discuss mailing list for those
--- Comment #6 from roland at redhat dot com 2010-08-13 00:43 ---
DW_AT_external is correct for anything that has global linkage, whether or
not is defined. The absence of DW_AT_external, in a DIE that is not inside a
DW_TAG_subprogram scope, means that it has file linkage, like
--- Comment #4 from roland at redhat dot com 2010-08-11 23:52 ---
The compiler is being internally inconsistent here. It somtimes decides that
__attribute__((section (name))) means a name section in a COMDAT group, and
sometimes decides that it means just a plain name section. If it's
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45123
--- Comment #2 from roland at redhat dot com 2010-07-01 18:56 ---
The foo.part.0 DW_TAG_subprogram should get DW_AT_artificial.
IMHO that is equivalent to any other hypothetical case where
the compiler decides to spin a function where there was not
exactly one in the source. That fits
feature: check for unstable iterators
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland at redhat dot com
: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41439
--- Comment #3 from roland at redhat dot com 2009-06-23 20:27 ---
I don't understand. Why can't it print the source-level variable name?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40517
--- Comment #4 from roland at redhat dot com 2009-05-06 19:45 ---
Hmm. I am concerned by the idea of relocs for DWARF sections in final-linked
objects. That is a hassle that consumers have not had to handle before.
(AFAIK only consumers that handle ET_REL pseudo-final objects
--- Comment #3 from roland at redhat dot com 2007-08-06 19:19 ---
Absolute file names are a very bad idea. That makes for gratuitous differences
in builds due to the build or source directory name, i.e. unrepeatable builds.
The names in .debug_line and .debug_info are already expected
at gcc dot gnu dot org
ReportedBy: roland at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20043
--- Additional Comments From roland at redhat dot com 2005-02-17 23:16
---
Created an attachment (id=8218)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8218action=view)
small test case for this bug
3.4 likes this fine, but 4.0 does not.
--
http://gcc.gnu.org/bugzilla
14 matches
Mail list logo
