Bug: 16408818
These targets are no longer in use, since we have a proper way to create both
32-bit and 64-bit host libraries in a single build now.
Change-Id: Icd09f795acd220de5b5e956a8d8e1b4ab4864fa9
* Read out system properties with same syntax as SystemProperties.java
* Also adds unit test suite to validate correctness of properties
* Also fixes buffer overrun in property_get
(cherry picked from commit d4507e9246)
Change-Id: Ifd42911f93e17da09e6ff1298e8875e02f3b6608
Port libcutils memset16/32 assembly SSE2 optimizations to x86_64
architecture. Ensures the same performance on 64-bit arch.
Change-Id: I874a71a884c0d28a152933ddff9cb886c9a6e99e
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
Not seeding this each call should help reduce collisions when multiple
threads are calling ashmem_create_region. Also cleaned up code by
deleting gotos, and making formatting consistent.
Bug: 15394258
Change-Id: Iafdaea57b2317e0eb7c40d7b5595c523814fd88c
In some condition, some of FS would set disable_roll_forward option.
In this case, when we do power off or reboot, the power down progress
would stuck at android_reboot for 360 sec.
The reason is, remount_ro_done function check key word "rw" to determine
whether all the read-write FS has been remounted as read-only FS.
Unfortunately, it takes disable_roll_forward as a rw flag too by
mistake, so the check would always fail, until reach 360 sec threshold.
The patch would match "rw," from mount options, this can avoid the issue
successfully.
Change-Id: I409f9dc88c9ee5cf049615ea9dcccaf195b6bc5a
Signed-off-by: Hong-Mei Li <a21834@motorola.com>
After a disconnect, the initial blocking connect takes
a long time to return, while subsequent calls return
quicks. Switch to a non-blocking connect to make the
re-connect time more consistent and faster overall.
Change-Id: I21d02b22a8eb9a457c2f1fa95eb17894d5612ccd
Signed-off-by: Ken Lierman <ken.lierman@windriver.com>
Reviewed-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Reviewed-by: Jovanovic, Radivoje <radivoje.jovanovic@intel.com>
Reviewed-by: Boie, Andrew P <andrew.p.boie@intel.com>
Bionic needs to re-raise various signals, which means the si_code
debuggerd sees has been clobbered. If bionic sends us the original
si_code value, we can use that instead of the one we see when the
ptrace the crashed process' siginfo.
Change-Id: If116a6bc667d55a6fb39b74f96673292af4e4c8c
Adds Silvermont specific cache sizes for memset16/32 SSE optimization.
Change-Id: Ib5ea086d57544e74ac384ee1ef516b8511392f70
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
A normal sequence of calls is as follows:
str_parms_create_str, str_parms_add_str, str_parms_destroy.
In some cases the destroy caused double free.
str_parms_add_str will clone the input and send it to hashmapPut
for storage. If hashmapPut did not store the strings it will raise
errno = ENOMEM and leave caller with ownership of the strings.
In any of these cases it will be safe to destroy the str_parms.
But what if it wasn't hashmapPut that said NOMEM? What if there
was a stale NOMEM already before a successful hashmapPut?
In that case the strings will be successfully added to the list
(if new), but when str_parms_add_str sees the NOMEM it will free
them anyway, leaving dangling pointers in the str_parms!!
It is the responsibility of the caller to clear errno before any
interesting call. This patch makes sure that str_parms_add_str
reacts only on errno emmitted from hashmapPut.
Change-Id: If87e4bcc482f09e1c66133d33517b152ebdac65f
We have benchmarking for memset in bionic itself, and a benchmarking
framework for other native benchmarking.
Change-Id: I241a288a96d3b2d37f3d51b04a519ac23f18a989
Eliminates various warnings from SELinux-related code.
Bug: 12587913
Change-Id: I28921f0ebd934324436609540d95ccef58552b64
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
str_parms_get_float did not return the output into
*val. Only output if returning with no error. Audit
shows no internal users of this library function
(cherry picked from commit 8e71ddeac0)
Change-Id: I14a3f08a098072a159dd93f85ead36b3f445816f
The kernel headers are already in the include path, and manually
adding them again will break on a multiarch build, where the
kernel headers may be different for each arch.
Change-Id: Ib13d96543f2c97b1b487a46e1748ceb2c5724169
When initiating a manual dump, the abort_msg_address parameter is random
garbage. Initialize this value to 0.
Change-Id: I9ba817ee6104f47cfcb2b746bfa6f02a259c86d7
__reboot is hidden for 64-bits and should be hidden on others
Change-Id: Ib6435269aac7fa726e49cc02f8f76d2be2875bc6
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Elliott Hughes