summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/lang/cpp/overloaded-functions/main.cpp
diff options
context:
space:
mode:
authorRafael Espindola <rafael.espindola@gmail.com>2015-11-18 06:02:15 +0000
committerRafael Espindola <rafael.espindola@gmail.com>2015-11-18 06:02:15 +0000
commit449711cb366962c841e7c6b9c1271484d2965c54 (patch)
tree431bb6aa43feca0657676cb7f1aceb0521050d0f /lldb/packages/Python/lldbsuite/test/lang/cpp/overloaded-functions/main.cpp
parente113b5e9afeda18d249aca75d473350b94fcda5f (diff)
downloadbcm5719-llvm-449711cb366962c841e7c6b9c1271484d2965c54.tar.gz
bcm5719-llvm-449711cb366962c841e7c6b9c1271484d2965c54.zip
Stop producing .data.rel sections.
If a section is rw, it is irrelevant if the dynamic linker will write to it or not. It looks like llvm implemented this because gcc was doing it. It looks like gcc implemented this in the hope that it would put all the relocated items close together and speed up the dynamic linker. There are two problem with this: * It doesn't work. Both bfd and gold will map .data.rel to .data and concatenate the input sections in the order they are seen. * If we want a feature like that, it can be implemented directly in the linker since it knowns where the dynamic relocations are. llvm-svn: 253436
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/lang/cpp/overloaded-functions/main.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud