[llvm-debuginfo-analizer] Segfault when consuming `debuginfologicalview` library inside a project whose build-mode doesn't match LLVM's

[jalopezg-git]

SIGSEGV happens when using llvm::logicalview interfaces from a program built in Debug mode when LLVM was built in Release mode (or viceversa).

Description of the issue

The underlying cause is that the LVObject::ID data member (see https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/DebugInfo/LogicalView/Core/LVObject.h#L173) is only part of the class definition if !NDEBUG (i.e. in Debug builds).

Given that NDEBUG has a different definition during LLVM builld (matching LLVM's build mode), and a different one when the LVObject.h header is parsed in the downstream project (that consumes the debuginfologicalview library), this class definition may violate the ODR (due to different class layouts), resulting in visible crashes.

Reproducer

Not attaching a particular call stack (!important) / reproducer, as the problem could be potentially reproduced in any context that matches the explanation above.

Ideas for a fix

The following are just a couple of ideas for fixing this situation:

• Either we make ID an unconditional data member of the LVObject class
• Or... we extend llvm-config.h.cmake to incorporate a LLVM_BUILD_DEBUG PP macro that we could use in this case (and possibly other cases throughout LLVM)
• Or... we completely remove ID (and static GID), if it is not a useful debugging feature anymore

FYI, @CarlosAlbertoEnciso. I can take care of this in a PR, but first let's agree on any of the solutions above (or any other that we could come up with).

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Javier Lopez-Gomez (jalopezg-git)

SIGSEGV happens when using `llvm::logicalview` interfaces from a program built in Debug mode when LLVM was built in Release mode (or viceversa).

Description of the issue

The underlying cause is that the LVObject::ID data member (see https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/DebugInfo/LogicalView/Core/LVObject.h#L173) is only part of the class definition if !NDEBUG (i.e. in Debug builds).

Given that NDEBUG has a different definition during LLVM builld (matching LLVM's build mode), and a different one when the LVObject.h header is parsed in the downstream project (that consumes the debuginfologicalview library), this class definition may violate the ODR (due to different class layouts), resulting in visible crashes.

Reproducer

Not attaching a particular call stack (!important) / reproducer, as the problem could be potentially reproduced in any context that matches the explanation above.

Ideas for a fix

The following are just a couple of ideas for fixing this situation:

• Either we make ID an unconditional data member of the LVObject class
• Or... we extend llvm-config.h.cmake to incorporate a LLVM_BUILD_DEBUG PP macro that we could use in this case (and possibly other cases throughout LLVM)
• Or... we completely remove ID (and static GID), if it is not a useful debugging feature anymore

FYI, @CarlosAlbertoEnciso. I can take care of this in a PR, but first let's agree on any of the solutions above (or any other that we could come up with).

[CarlosAlbertoEnciso]

There is an option --attribute=id (Prints unique element ID), which includes the ID for the logical element and it is used to debug issues as you can put a breakpoint for that specific value. If the debug information does not change, that ID is the same, which is quite useful, during development.

Removing that functionality I don't think it is a good option.

[CarlosAlbertoEnciso]

Making ID an unconditional data member of the LVObject class, it will solve the issue, but it will increase the size, which I don't think is a desirable option, as ID is used only for debugging.

There is a PR #69160 that mention the size issue.

[CarlosAlbertoEnciso]

Or... we extend llvm-config.h.cmake to incorporate a LLVM_BUILD_DEBUG PP macro that we could use in this case (and possibly other cases throughout LLVM)

I guess this is the only option left.

[jalopezg-git]

Or... we extend llvm-config.h.cmake to incorporate a LLVM_BUILD_DEBUG PP macro that we could use in this case (and possibly other cases throughout LLVM)

I guess this is the only option left.

Agreed! I'll try to implement that this week (rest of the workload permitting).