[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"

Mehdi Amini via llvm-dev
Mon, 10 Apr 2017 23:12:06 -0000

> On Apr 10, 2017, at 12:17 PM, Chris Bieneman <beanz at apple.com>
wrote:
>
> Presently several of our headers have definitions like:
>
> #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
>   void dump() const;
> #endif
>
> Would it make sense to modify the build system to define LLVM_ENABLE_DUMP
in config.h on debug builds?
>
> Then we could wrap dump methods just based on LLVM_ENABLE_DUMP instead of
two variables.

I missed this email earlier, but that totally makes sense to me (ideally with a
link/runtime check like the ABI_BREAKING_CHECK one).

Thanks,

—
Mehdi


>> On Apr 10, 2017, at 1:34 PM, Robinson, Paul via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>
>>
>>> -----Original Message-----
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Mehdi
>>> Amini via llvm-dev
>>> Sent: Sunday, April 09, 2017 2:26 PM
>>> To: Matthias Braun
>>> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>; jingu at codeplay.com <mailto:jingu at codeplay.com>
>>> Subject: Re: [llvm-dev] Question about LLVM Building Error with
"-
>>> DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
>>>
>>>
>>>> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev
<llvm-
>>> dev at lists.llvm.org <mailto:dev at lists.llvm.org>>
wrote:
>>>>
>>>> I think the idea is to keep NDEBUG out of headers when
possible. So I
>>> think this should better be something like:
>>>>
>>>> -#ifndef NDEBUG
>>>>  void dumpUses(unsigned RegNo) const;
>>>> -#endif
>>>>
>>>> to be inline with various other dumpers (like
MachineInstr::dump(),
>>> Pass::dump(), …)
>>>
>>> I’m fine with leaving methods there, but we need to be able to
compile-out
>>> fields in structure.
>>
>> Hmmm seems to me this has come up in the past, and somebody pointed out
>> that it prevents building a debug-mode front-end against a release-mode
LLVM.
>> (Why is that a valid use-case?  If I have an out-of-tree front end, and
>> especially one with a different license, I might well prefer to
download
>> only LLVM releases rather than keep up-to-date with a live tree that I
>> build myself.  IIRC we do not provide debug-mode downloads, therefore
>> anything that affects struct size/layout will break this use-case.)
>> --paulr
>>
>>>
>>> We already have ABI_BREAKING_CHECKS for instance to this end, the
naming
>>> isn’t completely in line with LLVM_ENABLE_DUMP but could be
unified.
>>>
>>> —
>>> Mehdi
>>>
>>>
>>>>
>>>> If that works for you please submit a patch to phabricator as
described
>>> in
http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch
<http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch>
>>>>
>>>> - Matthias
>>>>
>>>>> On Apr 6, 2017, at 7:38 AM, jingu at codeplay.com
<mailto:jingu at codeplay.com> via llvm-dev <llvm-
>>> dev at lists.llvm.org <mailto:dev at lists.llvm.org>>
wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I have tried to build llvm tip as following:
>>>>>
>>>>> cmake
-DCMAKE_CXX_FLAGS:STRING="-DLLVM_ENABLE_DUMP" -
>>> DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm
>>>>>
>>>>> After running 'make', I have got error messages
like below.
>>>>>
>>>>> llvm/lib/CodeGen/MachineRegisterInfo.cpp:462:67: error: no
‘void
>>> llvm::MachineRegisterInfo::dumpUses(unsigned int) const’ member
function
>>> declared in class ‘llvm::MachineRegisterInfo’
>>>>>
>>>>> llvm/lib/CodeGen/MachineScheduler.cpp:2331:57: error: no
‘void
>>> llvm::SchedBoundary::dumpScheduledState()’ member function declared
in
>>> class ‘llvm::SchedBoundary’
>>>>>
>>>>> ...
>>>>>
>>>>> It seems the "defined(LLVM_ENABLE_DUMP)" is
needed on several
>>> locations. How do you think about it? I have attached the diff file
about
>>> the locations for reference.  If I missed something, please let me
know.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JinGu Kang
>>>>>
>>>>>
<dump.diff>_______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170410/8952d9e1/attachment.html>