2013-12-01 10:16:35 +00:00
|
|
|
; RUN: llvm-dis < %s.bc| FileCheck %s
|
|
|
|
|
|
|
|
|
|
; linkage-types-3.2.ll.bc was generated by passing this file to llvm-as-3.2
|
|
|
|
|
; The test checks that LLVM does not silently misread linkage types of
|
|
|
|
|
; older bitcode files.
|
|
|
|
|
|
|
|
|
|
@common.var = common global i32 0
|
|
|
|
|
; CHECK: @common.var = common global i32 0
|
|
|
|
|
|
|
|
|
|
@appending.var = appending global [8 x i32] undef
|
|
|
|
|
; CHECK: @appending.var = appending global [8 x i32] undef
|
|
|
|
|
|
|
|
|
|
@extern_weak.var = extern_weak global i32
|
|
|
|
|
; CHECK: @extern_weak.var = extern_weak global i32
|
|
|
|
|
|
|
|
|
|
@private.var = private constant i32 0
|
|
|
|
|
; CHECK: @private.var = private constant i32 0
|
|
|
|
|
|
|
|
|
|
@linker_private.var = linker_private constant i32 0
|
Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00
|
|
|
; CHECK: @linker_private.var = private constant i32 0
|
2013-12-01 10:16:35 +00:00
|
|
|
|
|
|
|
|
@linker_private_weak.var = linker_private_weak constant i32 0
|
Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00
|
|
|
; CHECK: @linker_private_weak.var = private constant i32 0
|
2013-12-01 10:16:35 +00:00
|
|
|
|
|
|
|
|
@linker_private_weak_def_auto.var = linker_private_weak_def_auto constant i32 0
|
|
|
|
|
; CHECK: @linker_private_weak_def_auto.var = constant i32 0
|
|
|
|
|
|
|
|
|
|
@internal.var = internal constant i32 0
|
|
|
|
|
; CHECK: @internal.var = internal constant i32 0
|
|
|
|
|
|
|
|
|
|
@available_externally.var = available_externally constant i32 0
|
|
|
|
|
; CHECK: @available_externally.var = available_externally constant i32 0
|
|
|
|
|
|
|
|
|
|
@linkonce.var = linkonce constant i32 0
|
|
|
|
|
; CHECK: @linkonce.var = linkonce constant i32 0
|
|
|
|
|
|
|
|
|
|
@weak.var = weak constant i32 0
|
|
|
|
|
; CHECK: @weak.var = weak constant i32 0
|
|
|
|
|
|
|
|
|
|
@linkonce_odr.var = linkonce_odr constant i32 0
|
|
|
|
|
; CHECK: @linkonce_odr.var = linkonce_odr constant i32 0
|
|
|
|
|
|
|
|
|
|
@linkonce_odr_auto_hide.var = linkonce_odr_auto_hide constant i32 0
|
|
|
|
|
; CHECK: @linkonce_odr_auto_hide.var = constant i32 0
|
|
|
|
|
|
|
|
|
|
@external.var = external constant i32
|
|
|
|
|
; CHECK: @external.var = external constant i32
|
|
|
|
|
|
|
|
|
|
@dllexport.var = dllexport global i32 0
|
|
|
|
|
; CHECK: @dllexport.var = dllexport global i32 0
|
|
|
|
|
|
|
|
|
|
@dllimport.var = dllimport global i32
|
2014-01-14 15:22:47 +00:00
|
|
|
; CHECK: @dllimport.var = external dllimport global i32
|
2013-12-01 10:16:35 +00:00
|
|
|
|
|
|
|
|
define private void @private()
|
|
|
|
|
; CHECK: define private void @private
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define linker_private void @linker_private()
|
Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00
|
|
|
; CHECK: define private void @linker_private
|
2013-12-01 10:16:35 +00:00
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define linker_private_weak void @linker_private_weak()
|
Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00
|
|
|
; CHECK: define private void @linker_private_weak
|
2013-12-01 10:16:35 +00:00
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define linker_private_weak_def_auto void @linker_private_weak_def_auto()
|
|
|
|
|
; CHECK: define void @linker_private_weak_def_auto
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define internal void @internal()
|
|
|
|
|
; CHECK: define internal void @internal
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define available_externally void @available_externally()
|
|
|
|
|
; CHECK: define available_externally void @available_externally
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define linkonce void @linkonce()
|
|
|
|
|
; CHECK: define linkonce void @linkonce
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define weak void @weak()
|
|
|
|
|
; CHECK: define weak void @weak
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define linkonce_odr void @linkonce_odr()
|
|
|
|
|
; CHECK: define linkonce_odr void @linkonce_odr
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define linkonce_odr_auto_hide void @linkonce_odr_auto_hide()
|
|
|
|
|
; CHECK: define void @linkonce_odr_auto_hide
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
define external void @external()
|
|
|
|
|
; CHECK: define void @external
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
declare dllimport void @dllimport()
|
|
|
|
|
; CHECK: declare dllimport void @dllimport
|
|
|
|
|
|
|
|
|
|
define dllexport void @dllexport()
|
|
|
|
|
; CHECK: define dllexport void @dllexport()
|
|
|
|
|
{
|
|
|
|
|
ret void;
|
|
|
|
|
}
|
