diff options
| author | George Rimar <grimar@accesssoftek.com> | 2018-07-18 11:56:53 +0000 |
|---|---|---|
| committer | George Rimar <grimar@accesssoftek.com> | 2018-07-18 11:56:53 +0000 |
| commit | 7d8e632e98d1d86f239947fb7af048c5d36d6571 (patch) | |
| tree | c6f239671d140471db300ae92d8342c281141b8f /llvm/lib/Bitcode/Reader | |
| parent | 1dbff9a4068e5a2860689ffb855f2dbd987ec9bf (diff) | |
| download | bcm5719-llvm-7d8e632e98d1d86f239947fb7af048c5d36d6571.tar.gz bcm5719-llvm-7d8e632e98d1d86f239947fb7af048c5d36d6571.zip | |
[ELF] - Stop silently producing a broken .eh_frame_hdr.
Currently, getFdePC() returns uint64_t. Its because the following
encodings might use 8 bytes: DW_EH_PE_absptr and DW_EH_PE_udata8.
But caller assigns returned value to uint32_t field:
https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L508
Value is used for building .eh_frame_hdr section.
We use DW_EH_PE_sdata4 encoding for building it at this moment:
https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L2545
And that means that an overflow issue might happen if
DW_EH_PE_absptr/DW_EH_PE_udata8 address encodings are present
in .eh_frame. In that case, before this patch, we silently would
truncate the address and produced broken .eh_frame_hdr section.
It would be not hard to support real 64-bit values for
DW_EH_PE_absptr/DW_EH_PE_udata8 encodings, but it is
unclear if it is usefull and if we should do it.
Since nobody faced/reported it, int this patch I only implement
a check to stop producing broken output silently for now.
llvm-svn: 337382
Diffstat (limited to 'llvm/lib/Bitcode/Reader')
0 files changed, 0 insertions, 0 deletions

