[llvm-dev] Errors linking with LLVM 5.0 - dump() missing

[Dibyendu Majumdar via llvm-dev]

Hi Don,

On 25 September 2017 at 22:37, Don Hinton <hintonda at gmail.com> wrote:
> It'll work in release builds -- just rebuild llvm with LLVM_ENABLE_DUMP
> enabled.
>

That assumes one has control over the LLVM build options.


> On Mon, Sep 25, 2017 at 2:35 PM, Dibyendu Majumdar <mobile at majumdar.org.uk>
> wrote:
>>
>> On 25 September 2017 at 22:29, Don Hinton <hintonda at gmail.com> wrote:
>> > Thanks for reporting this.
>> >
>> > Looks like this one was missed -- the declaration should have been
>> > #ifdef'd
>> > away along with the definition.   A quick grep indicates there are a
>> > number
>> > of them that need to be fixed.
>> >
>> > Here's the original commit:
>> >
>> > commit 88d207542b618ca6054b24491ddd67f8ca397540
>> > Author: Matthias Braun <matze at braunis.de>
>> > Date:   Sat Jan 28 02:02:38 2017 +0000
>> >
>> >     Cleanup dump() functions.
>> >
>> >     We had various variants of defining dump() functions in LLVM.
>> > Normalize
>> >     them (this should just consistently implement the things discussed
>> > in
>> >     http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html
>> >
>> >     For reference:
>> >     - Public headers should just declare the dump() method but not use
>> >       LLVM_DUMP_METHOD or #if !defined(NDEBUG) ||
>> > defined(LLVM_ENABLE_DUMP)
>> >     - The definition of a dump method should look like this:
>> >       #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
>> >       LLVM_DUMP_METHOD void MyClass::dump() {
>> >         // print stuff to dbgs()...
>> >       }
>> >       #endif
>> >
>> >     git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293359
>> > 91177308-0d34-0410-b5e6-96231b3b80d8
>> >
>>
>> I would argue that removing dump() is the wrong thing to do even in
>> Release builds. I am using LLVM as a JIT. In this use case, it is
>> essential that one can inspect the IR at runtime. Perhaps in the AOT
>> case dump() is not used in release versions but that is not the case
>> in a JIT use case.
>>
>> Unless there is an equivalent alternative to dump() that is always
>> available.
>>
>>

Regards
Dibyendu