the spec required by std::sort and friends. Ordering things this way also dramatically simplifies the code as short-circuit ensures we can skip all of the negative tests. I've left one FIXME where we're establishing a fairly arbitrary ordering. Previously, the function compared all types as equal except for the ones it explicitly handled, but it didn't delegate correctly to the atomflags when doing so, and so it would fail to be a SWO. The two possible fixes are to stop comparing the atom flags entirely, or to establish some arbitrary ordering of the types. Since it was pure luck which ordering of unequal types we ended up with previously (the caller was std::sort, not std::stable_sort) I chose to make the ordering explicit and guaranteed. This seems like the best conservative approach as I suspect we would want to switch to stable_sort otherwise in order to have deterministic output. Differential Revision: http://reviews.llvm.org/D8266 llvm-svn: 231968
27 lines
974 B
Plaintext
27 lines
974 B
Plaintext
# Tests that the option --rosegment produces an output file with a separate
|
|
# segment created for read only data.
|
|
RUN: lld -flavor gnu -target x86_64 %p/Inputs/rodata.o -o %t1.elf \
|
|
RUN: --noinhibit-exec
|
|
RUN: lld -flavor gnu -target x86_64 %p/Inputs/rodata.o --rosegment -o %t2.elf \
|
|
RUN: --noinhibit-exec
|
|
RUN: llvm-readobj -program-headers %t1.elf | FileCheck %s -check-prefix=NORO-SEGMENT
|
|
RUN: llvm-readobj -program-headers %t2.elf | FileCheck %s -check-prefix=RO-SEGMENT
|
|
|
|
#NORO-SEGMENT: Type: PT_PHDR
|
|
#NORO-SEGMENT: Type: PT_INTERP
|
|
#NORO-SEGMENT: Type: PT_LOAD
|
|
#NORO-SEGMENT: Type: PT_LOAD
|
|
#NORO-SEGMENT: Type: PT_DYNAMIC
|
|
#NORO-SEGMENT: Type: PT_GNU_EH_FRAME
|
|
|
|
#RO-SEGMENT: Type: PT_PHDR
|
|
#RO-SEGMENT: Type: PT_INTERP
|
|
#RO-SEGMENT: Type: PT_LOAD
|
|
#RO-SEGMENT: Type: PT_LOAD
|
|
#RO-SEGMENT: Flags [
|
|
#RO-SEGMENT: PF_R (0x4)
|
|
#RO-SEGMENT: ]
|
|
#RO-SEGMENT: Type: PT_LOAD
|
|
#RO-SEGMENT: Type: PT_DYNAMIC
|
|
#RO-SEGMENT: Type: PT_GNU_EH_FRAME
|