[Bug testsuite/25684] New: gdb testing with gcc -flto

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25684

            Bug ID: 25684
           Summary: gdb testing with gcc -flto
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

gcc supports -flto , an optimization which changes how debug info is generated.

In order to properly support this in gdb, it would be good to be able to test
some sort of unix/-flto flavour.

A problem here is that -flto -O0 still optimizes, which causes lots of FAILs.
F.i., verification of printing a variable fails because it has been privatized,
and has a "static" prefix which is not expected.

There's an open gcc PR for this: 51663 - "Desirable/undesirable elimination of
unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program" (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663 ).

Another failure cause I've seen is lack of being able to set a breakpoint at a
specific line, because that line's not there in the line number program (f.i.
in gdb.base/branch-to-self.exp). I'm not sure if that's the same gcc PR, or yet
something else.

Either way, test results with
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects look like:
...
                === gdb Summary ===

# of expected passes            72442
# of unexpected failures        4964
# of unexpected successes       19
# of expected failures          144
# of unknown successes          1
# of known failures             52
# of unresolved testcases       54
# of untested testcases         35
# of unsupported tests          78
...

We can compare results without and with patch to verify gdb patches that affect
lto handling.

However, currently this takes a long time due to timeouts. For me, testing time
increases from 30m to 3h due to these timeouts.

I've filed one of these timeouts as a separate issue ( PR25667 - "If
gdb.linespec/cpcompletion.exp fails, it's too slow",
https://sourceware.org/bugzilla/show_bug.cgi?id=25667 ).

Looking at the number of timeouts (testing with the proposed fix for PR25667):
...
$ grep -c "(timeout)" master/gdb.sum 
373
...
we have roughly an hour worth of timing out.

Looking at the timeouts, there are not too many sources:
...
$ grep ^FAIL:.*timeout gdb.sum | awk '{print $2}' | sort -u
gdb.base/branch-to-self.exp:
gdb.base/completion.exp:
gdb.base/gdb-sigterm.exp:
gdb.base/paginate-bg-execution.exp:
gdb.cp/cpcompletion.exp:
gdb.fortran/info-modules.exp:
gdb.linespec/cpcompletion.exp:
gdb.linespec/cpls-abi-tag.exp:
gdb.linespec/cpls-ops.exp:
gdb.linespec/explicit.exp:
gdb.linespec/linespec.exp:
gdb.mi/user-selected-context-sync.exp:
...

So we might be able to improve the testing time by preventing timeouts in these
test-cases.

Note: we might be able to improve target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects by explictly disabling
some optimizations that happen to reduce FAILs.

Note: gcc version matters. I've just tested a patch using this scheme, only to
realize that I used gcc 7, which does support flto, but not the early/late
debug scheme, which means testing did not trigger the patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.