[Bug debug/23551] dwarf records for inlines appear incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #21 from Richard Biener --- There is PR103047 for that now.
[Bug debug/23551] dwarf records for inlines appear incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #20 from Eric Gallager --- (In reply to Matthew Fortune from comment #19) > I have one further case that may be worth adding to this ticket which > relates to the order of formal paramters emitted for an inlined subroutine > in debug info. > > GCC currently emits formal parameter DIEs for an inlined subroutine in > reverse order to the function's parameters. The DWARF spec is slightly > unclear in this area but does indicate that formal parameters must appear in > the same order as listed in the function prototype in both abstract and > concrete instances. > > One potential fix would be to change setup_one_parameter in tree-inline.c to > append each new VAR_DECL to the vars list instead of prepend them. There may > however be a more elegant approach by modifying the dwarf engine to detect > and re-order VAR_DECLs that relate to formal paramters and emit them in the > correct order. > > If this would be best as a separate ticket then I will open one. If a separate ticket would let us close this one, then yes, please open one.
[Bug debug/23551] dwarf records for inlines appear incomplete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551 Matthew Fortune mfortune at gmail dot com changed: What|Removed |Added CC||mfortune at gmail dot com --- Comment #19 from Matthew Fortune mfortune at gmail dot com 2011-04-21 14:07:35 UTC --- I have one further case that may be worth adding to this ticket which relates to the order of formal paramters emitted for an inlined subroutine in debug info. GCC currently emits formal parameter DIEs for an inlined subroutine in reverse order to the function's parameters. The DWARF spec is slightly unclear in this area but does indicate that formal parameters must appear in the same order as listed in the function prototype in both abstract and concrete instances. One potential fix would be to change setup_one_parameter in tree-inline.c to append each new VAR_DECL to the vars list instead of prepend them. There may however be a more elegant approach by modifying the dwarf engine to detect and re-order VAR_DECLs that relate to formal paramters and emit them in the correct order. If this would be best as a separate ticket then I will open one.
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #18 from aoliva at gcc dot gnu dot org 2007-07-09 19:24 --- Subject: Bug 23551 Author: aoliva Date: Mon Jul 9 19:24:23 2007 New Revision: 126492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126492 Log: Revert: 2007-07-06 Alexandre Oliva [EMAIL PROTECTED] PR debug/23551 * tree-ssa-copyrename.c (copy_rename_partition_coalesce): Disregard DECL_FROM_INLINE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-copyrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #17 from aoliva at gcc dot gnu dot org 2007-07-06 08:38 --- Subject: Bug 23551 Author: aoliva Date: Fri Jul 6 08:38:40 2007 New Revision: 126402 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126402 Log: PR debug/23551 * tree-ssa-copyrename.c (copy_rename_partition_coalesce): Disregard DECL_FROM_INLINE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-copyrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #16 from patchapp at dberlin dot org 2007-05-10 08:40 --- Subject: Bug number PR 23551 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00703.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #13 from fche at redhat dot com 2007-03-30 19:21 --- Case 1, is also too hard to fix as it would make us lose a lot of optimizations. If aoliva is correct in comment# 11, then some information is being lost that could be retained with some additional effort. That would make this bug other than invalid - at best a wontfix. -- fche at redhat dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-30 22:04
---
(In reply to comment #13)
If aoliva is correct in comment# 11, then some information is being lost
that could be retained with some additional effort. That would make this
bug other than invalid - at best a wontfix.
Lets look at this again. A simplified testcase without inlining:
int main ()
{
int x1 = 3;
{
int x = x1;
int i = 0;
for (i = 0; i x; ++i)
x += i;
return x;
}
}
This is basically the same as case 1 (though a constant instead of a call to
rand()), now do we want not to prop x1 into x? I say we always do want that
because otherwise we get an extra assignment. Plus this issue is not a
regression at all because the RTL level does the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #15 from fche at redhat dot com 2007-03-30 22:10 --- (In reply to comment #14) This is basically the same as case 1 (though a constant instead of a call to rand()), now do we want not to prop x1 into x? I say we always do want that because otherwise we get an extra assignment. I believe the idea was to emit extra DWARF for that copy-propagation, so as to treat the destination as a location-list-level alias of the source. The idea was not to inhibit the copy, just to document it, if that is sensible feasible. Plus this issue is not a regression at all because the RTL level does the same. (Did someone say it was?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-12-09 05:43 --- Case 2 was filed as PR 29792 and was declared invalid. Though we get currently: .uleb128 0x2# (DIE (0x25) DW_TAG_subprogram) .ascii foo\0 # DW_AT_name .byte 0x1 # DW_AT_decl_file (no-inlined-instance-record.c) .byte 0x2 # DW_AT_decl_line .byte 0x1 # DW_AT_prototyped .long 0x40# DW_AT_type .byte 0x3 # DW_AT_inline .long 0x40# DW_AT_sibling .uleb128 0x3# (DIE (0x36) DW_TAG_formal_parameter) .ascii x\0# DW_AT_name .byte 0x1 # DW_AT_decl_file (no-inlined-instance-record.c) .byte 0x1 # DW_AT_decl_line .long 0x40# DW_AT_type .byte 0x0 # end of children of DIE 0x25 Case 1, is also too hard to fix as it would make us lose a lot of optimizations. Really what GCC is producing is the best debugging you can get for these functions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #11 from aoliva at gcc dot gnu dot org 2006-11-01 06:37 --- Every inlined function starts with copying of argument initializers into the formal arguments. This makes such copies too suitable for SSA coalescing. It appears to me that it would be desirable to arrange for coalescing to somehow preserve information as to which variables have been coalesced, such that we can emit debug info for all coalesced variables, not just one of them. It sounds like a lot of work, though. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #10 from drow at gcc dot gnu dot org 2006-07-21 16:57 --- (In reply to comment #9) Case 1: There is no location info for the parameter x because it has been optimized away. Change the variable x in main to y to avoid ambiguity, compile with -fdump-tree-all, and look at the t27 and t29 dumps. In the t27 dump, the variable x is there and assigned to. In the t29 dump, the variable x is there, but no longer assigned to. Since it is no longer assigned to, we never allocate space for it, and hence no location attribute can be emitted. t29 is the copyrename dump file. If I compile with -fno-tree-copyrename, then I do get a location attribute for the parameter x in the inlined copy of foo. I don't think there is any bug here, but if there is, it would be in the tree copyrename pass, because there is no longer any useful parameter x when it is done. For the record, I encountered this problem today also (formals with no location information). Not a single argument had a location. Adding -fno-tree-copyrename fixed one (of about seven). In this case the variables are all used, mostly in non-trivial ways. My testcase was eval.c from GDB; the function evaluate_struct_tuple is inlined and debugging into it is quite hard. I'm working on improving this in GDB, but I can't improve where the compiler gives me nothing to work with. We already know that there are many similar problems in the tree optimizers; I'm just adding a data point. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-21 16:57:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #9 from wilson at gcc dot gnu dot org 2005-10-13 02:47 --- If you compile with -dA you will get readable DWARF2 debug info in the .s file. Case 1: There is no location info for the parameter x because it has been optimized away. Change the variable x in main to y to avoid ambiguity, compile with -fdump-tree-all, and look at the t27 and t29 dumps. In the t27 dump, the variable x is there and assigned to. In the t29 dump, the variable x is there, but no longer assigned to. Since it is no longer assigned to, we never allocate space for it, and hence no location attribute can be emitted. t29 is the copyrename dump file. If I compile with -fno-tree-copyrename, then I do get a location attribute for the parameter x in the inlined copy of foo. I don't think there is any bug here, but if there is, it would be in the tree copyrename pass, because there is no longer any useful parameter x when it is done. Case 2: Similar situation. The tree-ssa optimizers optimize away all trace of the inline foo function. By the time we get to the end of tree-ssa, all we have left is return 11. If you look in the .00.expand RTL dump, there are no line number notes or basic block notes associated with the inline foo. Since there is no inline foo, the debug output routines can't do anything here. I tried all of the -fno-tree-* options, but that doesn't help. This is apparently something that can't be turned off. If we really want debug info in this case, then the tree optimizers need to be modified to preserve lexical blocks and variables that originated in inlined functions. Not clear if this is desirable. Case 3: The difference here is that the tree optimizers are not able to completely optimize away the for loop in the inline function. Since we still have lines of code from the inline function, and stores to the parameter x, when the tree-ssa optimizers are done, we get the debug info you expect. Summary, these problems are all issues with tree optimizers destroying info when optimizing. Case 1 probably can't be fixed without hurting optimization, and hence is probably not feasible to fix it. A partial fix to Case 2 may be feasible, as the tree optimizers can perhaps be taught to keep the lexical block needed to represent the inline function foo. However, as in case 1, there will be no location attribute for x though, and this can't be fixed without disabling optimizations. Case 3 is the good example, there is nothing broken here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Additional Comments From graydon at redhat dot com 2005-08-24 20:52 --- Created an attachment (id=9577) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9577action=view) case 1, preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Additional Comments From graydon at redhat dot com 2005-08-24 20:52 --- Created an attachment (id=9578) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9578action=view) case 1, debug info dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Additional Comments From graydon at redhat dot com 2005-08-24 20:53 --- Created an attachment (id=9579) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9579action=view) case 2, preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Additional Comments From graydon at redhat dot com 2005-08-24 20:54 --- Created an attachment (id=9580) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9580action=view) case 2, debug info dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Additional Comments From graydon at redhat dot com 2005-08-24 20:54 --- Created an attachment (id=9581) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9581action=view) case 3, preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Additional Comments From graydon at redhat dot com 2005-08-24 20:55 --- Created an attachment (id=9582) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9582action=view) case 3, debug info dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Additional Comments From graydon at redhat dot com 2005-08-24 20:59 --- I should also point out that the compile flags for these cases were always -finline -O2 -g; I'm not sure how best to tell gcc to enable function-inlining (and nothing else), so this might be a mistake on my part. The cases are small enough that you can retry them on other flags and experiment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-24 21:08 --- A lot of these are all because we optimize stuff away. like the no-inlined-subroutine is because we just get return 11;. Others look like they are fixed in 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
