summaryrefslogtreecommitdiff
path: root/jpeg_nbits_table.c
AgeCommit message (Collapse)Author
2020-08-06Use hidden visibility for jpeg_nbits_table.Elliott Hughes
The non-upstream change to reuse one copy of jpeg_nbits_table rather than inline it with the two assembler routines that use it causes issues when generating a shared library with lld. Specifically: movzx edx, byte [GOTOFF(ebp, jpeg_nbits_table + ecx)] causes invalid relocations for jpeg_nbits_table. Normally if the target symbol is local, both movl $1, foo@GOTOFF(%ecx) and leal foo@GOTOFF(%eax), %eax will produce a R_386_GOTOFF relocation referencing a STT_SECTION local symbol. There is no issue for GNU ld or LLD. If the target symbol is global and preemptible LLD will report an error (GNU ld permissively allows it). The fix is to make jpeg_nbits_table hidden. Bug: http://b/162610242 Bug: https://issuetracker.google.com/135180511 Change-Id: I4fe75ca0069a047db05ab18eb36e94bf535878f5
2019-07-10Fix static const data duplicationChris Davis
While doing some size analysis of chrome binaries I noticed that the jpeg_nbits_table in the libjpeg_turbo codebase was being duplicated. A unique copy was in the jchuff.obj and jcphuff.obj resulting in an added 65k in .rdata in chrome.dll and chrome_child.dll. Declaring extern const in the header instead of static const and moving the definition to a new .c file fixes this so only one copy is referenced. Change-Id: I57ea19dd88951b3ba6b5f978bb53fc5377956c30