Bug 111660 - [ARM] isVFPPresent failed to detect vfp3
Summary: [ARM] isVFPPresent failed to detect vfp3
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Android Android
: P1 Critical
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 108645
  Show dependency treegraph
 
Reported: 2013-03-06 18:46 PST by linzj
Modified: 2019-06-09 19:11 PDT (History)
9 users (show)

See Also:


Attachments
change to vfp3 (597 bytes, application/octet-stream)
2013-03-20 18:54 PDT, linzj
no flags Details
patch (597 bytes, text/plain)
2013-03-20 18:56 PDT, linzj
no flags Details
patch (597 bytes, patch)
2013-03-20 19:22 PDT, linzj
msaboff: review+
commit-queue: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description linzj 2013-03-06 18:46:20 PST
Currently,the ARM family assemblers only support vfp3.But the function isVFPPresent just determines if we want to use vfp by checking HWCAP_VFP.
    int fd = open("/proc/self/auxv", O_RDONLY);
    if (fd > 0) {
        Elf32_auxv_t aux;
        while (read(fd, &aux, sizeof(Elf32_auxv_t))) {
            if (aux.a_type == AT_HWCAP) {
                close(fd);
                return aux.a_un.a_val & HWCAP_VFP;
            }
        }
        close(fd);
    }

This flag is on whenever the cpu has a vfp.But for armv5 family cpus,they just have vfp,not vfp3.So this will cause crash on these machines.
You should change HWCAP_VFP to HWCAP_VFPv3.
As the Linux kernel source arch/arm/vfp/vfpmodule.c descripts:

#ifdef CONFIG_VFPv3
		if (VFP_arch >= 2) {
			elf_hwcap |= HWCAP_VFPv3;

			/*
			 * Check for VFPv3 D16. CPUs in this configuration
			 * only have 16 x 64bit registers.
			 */
			if (((fmrx(MVFR0) & MVFR0_A_SIMD_MASK)) == 1)
				elf_hwcap |= HWCAP_VFPv3D16;
		}
#endif
Comment 1 linzj 2013-03-06 18:47:52 PST
you don't want me to submit a patch,because I can't checkout the whole svn trunk.I am in China,where is "protected" by the Great Fire Wall.
Comment 2 linzj 2013-03-19 23:39:25 PDT
well,seems a patch is mandatory here
Comment 3 linzj 2013-03-20 18:54:29 PDT
Created attachment 194165 [details]
change to vfp3
Comment 4 linzj 2013-03-20 18:56:36 PDT
Created attachment 194166 [details]
patch
Comment 5 linzj 2013-03-20 19:22:46 PDT
Created attachment 194167 [details]
patch
Comment 6 WebKit Commit Bot 2013-10-31 16:20:59 PDT
Comment on attachment 194167 [details]
patch

Rejecting attachment 194167 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.appspot.com', '--bot-id=webkit-cq-01', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 194167, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
/git.webkit.org/WebKit
   ed46a0b..9cd447a  master     -> origin/master
Partial-rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc ...
Currently at 158402 = ed46a0b8b39c279bd312a1751a6d47cd897fafb8
r158404 = 9cd447a9654a49da4bb567a48886a88e9c6a144b
Done rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/origin/master.

Full output: http://webkit-queues.appspot.com/results/19498010
Comment 7 Carlos Alberto Lopez Perez 2015-09-18 09:08:15 PDT
Hey. This patch has been sitting here for 2 years, with an r+ and just with a cq- because it don't has a changelog.


The patch still applies, should we commit it? It only needs a changelog.
Comment 8 Csaba Osztrogonác 2015-09-22 03:36:01 PDT
(In reply to comment #7)
> Hey. This patch has been sitting here for 2 years, with an r+ and just with
> a cq- because it don't has a changelog.
> 
> The patch still applies, should we commit it? It only needs a changelog.

I agree, let's add a changelog and commit it.