Fixes for Europe/Tiraspol (Moldova) and all four Ukrainian zones.
Also show the MD5 of the downloaded data, for comparison against the MD5
given in the announcement mails. (There's a plan to move to proper signing,
but that's not implemented on their end yet.)
Change-Id: I845e6f125c0f54298abadc643adfeca2eff4827a
Modify the dynamic linker so that executables can be loaded
at locations other than 0x00000000.
Modify crtbegin* so that non-PIC compilant "thumb interwork
veneers" are not created by the linker.
Bug: 5323301
Change-Id: Iece0272e2b708c79034f302c20160e1fe9029588
Without this change strcmp size is zero (not set), and it gets
ignored by Valgrind. Changes to memcpy and atexit don't affect the
generated binary in any way.
Change-Id: I05818cb5951f75901dc8c0eef02807a2e83a9231
http://code.google.com/p/android/issues/detail?id=19276
GCC would remove inline asm due to lack of knowledge
of FPU register changes.
Change-Id: I9f9e8623fa6580843b7cd8178439ace8c2db2d51
Signed-off-by: Mark D Horn <mark.d.horn@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Author: Jingwei Zhang <jingwei.zhang@intel.com>
AI_ADDRCONFIG is currently implemented by trying to connect
to well-known addresses in order to see if IPv4 and/or IPv6
connectivity is available.
In some cases (e.g., walled gardens with no global
connectivity) both probes can fail. If this happens,
query for both IPv4 and IPv6 addresses instead of doing
nothing and failing the query.
Bug: 5284168
Change-Id: I4e3a69ea86fb6d839a6bd31236b98da81e5cbf45
Change Ife82a8d8 broke IPv6 on wifi. Change I4e3a69ea is
an alternate approach that does not require any framework
changes.
Bug: 5284168
Change-Id: Ib52614be3875a2ae2eaedd1be265f90e506eda41
Instead of checking for IPv4 or IPv6 connectivity, try using pid-specific
hints the framework has left for us.
bug:5284168
Change-Id: Id64d48db3900865a7d58ada8309870c63d6eab12
vfork() would not save the registers that the parent would expect
to have restored after execl() completed.
Specially that execl() would call execve() underneath, further messing
up the stack of the parent.
To avoid that, we fork() for now. Later we will revisit and cleanup
vfork()+execve() to actually have vfork() store all the register
that the parent expects to see, and not those left by execve().
In the original code, looking at the registers just before the call to
popen(), and after the call showed that r7 would get clobbered.
This would leave the caller with an invalid pointer, leading to all
kinds of data corruptions.
execve() is simpler that execl() in this case.
Bug: 5336252
Change-Id: I3bf718c0bb4c0439f6f2753f153cdea14175be9c
