llvm dev - Nov 2019 - Inconsistency in llvm-link and opt (MCStreamer)

Hi Folks,

My colleague and I ran into this problem when we tried to run our custom
analysis on the latest kernel. We used llvm-link to generate the final
bitcode and when we ran opt we got the error
"LLVM ERROR: invalid symbol redefinition".

After digging around we figured out that because the symbols defined by
inline assembly directives "module asm" are not checked if they are
duplicated when llvm-link links the bitcode files.

However, in MCStreamer, the program will abort because it find out there
are actually multiple symbols defined in that final bitcode file.

I am wondering is it a good idea to have this inconsistency behavior, here
<https://llvm.org/docs/LangRef.html#module-level-inline-assembly> the
document says it is intended for llvm-link to simply concatenate symbols
defined by inline asm without checking duplication, as it does for other
normally defined symbols. The problem is having this erroneous bitcode,
other tools in the pipeline can't work correctly since there are duplicated
symbols.

Ideally, llvm-link should've pointed out the redefinition error, but since
it is a documented behavior there must be some reason. I am wondering what
that could be?

In addition, could you provide some suggestion on how we can resolve this
without manually editing the erroneous bc file?

Thanks in advance,
Eric

PS: if you want to reproduce the behavior, I attached the 2 bitcode files
that can be linked successfully by llvm-link but if you try to use opt to
parse it and generate a new bitcode, the program error out.

PPS: I am using llvm-9.0.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191107/531717ee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kobject-example.bc
Type: application/octet-stream
Size: 12188 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191107/531717ee/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kset-example.bc
Type: application/octet-stream
Size: 17712 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191107/531717ee/attachment-0001.obj>

> On Nov 7, 2019, at 15:10, Yaohui Chen via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi Folks,
> 
> My colleague and I ran into this problem when we tried to run our custom
analysis on the latest kernel. We used llvm-link to generate the final bitcode
and when we ran opt we got the error
> "LLVM ERROR: invalid symbol redefinition".
> 
> After digging around we figured out that because the symbols defined by
inline assembly directives "module asm" are not checked if they are
duplicated when llvm-link links the bitcode files.
> 
> However, in MCStreamer, the program will abort because it find out there
are actually multiple symbols defined in that final bitcode file.
> 
> I am wondering is it a good idea to have this inconsistency behavior, here
<https://llvm.org/docs/LangRef.html#module-level-inline-assembly> the
document says it is intended for llvm-link to simply concatenate symbols defined
by inline asm without checking duplication, as it does for other normally
defined symbols. The problem is having this erroneous bitcode, other tools in
the pipeline can't work correctly since there are duplicated symbols.
> 
> Ideally, llvm-link should've pointed out the redefinition error, but
since it is a documented behavior there must be some reason. I am wondering what
that could be?
LLVM doesn't really understand the semantics of an inline assembly string.
From its point of view it's just a string to expand and paste into the
generated code just before it runs the assembler. As a result, llvm-link
isn't aware that there's a symbol inside the inline assembly.
> In addition, could you provide some suggestion on how we can resolve this
without manually editing the erroneous bc file?
If the exact name doesn't really matter then you may be able to use ${:uid}
(http://llvm.org/docs/LangRef.html#inline-assembler-expressions
<http://llvm.org/docs/LangRef.html#inline-assembler-expressions>) to add a
unique number to each one. I don't know if that works in module-level
assembly though.
> Thanks in advance,
> Eric
> 
> PS: if you want to reproduce the behavior, I attached the 2 bitcode files
that can be linked successfully by llvm-link but if you try to use opt to parse
it and generate a new bitcode, the program error out.
> 
> PPS: I am using llvm-9.0.
>   
>
<kobject-example.bc><kset-example.bc>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20191111/8202ff73/attachment.html>