public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/63572] New: [5 Regression] ICF breaks user debugging experience
@ 2014-10-17  9:06 jakub at gcc dot gnu.org
  2014-10-17  9:20 ` [Bug debug/63572] " rguenth at gcc dot gnu.org
                   ` (22 more replies)
  0 siblings, 23 replies; 24+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-10-17  9:06 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

            Bug ID: 63572
           Summary: [5 Regression] ICF breaks user debugging experience
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: hubicka at gcc dot gnu.org, jakub at gcc dot gnu.org,
                    jakub at redhat dot com, mliska at suse dot cz, uros at gcc dot gnu.org
        Depends on: 63566
            Blocks: 63571

+++ This bug was initially created as a clone of Bug #63566 +++

On -O2 -g:
#define A \
  x += y * z; \
  y = (y << ((z & 2) + 1)) \
      ^ (y >> (__SIZEOF_INT__ * __CHAR_BIT__ - (z & 2) - 1)); \
  z *= 7;
#define B A A A A A A A A A A
#define C B B B B B B B B B B

static unsigned int
f1 (unsigned int x, unsigned int y, unsigned int z)
{
  C
  return x + y + z;
}

static unsigned int
f2 (unsigned int x, unsigned int y, unsigned int z)
{
  C
  return x + y + z;
}

__attribute__((noinline, noclone)) unsigned int
f3 (unsigned int x, unsigned int y, unsigned int z)
{
  return f1 (x, z, y) + 6;
}

__attribute__((noinline, noclone)) unsigned int
f4 (unsigned int x, unsigned int y, unsigned int z)
{
  return f2 (y, x, z) + 7;
}

__attribute__((noinline, noclone, used)) unsigned int
f5 (unsigned int x, unsigned int y, unsigned int z)
{
  return f1 (2 * x, z / 2, y + 3) - 6;
}

__attribute__((noinline, noclone, used)) unsigned int
f6 (unsigned int x, unsigned int y, unsigned int z)
{
  return f2 (y + 2, x | 1, z / 73) + 1;
}

int
main ()
{
  unsigned int x = f3 (0x173214, 0x182172, 0x9314);
  unsigned int y = f4 (0x173214, 0x182172, 0x9314);
#if __SIZEOF_INT__ * __CHAR_BIT__ == 32
  if (x != 0xd8e56f78U || y != 0x494c6699U)
    __builtin_abort ();
#endif
  return 0;
}

GCC emits incomplete DW_TAG_GNU_call_site DIEs for the f1 calls (that have been
optimized into ICF alias to f2) - no DW_AT_abstract_origin is provided,
and does not emit any DW_TAG_subprogram for f1 at all, just f2.
The question is how exactly do we want to emit the DW_TAG_subprogram for
icf_merged aliases.  Name/abstract origin/function type/names of arguments must
be it's own, I guess ICF will happily merge functions where the arguments have
e.g. different argument names, or different DECL_ABSTRACT_ORIGIN etc.
My question is mainly about DW_TAG_lexical_block/DW_TAG_inlined_subroutine, but
as even names of local variables can differ, or it can have different functions
inlined, I bet we need to fully populate DW_TAG_subprogram for the ICF aliases,
and have some mapping between BLOCKs in the ICF alias and BLOCKs in the kept
definition, so that we can reconstruct ranges.  Then, when we emit
DW_TAG_subprogram details for the kept original function definition when
finalizing its RTL, we also need to handle similarly all the ICF aliases.
Which is going to be non-fun.  Also, supposedly not just that, but we also need
a way to track multiple locations, not just blocks.
E.g. in one function, first 3 statements can have one location_t, say line 31,
and last 3 statements can have another location_t, say line 38.  Now, in
another
function ICF merged with that, the similar first 2 statements can have one
location_t, say line 47, the second 2 statements can have location_t line 49
and last 2 statements location_t line 53.  So, it might be impossible to create
e.g. a pointer_map from one set of locations to another set, we'd need to
analyze the correspondence between location_t's in between all the spots in the
function (gimple_location, EXPR_LOCATION) where they appear, and perhaps create
some artificial locations to make sure there is a 1-1 mapping between all ICF
merged functions.  Another problem is that we emit these days .debug_line using
.file/.loc directives and gas constructs that.  Not sure if we can have
multiple .debug_line proglets describing the same area of code (perhaps we need
some DWARF extension for that?) and if we had that possibility, the question is
how to emit it.
As for the DW_AT_abstract_origin of DW_TAG_GNU_call_site, that should probably
be just very easy, if there is a DIE for the ICF merged alias, supposedly it
will be found normally.

And, then we'll certainly need some GDB changes (and systemtap/elfutils etc.) - 
if some code range has multiple DW_TAG_subprogram DIEs covering that range,
e.g. if you want to put a breakpoint into a line in one of the functions


^ permalink raw reply	[flat|nested] 24+ messages in thread
end of thread, other threads:[~2023-07-07 10:30 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-17  9:06 [Bug debug/63572] New: [5 Regression] ICF breaks user debugging experience jakub at gcc dot gnu.org
2014-10-17  9:20 ` [Bug debug/63572] " rguenth at gcc dot gnu.org
2014-10-17  9:29 ` jakub at gcc dot gnu.org
2014-10-17  9:34 ` trippels at gcc dot gnu.org
2014-10-17  9:56 ` jakub at gcc dot gnu.org
2014-10-17 10:12 ` jakub at gcc dot gnu.org
2014-11-20 12:28 ` rguenth at gcc dot gnu.org
2015-02-09 15:43 ` marxin at gcc dot gnu.org
2015-02-09 21:58 ` jakub at gcc dot gnu.org
2015-03-02 17:49 ` hubicka at gcc dot gnu.org
2015-03-03 16:06 ` law at redhat dot com
2015-03-04 10:58 ` marxin at gcc dot gnu.org
2015-03-19 19:16 ` howarth at bromo dot med.uc.edu
2015-04-22 12:02 ` [Bug debug/63572] [5/6 " jakub at gcc dot gnu.org
2015-07-16  9:15 ` rguenth at gcc dot gnu.org
2020-11-23  7:53 ` [Bug debug/63572] [8/9/10/11 " hubicka at gcc dot gnu.org
2020-11-23 10:34 ` rguenth at gcc dot gnu.org
2020-11-23 10:36 ` jakub at gcc dot gnu.org
2021-05-14  9:47 ` [Bug debug/63572] [9/10/11/12 " jakub at gcc dot gnu.org
2021-06-01  8:06 ` rguenth at gcc dot gnu.org
2022-05-27  9:35 ` [Bug debug/63572] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:31 ` jakub at gcc dot gnu.org
2023-05-30 18:12 ` [Bug debug/63572] [10/11/12/13/14 " jakub at gcc dot gnu.org
2023-07-07 10:30 ` [Bug debug/63572] [11/12/13/14 " rguenth at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).