From 70752818b006aa0a0758f076f7a0a24288e37676 Mon Sep 17 00:00:00 2001 From: Ian Lance Taylor Date: Thu, 3 Apr 2008 00:33:37 +0000 Subject: [PATCH] * TODO: New file. --- gold/ChangeLog | 4 ++++ gold/TODO | 26 ++++++++++++++++++++++++++ 2 files changed, 30 insertions(+) create mode 100644 gold/TODO diff --git a/gold/ChangeLog b/gold/ChangeLog index 7af52ff9a79..5bdf106c71e 100644 --- a/gold/ChangeLog +++ b/gold/ChangeLog @@ -1,3 +1,7 @@ +2008-04-02 Craig Silverstein + + * TODO: New file. + 2008-04-02 Ian Lance Taylor * fileread.cc (File_read::find_view): Add byteshift and vshifted diff --git a/gold/TODO b/gold/TODO new file mode 100644 index 00000000000..b85df9751b0 --- /dev/null +++ b/gold/TODO @@ -0,0 +1,26 @@ +Things that still need to be done: -*- Text -*- + + o - Performance + + All performance could be tuned, but one area that could be looked + at especially is performance with flags, particularly + --detect-odr-violations and --compress-debug-sections. + + o - Threads + + Why is the usertime when we run with threads the same (or almost + the same) as when we run without? Is it because threads spend most + of their time waiting on the same resources? On each other? + Something else? + + o - ODR false positives + + ODR false positives can happen when we optimize, since code in .h + files may be optimized in different ways in different compilation + units. It's possible we could fix this for real by looking at the + full debug info and using DW_TAG_inlined_subroutine in a clever way + to correct for inlining. But that would be very expensive, I + think. The easier solution is to recommend people only do + ODR-detection with -g0. + + o - Better testing -- 2.30.2