This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix unused static symbols so they're not dropped by clang
- From: David Blaikie <dblaikie at gmail dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>, Eric Christopher <echristo at gmail dot com>
- Date: Fri, 11 Apr 2014 13:17:36 -0700
- Subject: Re: [patch] Fix unused static symbols so they're not dropped by clang
- Authentication-results: sourceware.org; auth=none
- References: <CAENS6Es8jHe=xp1Ca0WiZ2dg2JNqJ5JYLP89CCBGWWqPQ20rrQ at mail dot gmail dot com> <CADPb22TMi8w5aVL3eAUABhEa44_a-uh0jn9PPAvnbt4f=h2Cmw at mail dot gmail dot com>
On Fri, Apr 11, 2014 at 11:23 AM, Doug Evans <dje@google.com> wrote:
> On Thu, Apr 10, 2014 at 11:51 PM, David Blaikie <dblaikie@gmail.com> wrote:
>> Several tests used file-static functions and variables that were not
>> referenced by the code. Even at -O0, clang omits these entities at the
>> frontend so the tests fail.
>>
>> Since it doesn't look like these tests needed this functionality for
>> what they were testing, I've modified the variables/functions to
>> either be non-static, or marked them with __attribute__((used)).
>>
>> If it's preferred that I use the attribute more pervasively, rather
>> than just making the entities non-static, I can provide a patch for
>> that (or some other preferred solution). There's certainly precedent
>> for both (non-static entities and __attribute__((used)) in the
>> testsuite already and much more of the former than the latter).
>>
>> I have commit-after-review access, so just looking for sign-off here.
>
> Yikes.
>
> This is becoming more and more painful (not your fault of course!).
> I can imagine this being a never ending source of regressions.
>
> Does clang perchance have a -O0-and-yes-I-really-mean-O0 option?
Sort of. It does have -femit-all-decls, which, though poorly named,
causes clang to produce definitions for unused static entities and
even unused inline functions (which GCC doesn't do). I'm not sure
where we'd build in passing that flag from the GCC test suite. I'd
rather not have "clang passes the test suite only if you pass this
carefully chosen set of flags".