shadowstack implicitly assumes that SCS_SIZE is a multiple of page size.
Currently, SCS_SIZE is set to 8K. This assumption is broken on 16K
platforms.
Test: launch_cvd --use_16k
Bug: 253652966
Bug: 279808236
Change-Id: I1180cfba32c98d638e18615ccfdc369beb390ea7
This will, hopefully, reduce the number of flaky runs of this test.
Add skipping xml files for the notice file parser.
Bug: 280572235
Test: atest malloc_debug_system_tests
Change-Id: I6fb76287f55d0cff5b695dce09cc2b7a69b62874
This comes up now and then, and the different behavior with `adb shell`
in particular confuses people.
Bug: https://github.com/android/ndk/issues/1897
Test: N/A
Change-Id: I757fa6b6277610a139f326563d508fb9009dcb75
If folks want to use this instead of PAGE_SIZE, let's let the compiler
know that it doesn't need to be called more than once. Using "const"
rather than "pure" lets us cover more cases, and although this function
may need to check global state, it's _immutable_ global state, so it's
effectively "const".
Test: llvm-objdump -d
Change-Id: I0b13de79d44b57545258121df7cdd6490a9a5be1
The hidden pointer makes this trickier than the usual incantation, so
leave some copy & paste lying around for anyone trying to work this out.
Test: treehugger
Change-Id: I26e94bf7a74ce3e43de587edc52ab63e36d1d86b
This works (by reading /etc/localtime) on NetBSD, but not on Android
since we have no such file. Fix that by using our equivalent system
property instead.
Also s/time zone/timezone/ in documentation and comments. We've always
been inconsistent about this (as is upstream in code comments and
documentation) but it seems especially odd now we expose a _type_ that
spells it "timezone" to talk of "time zone" even as we're describing
that type and its associated functions.
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: I142995a3ab4deff1073a0aa9e63ce8eac850b93d
There are still some instances of
`__INTRODUCED_IN_NO_GUARD_FOR_NDK(26)` which we can get rid of after the
libc++ update, but we can get rid of the API level 21 instances right
now, since the NDK no longer supports older API levels anyway.
Test: treehugger
Change-Id: I243957f15b68d3d89ec8e15e2aefc45e8c294c31
This new mallopt cause statistics of the allocator to be printed in
the log.
Add a stats print for jemalloc.
This is designed to be used as part of a dumpsys meminfo --XXXX
option so that it's easier to get information about apps that
have an unusual memory footprint.
Test: Unit tests pass.
Test: Ran on a device using jemalloc and verified log data.
Test: Ran on a device using scudo and verified log data.
Change-Id: I6fa44ce619c064b2596fbbb478c231994af94f4c
Investigation shows that the symbols that claimed to have been in 32-bit
builds one API level earlier than in 64-bit builds actually weren't ---
everything was actually API level 22. This patch fixes the libc.map.txt
to match reality, and then simplifies the __INTRODUCED_IN()
incantations.
Investigation also shows that we have a bunch of unused #defines, so
this patch removes the ones that don't correspond to functions we
actually expose.
Test: treehugger
Change-Id: I540dd0d1d9561cac17c55eb68a07bed58dd718fa
The NDK no longer supports API levels earlier than 21.
This *doesn't* include <ctype.h> because I have a separate change
rewriting that (that's blocked on the upcoming libc++ update).
Test: treehugger
Change-Id: I53e915f27011dfc0513e0c78d8799377e183ceca
* Rationale
The question often comes up of how to use multiple time zones in C code.
If you're single-threaded, you can just use setenv() to manipulate $TZ.
toybox does this, for example. But that's not thread-safe in two
distinct ways: firstly, getenv() is not thread-safe with respect to
modifications to the environment (and between the way putenv() is
specified and the existence of environ, it's not obvious how to fully
fix that), and secondly the _caller_ needs to ensure that no other
threads are using tzset() or any function that behaves "as if" tzset()
was called (which is neither easy to determine nor easy to ensure).
This isn't a bigger problem because most of the time the right answer
is to stop pretending that libc is at all suitable for any i18n, and
switch to icu4c instead. (The NDK icu4c headers do not include ucal_*,
so this is not a realistic option for most applications.)
But what if you're somewhere in between? Like the rust chrono library,
for example? What then?
Currently their "least worst" option is to reinvent the entire wheel and
read our tzdata files. Which isn't a great solution for anyone, for
obvious maintainability reasons.
So it's probably time we broke the catch-22 here and joined NetBSD in
offering a less broken API than standard C has for the last 40 years.
Sure, any would-be caller will have to have a separate "is this
Android?" and even "is this API level >= 35?" path, but that will fix
itself sometime in the 2030s when developers can just assume "yes, it
is", whereas if we keep putting off exposing anything, this problem
never gets solved.
(No-one's bothered to try to implement the std::chrono::time_zone
functionality in libc++ yet, but they'll face a similar problem if/when
they do.)
* Implementation
The good news is that tzcode already implements these functions, so
there's relatively little here.
I've chosen not to expose `struct state` because `struct __timezone_t`
makes for clearer error messages, given that compiler diagnostics will
show the underlying type name (`struct __timezone_t*`) rather than the
typedef name (`timezone_t`) that's used in calling code.
I've moved us over to FreeBSD's wcsftime() rather than keep the OpenBSD
one building --- I've long wanted to only have one implementation here,
and FreeBSD is already doing the "convert back and forth, calling the
non-wide function in the middle" dance that I'd hoped to get round to
doing myself someday. This should mean that our strftime() and
wcsftime() behaviors can't easily diverge in future, plus macOS/iOS are
mostly FreeBSD, so any bugs will likely be interoperable with the other
major mobile operating system, so there's something nice for everyone
there!
The FreeBSD wcsftime() implementation includes a wcsftime_l()
implementation, so that's one stub we can remove. The flip side of that
is that it uses mbsrtowcs_l() and wcsrtombs_l() which we didn't
previously have. So expose those as aliases of mbsrtowcs() and
wcsrtombs().
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: Iee1b9d763ead15eef3d2c33666b3403b68940c3c
wfN: Specifies that a following b, d, i, o, u, x, or X conversion specifier applies to a fastest minimum-width integer argument with a specific width where N is a positive decimal integer with no leading zeros (the argument will have been promoted according to the integer promotions, but its value shall be converted to the unpromoted type); or that a following n conversion specifier applies to a pointer to a fastest minimum-width integer type argument with a width of N bits. All fastest minimum-width integer types (7.22.1.3) defined in the header <stdint.h> shall be supported. Other supported values of N are implementation-defined.
Bug: b/271903607
Test: adb shell
Change-Id: Iaa1f6d87251144de0b763672ca93f23272880ad1
Strictly the _doc comment_ is correct, but the names of the parameters
are the wrong way round. (Although iconv_open() follows the usual C
tradition of "destination first", iconv() itself doesn't, so these
functions are inherently confused/confusing.)
Bug: https://github.com/android/ndk/issues/1895
Test: N/A
Change-Id: Iafc9bd630ece1d3c55986b04bb9a99c477716530
To enable experiments with non-4KiB page sizes, introduce
an inline page_size() function that will either return the runtime
page size (if PAGE_SIZE is not 4096) or a constant 4096 (elsewhere).
This should ensure that there are no changes to the generated code on
unaffected platforms.
Test: source build/envsetup.sh
lunch aosp_cf_arm64_16k_phone-userdebug
m -j32 installclean
m -j32
Test: launch_cvd \
-kernel_path /path/to/out/android14-5.15/dist/Image \
-initramfs_path /path/to/out/android14-5.15/dist/initramfs.img \
-userdata_format=ext4
Bug: 277272383
Bug: 230790254
Change-Id: Ic0ed98b67f7c6b845804b90a4e16649f2fc94028
Although the existing annotations were strictly true (see
https://github.com/android/ndk/issues/1888#issuecomment-1581773348 for
the gory details), given the Play Store requirement that 32-bit code
must have a 64-bit version, it's not obviously useful to offer a
function for 32-bit before 64-bit.
Test: treehugger
Change-Id: I8ca11b874c26dfaa632690f510cb5409d95012e9
wN: Specifies that a following b, d, i, o, u, x, or X conversion specifier applies to an integer argument with a specific width where N is a positive decimal integer with no leading zeros (the argument will have been promoted according to the integer promotions, but its value shall be converted to the unpromoted type); or that a following n conversion specifier applies to a pointer to an integer type argument with a width of N bits. All minimum-width integer types (7.22.1.2) and exact-width integer types (7.22.1.1) defined in the header <stdint.h> shall be supported. Other supported values of N are implementation-defined.
Bug: b/271903607
Test: adb shell
Change-Id: I595fd2ac7bc40d9fb7f1935b39933a6cc068eeff
Discussion of this during my recent minor cleanup convinced me that we
should just remove __RENAME_LDBL. There's no obvious benefit to being
able to build something for 32-bit if you can't build the same code for
64-bit, given that most new hardware (and entire verticals such as Auto)
are 64-bit-only, and the Play Store requires any app with 32-bit code to
also ship 64-bit code.
Test: treehugger
Change-Id: I1c5503b968ca66925d7bd125bd3630c41ec1bfd0
Now the NDK doesn't support API levels below 21, we don't actually need
the different arm32 vs x86 annotations. In general we haven't been
removing this historical information because it might be interesting to
someone, and there's no real reason to remove it, but we've had
versioner bugs recently with these more complex cases.
Test: treehugger
Change-Id: I9460109a2648b9d05d7e21e397935293d3fea8eb
Add vector version mem* and str* functions and only build them when the
vector extension is enabled.
The original implementation comes from
https://github.com/sifive/sifive-libc, which we agree to contribute to
the Android Open Source Project.
Test: mma
Change-Id: I11b671a5bc571d7c783a657f272f282df7d16c29
Signed-off-by: Yun Hsiang <yun.hsiang@sifive.com>
Now the NDK doesn't support API levels below 21, we don't actually need
weird x86-specific annotations. In general we haven't been removing
this historical information because it might be interesting to someone,
and there's no real reason to remove it, but we've had versioner bugs
recently with these more complex cases.
Test: treehugger
Change-Id: Ia457bb338ecf55af8e319e411ec3bf48a03f3c03
Now the NDK doesn't support API levels below 21, we don't actually need
the different arm32 vs x86 annotations. In general we haven't been
removing this historical information because it might be interesting to
someone, and there's no real reason to remove it, but we've had
versioner bugs recently with these more complex cases.
Test: treehugger
Change-Id: Id9c9b8ecc01d232becd5dd8741509c104a8b6e19
C23 adds timegm(), gmtime_r(), and localtime_r(). We should remove the
"non-standard" text for timegm(), and while I'm here, let's just
document everything in this file.
Test: treehugger
Change-Id: Ia44c1bd155c939f694f6f8138b9cb7503519522c
No actual effect on the code, but misleading and wrong. (The previous
change only fixed the argument types; I didn't notice that some of the
return types were wrong too.)
Test: treehugger
Change-Id: I1ee5c48e2652fd8cbf8178d5659e57f79e61898e
Neither is great, but "gp" seems actively misleading (and setjmp.S
says x3 every time, so we should be consistent if nothing else).
Bug: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/379
Test: treehugger
Change-Id: Ibccda74d4794caa770b82e7ba2e31ce7b645b83f
The only remaining differences between vfprintf.cpp and vfwprintf.cpp
after this are the wide/narrow conversions for %c, %m, and %s. I've used
"chars" and "bytes" for the named constants for the directions because
(a) I find -1 and 1 pretty confusing and (b) although "narrow" is the
obvious opposite of "wide", only Windows actually moved to wide
characters, so "narrow" (aka "multibyte", and probably "utf8") is the
default/normal case. Even though C confuses bytes and characters via its
`char` type, "bytes" versus "chars" seems like the appropriate
terminology (and it's what Java/Python use).
Also improve the swprintf tests assertion so failures are readable.
Test: treehugger
Change-Id: Ife8f70f65ec28d96058a7d68df353945524835d2
wprintf doesn't need this (and already only has the iov stuff because
the non-wide printf implementation needs it), but we can further reduce
the diff between the two implementations by defining a no-op FLUSH() for
wide characters.
Test: treehugger
Change-Id: Ifefcb4b8474b086f995e2b0796f61558a19e2a42
Jens Gustedt suggested a better implementation last year on the musl
mailing list: https://www.openwall.com/lists/musl/2022/11/19/1
It means the constants are sparse, but in return it means we can add
future constants and they'll be backward compatible. (Sadly you'll need
to be on API level 35 before you can use anything but TIME_UTC.)
I doubt this will ever matter, because everyone should just stick to
clock_gettime()/clock_getres() anyway, and anyone who does have a
legitimate use for timespec_get() and timespec_getres() probably needs
to support non-Linux and so can't use any clocks that aren't in ISO C
anyway. But given that we don't _have_ to paint ourselves into a corner
here, we may as well take the opportunity to not do so.
Test: strace
Change-Id: I293d32fcbcf7f6703564dac0978ae2a10192a482
This is the one openlog() flag that toybox uses. We should probably try
to unify toybox's POSIX logger and Android-specific log at some point,
and this will help.
Also fix our behavior with an empty format string, noticed while adding
tests.
Test: treehugger
Test: adb shell logger -s foo
Change-Id: Ic027e78a460be3db83cc4c6f9946c9efa22be6e1
That lets us have idempotent #defines to reduce namespace pollution.
Bug: http://b/279405445
Test: treehugger
Change-Id: I00312cc8911025696cf0eea2d70e3219ab361613
wfN: Specifies that a following b, d, i, o, u, x, or X conversion specifier applies to a fastest minimum-width integer argument with a specific width where N is a positive decimal integer with no leading zeros (the argument will have been promoted according to the integer promotions, but its value shall be converted to the unpromoted type); or that a following n conversion specifier applies to a pointer to a fastest minimum-width integer type argument with a width of N bits. All fastest minimum-width integer types (7.22.1.3) defined in the header <stdint.h> shall be supported. Other supported values of N are implementation-defined.
Bug: b/271903607
Test: adb shell
Change-Id: Ida36d5a50af2a46fd04cb5fe039793d8872f9f3b
Although this breaks job control in several shells (including mksh),
this has been broken since the initial commit and no-one's noticed until
now.
Bug: https://github.com/android/ndk/issues/1878
Test: treehugger
Change-Id: Id7c4805965c5e5847db99b57df1af13355adcc22
57b8fc957a
changes the way overflows are tracked: now compiler builtins
are used instead of manual arithmetics. But as int_fast32_t on
64-bit Android takes 8 bytes, new logic behaves differently.
See time_test.cpp changes for more details.
Changes were applied using following commands:
1) Checkout tzcode repo
2) Prepare patches for all tzcode file using
git diff 2022a 2023a -- <file-name> > <file-name-patch>
3) Apply these patches to files in bionic using
patch -p1 <file-name> <file-name-patch>
Bug: 279742606
Test: CtsBionicTestCases
Test: CtsLibcoreTestCases
Test: CtsLibcoreOjTestCases
Test: atest toybox-tests
Change-Id: I7772a90538b8185bdd2f4be6e9d1740c95509d6c
The original wording implies that memory tagging can be disabled
per thread. That is not really possible, and doesn't happen. Instead,
this option only turns off some of the memory tagging initialization.
Leave this slightly vague since it's possible this might change
in the future.
Bug: 272383932
Test: NA
Change-Id: I6333f16175edb52a38aadfc67ce7c9ce76113e59
When annotating the netinet directory aosp/2552567, we realize the
argment s for vsnprintf family can be null only if the buffer size is 0.
So we correct them and add some tests to verify our assumption.
Bugs: b/245972273
Test: adb shell
Change-Id: I51063286272be0daee0d7c1453a374b1f5674481
Nothing to see here --- you'll want to keep using POSIX clock_gettime()
and clock_getres() instead. But portable code might use this eventually,
and it's trivial, so let's add it anyway.
(The whole "zero as an error return" precluding the direct use of
Linux's CLOCK_ constants is what really makes this a terrible API ---
we're going to have to add explicit translation any time they add a
new base.)
Test: treehugger
Change-Id: Iddb6cbe67b67b2b10fdd8b5ee654896d23deee47
Fix the uapi import script to look at the riscv/asm/ directory too, and
re-run it to add the missing SYS_riscv_* entry (there's only this one)
to glibc-syscalls.h.
Test: treehugger
Change-Id: Ie52c6ca1943c05bb615932174e49e7fb79725a7b
wN: Specifies that a following b, d, i, o, u, x, or X
conversion specifier applies to an integer argument with
a specific width where N is a positive decimal integer with
no leading zeros
Bug: b/271903607
Test: adb shell
Change-Id: I688f6cefeb2e5c8325b007a59935a46f4116ac29
This reverts commit fe2907c133.
Reason for revert: Breaks bionic-unit-tests b/278795547. Since the original mixed build change is being reverted for now (aosp/2547450), fe2907c133 is not needed immediately
Change-Id: I2deb06a38322bf8296d4721c840f06f35b757177
Contrary to the old comment, POSIX says nothing about whether or not
tmpfile() respects $TMPDIR, and it's significantly more useful on
Android if it does (because there's no shared /tmp that everyone can
write to).
Bug: https://issuetracker.google.com/36991167
Test: treehugger
Change-Id: I3cc45adff167420f100c8ed1c63cba1ea67e9f70
bp2build will generate the stub targets only if versions is not empty.
Test: b query //bionic/libc:* | grep libc_hwasan_stub_libs-current
Change-Id: Iac905497ae4955a44b7b29e2d29a2c702c86da8e
This mode instructs the linker to search for libraries in hwasan
subdirectories of all library search paths. This is set up to contain a
hwasan-enabled copy of libc, which is needed for HWASan programs to
operate. There are two ways this mode can be enabled:
* for native binaries, by using the linker_hwasan64 symlink as its
interpreter
* for apps: by setting the LD_HWASAN environment variable in wrap.sh
Bug: 276930343
Change-Id: I0f4117a50091616f26947fbe37a28ee573b97ad0
We want to give back a useful callee-saved general purpose
register (x18) that was only "chosen" because it was what llvm
allowed for historical reasons. gp is a better choice because it's
effectively unused otherwise anyway.
Unfortunately, that means we need extra space in jmp_buf (which I've
reserved in an earlier change, e7b3b8b467),
so let's rearrange the entries in jmp_buf to match their order in the
register file.
Bug: https://github.com/google/android-riscv64/issues/72
Bug: http://b/277909695
Test: treehugger
Change-Id: Ia629409a894c1a83d2052885702bbdd895c758e1
Bazel doesn't like it when modules produce files with the same name
as the module itself, and gives warnings.
Rename either the module or file in this case so that the file has
an extension and the module doesn't.
Bug: 198619163
Test: m nothing
Change-Id: Ic4592b06f575496ffd54ac75cb4d682118b29d93
If we switch from x18 to gp for shadow call stack, we're going to need
another slot in jmp_buf. We'll need this even for hardware shadow call
stacks too.
While I'm here, and because this is likely my last chance, let's just
round this up to 32 for safety. musl and glibc only have the minimum
needed (which I think means they'll need an ABI break to support SCS
unless they just use a callee-saved general purpose register), but since
we can't do ABI breaks after we ship, let's play it safe.
Bug: https://github.com/google/android-riscv64/issues/72
Test: treehugger
Change-Id: I60661fb7a308c900bfd08c9361f51919b798c005
The recent header nullability additions and the corresponding source
cleanup made me notice that we're missing a couple of actions that most
of the other implementations have. They've also been added to the _next_
revision of POSIX, unchanged except for the removal of the `_np` suffix.
They're trivial to implement, the testing is quite simple too, and
if they're going to be in POSIX soon, having them accessible in older
versions of Android via __RENAME() seems useful. (No-one else has shipped
the POSIX names yet.)
Bug: http://b/152414297
Test: treehugger
Change-Id: I0d2a1e47fbd2e826cff9c45038928aa1b6fcce59
Now <utmpx.h> isn't any more useful on Android than <utmp.h> is, but it
is POSIX, and -- importantly -- we can implement it with just a header
file, so code can use it on every existing API level.
macOS does indeed only have the <utmpx.h> functions (although it does
still have the <utmp.h> header!), so potentially portable code might
want <utmpx.h> on Android. (glibc/musl both have both headers.)
Bug: https://github.com/landley/toybox/pull/213
Test: treehugger
Change-Id: Iaa88167708182009a63e2e1a15f11186b251ed02
All the other architectures are already polluting the namespace with
`struct ucontext`, so make riscv64 match for source compatibility with
other Android code. (Code _should_ be using the POSIX `ucontext_t`, but
ART in particular had a lot of `struct ucontext`, and although I'll
clean that up separately, if there's some in our tree, there's probably
a lot more out there in the wild.)
Test: treehugger
Change-Id: Id0e4e97e660d7d60e792cd2462ddb9788d4772d7
We're going to dereference a null pointer if you pass one instead of a
pointer to a path, but at the moment (because of implementation sharing
between the different file actions) we won't do it until the last
minute, in the child itself. Let's crash as soon as you make the mistake
instead, to make debugging a lot easier.
Test: treehugger
Change-Id: I987d2700ba05b9867a936ebe770224259376633f
We don't really need <linux/compiler.h> and <linux/compiler_types.h>. We
already have a mechanism to remove unused macros, so let's do that. We
don't currently have a way to remove unused #includes, so we still need
<linux/compiler.h> and <linux/compiler_types.h> files (but I've clarified
the comments in them).
I've kept the empty definitions of `__user` and `__force` for source
compatibility. (We had one security test at least that was assuming
a kernel struct definition will "just work".)
Bug: http://b/262917450
Test: treehugger
Change-Id: Iacbbbc1aeef9a4fac52dabd7811ab875cc267d4f
Move the "is there a comparator?" check into the sole caller, to match
the "is there a filter?" check. Remove the unnecessary (and unlikely)
pre-sort "is the array empty?" check.
Test: treehugger
Change-Id: I8bd461380420dce4a8bc05ef5fe3511b26347d7c
No idea if this will be the actual API level or not, but that's all
the more reason to abstract it away early...
Bug: None
Test: None
Change-Id: I8a17bb42dbb08a6e760427514af8331e7dc9b549
Since it doesn't matter if these calls take a little longer than
before, use the more thorough but slightly longer purge mechanism.
Test: Unit tests pass.
Change-Id: Ifab7166a9682a13231746b78717d52673d13be1b
The strerror_buf is way too large, so instead of using a separate
buffer for just this string, reuse the already existing buffer.
Increase the buffer size to cover the maximum errno string.
Add a unit test to verify that none of the errno values are cut off
in the async_safe_format_buffer function when passing %m.
Bug: 274474681
Test: New unit test passes.
Test: Changing the buffer to a small value and verify that the test fails.
Change-Id: I4cb4652709582a8a6b958e12de5d923ec950e6b6
Use __memcpy_chk assembly to replace the implementation of c functions, which can reduce the use of instructions
Test: llvm-objdump
Change-Id: I5d75601626dc997626f6173d53af301183a64004
Signed-off-by: caowencheng <caowencheng@eswincomputing.com>
As of https://reviews.llvm.org/D143769, binaries (with -fsanitize=memtag-*)
have DT_AARCH64_MEMTAG_* dynamic entries, as per the AArch64 MemtagABI.
Android uses an OS-specific ELF note for MTE config, but we should
migrate to the new thing (while preserving backwards compatibility).
Without actually doing the migration right now, just handle these new
entries. Otherwise, you get a whole bunch of logspam about the
unrecognised dynamic entries.
Bug: 274032544
Test: Build android, don't get logspam.
Change-Id: I5c8b59f77a0058e5b93335e269d558a5014f2260
The buffer filled in by strerror_r needs to stay in scope while
it is pointed to by str.
Bug: 273807460
Change-Id: I494ca8b8aca2b28ec2f0f3da72d845db99633553
This is a new mallopt option that will force purge absolutely
everything no matter how long it takes to purge.
Wrote a unit test for the new mallopt, and added a test to help
verify that new mallopt parameters do not conflict with each other.
Modified some benchmarks to use this new parameter so that we can
get better RSS data.
Added a new M_PURGE_ALL benchmark.
Bug: 243851006
Test: All unit tests pass.
Test: Ran changed benchmarks.
Change-Id: I1b46a5e6253538108e052d11ee46fd513568adec
clang-r487747 added stack protector capability to check noreturn calls.
This caused the system to boot loop. Turn off the new capabilities as a
temporary workaround.
Test: build and boot
Change-Id: I62c912619dfdd2384672d504ce5d52330bf2a102
If the 'j' command is used here,it cannot always be called.
The 'tail' command is used here, let the compiler decide
which instruction to use,when the call distance is less
than 1M, it will be compiled into 'j' command, and when
the distance is greater than 1M, it will be compiled
into 'aupic' and 'jr' command.
Test: llvm-objdump -d
Change-Id: I53d8aa7f54b9c4c96fce491487dcba7b63348219
Signed-off-by: caowencheng <caowencheng@eswincomputing.com>
