thr3ads.net - llvm dev - [llvm-dev] Errors linking with LLVM 5.0

If this information is useful, please help other people find it:
Share via:

Dibyendu Majumdar via llvm-dev

2017-Sep-25 20:22 UTC

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

Hi Martin

On 25 September 2017 at 21:13, Martin J. O'Riordan <MartinO at
theheart.ie> wrote:> Yes, if it is in the interface it would make more sense to have a null
implementation at the very least.  In my out-of-tree target, I also removed them
from the interface if the build was for Release to ensure that I got
compile-time errors to reveal other places I might have otherwise missed.
>
I assume you now need to create two LLVM builds - a debug build and a
release build. Then you need to link your own app's debug build /
release build to the right LLVM build.

On Windows this has to happen anyway due to dependencies on the C
libraries etc. but on Linux/Mac OSX I never had to until now build a
debug build of LLVM.

As I mentioned the real problem is that the client has no way of
knowing how LLVM was built - as there is no #define to flag the
missing dump() implementation either.

Regards
Dibyendu

>
> -----Original Message-----
> From: Dibyendu Majumdar [mailto:mobile at majumdar.org.uk]
> Sent: 25 September 2017 20:57
> To: Martin J. O'Riordan <MartinO at theheart.ie>
> Cc: LLVM Developers <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Errors linking with LLVM 5.0 - dump() missing
>
> Hi Martin,
>
>
> On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at
theheart.ie> wrote:
>> Are you building a Debug or Release version of the compiler?
>
> It seems that in Release builds of LLVM 5.0 the dump() implementation is
absent, although the method is available in the interface. This is plain wrong
in my view. If the dump() has to be removed then it should not be present in the
interface.
>
>>
>> I had similar problems a few days ago when I was migrating to v5.0, and
it turned out that I had calls to some of the dump routines that were not
guarded by either 'DEBUG(...)' or '#ifndef NDEBUG ... #endif'
and I was seeing the link failures with a Release build.  These had been there
since LLVM v3.1 and had never broken before.  There was some clean-up done in
the sources so that may of the 'dump' routines are enabled only for
Debug builds, and I fixed these (in my code) by adding these guards.
>>
>
> Well the problem is that there is no obvious way for a client to detect
whether the dump() implementation is available or not - as it does not depend
upon the Release/Debug build status of the client, but how LLVM 5.0 was
originally compiled. So the guards you have put are not really going to work
(that is my finding anyway).
>
> Regards
> Dibyendu
>
>>
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
>> Dibyendu Majumdar via llvm-dev
>> Sent: 25 September 2017 19:41
>> To: llvm-dev at lists.llvm.org
>> Subject: [llvm-dev] Errors linking with LLVM 5.0 - dump() missing
>>
>> Hi,
>>
>> I am finding that my project that previously successfully built with
versions 3.5 to 4.0 is now failing to link because of missing implementation for
dump(). Errors I get are:
>>
>> Undefined symbols for architecture x86_64:
>>
>>   "llvm::Type::dump() const", referenced from:
>>       ravi::LuaLLVMTypes::dump() in ravi_llvmtypes.cpp.o
>>       dump_content(lua_State*) in ravi_llvmluaapi.cpp.o
>>   "llvm::Value::dump() const", referenced from:
>>       dump_content(lua_State*) in ravi_llvmluaapi.cpp.o
>>   "llvm::Module::dump() const", referenced from:
>>
>> This appears to be a change that is not documented in the release notes
of 5.0. Please can someone describe what the change is and how I can detect
whether the dump() implementation is available or not?
>>
>> It also seems strange that dump() implementation was removed - surely
it would have been better ti stub it so that client code does not break?
>>
>> Regards
>> Dibyendu
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>

Don Hinton via llvm-dev

2017-Sep-25 21:29 UTC

head link

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

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 at 293359
91177308-0d34-0410-b5e6-96231b3b80d8

On Mon, Sep 25, 2017 at 1:22 PM, Dibyendu Majumdar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Martin
>
> On 25 September 2017 at 21:13, Martin J. O'Riordan <MartinO at
theheart.ie>
> wrote:
> > Yes, if it is in the interface it would make more sense to have a null
> implementation at the very least.  In my out-of-tree target, I also removed
> them from the interface if the build was for Release to ensure that I got
> compile-time errors to reveal other places I might have otherwise missed.
> >
>
> I assume you now need to create two LLVM builds - a debug build and a
> release build. Then you need to link your own app's debug build /
> release build to the right LLVM build.
>
> On Windows this has to happen anyway due to dependencies on the C
> libraries etc. but on Linux/Mac OSX I never had to until now build a
> debug build of LLVM.
>
> As I mentioned the real problem is that the client has no way of
> knowing how LLVM was built - as there is no #define to flag the
> missing dump() implementation either.
>
> Regards
> Dibyendu
>
>
> >
> > -----Original Message-----
> > From: Dibyendu Majumdar [mailto:mobile at majumdar.org.uk]
> > Sent: 25 September 2017 20:57
> > To: Martin J. O'Riordan <MartinO at theheart.ie>
> > Cc: LLVM Developers <llvm-dev at lists.llvm.org>
> > Subject: Re: [llvm-dev] Errors linking with LLVM 5.0 - dump() missing
> >
> > Hi Martin,
> >
> >
> > On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at
theheart.ie>
> wrote:
> >> Are you building a Debug or Release version of the compiler?
> >
> > It seems that in Release builds of LLVM 5.0 the dump() implementation
is
> absent, although the method is available in the interface. This is plain
> wrong in my view. If the dump() has to be removed then it should not be
> present in the interface.
> >
> >>
> >> I had similar problems a few days ago when I was migrating to
v5.0, and
> it turned out that I had calls to some of the dump routines that were not
> guarded by either 'DEBUG(...)' or '#ifndef NDEBUG ...
#endif' and I was
> seeing the link failures with a Release build.  These had been there since
> LLVM v3.1 and had never broken before.  There was some clean-up done in the
> sources so that may of the 'dump' routines are enabled only for
Debug
> builds, and I fixed these (in my code) by adding these guards.
> >>
> >
> > Well the problem is that there is no obvious way for a client to
detect
> whether the dump() implementation is available or not - as it does not
> depend upon the Release/Debug build status of the client, but how LLVM 5.0
> was originally compiled. So the guards you have put are not really going to
> work (that is my finding anyway).
> >
> > Regards
> > Dibyendu
> >
> >>
> >> -----Original Message-----
> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
> >> Dibyendu Majumdar via llvm-dev
> >> Sent: 25 September 2017 19:41
> >> To: llvm-dev at lists.llvm.org
> >> Subject: [llvm-dev] Errors linking with LLVM 5.0 - dump() missing
> >>
> >> Hi,
> >>
> >> I am finding that my project that previously successfully built
with
> versions 3.5 to 4.0 is now failing to link because of missing
> implementation for dump(). Errors I get are:
> >>
> >> Undefined symbols for architecture x86_64:
> >>
> >>   "llvm::Type::dump() const", referenced from:
> >>       ravi::LuaLLVMTypes::dump() in ravi_llvmtypes.cpp.o
> >>       dump_content(lua_State*) in ravi_llvmluaapi.cpp.o
> >>   "llvm::Value::dump() const", referenced from:
> >>       dump_content(lua_State*) in ravi_llvmluaapi.cpp.o
> >>   "llvm::Module::dump() const", referenced from:
> >>
> >> This appears to be a change that is not documented in the release
notes
> of 5.0. Please can someone describe what the change is and how I can detect
> whether the dump() implementation is available or not?
> >>
> >> It also seems strange that dump() implementation was removed -
surely
> it would have been better ti stub it so that client code does not break?
> >>
> >> Regards
> >> Dibyendu
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> 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
> 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/20170925/9ea33b03/attachment.html>

Dibyendu Majumdar via llvm-dev

2017-Sep-25 21:35 UTC

head link

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

Hi Don,

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 at 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

Reasonably Related Threads

Search for more seemingly similar threads

llvm dev - Sep 2017 - Errors linking with LLVM 5.0 - dump() missing

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

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

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

Reasonably Related Threads