Date: Sun, 14 Feb 2016 02:42:41 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 207175] projects/clang380-import for TARGET_ARCH=powerpc : clang 3.8.0 sometimes mishandles va_list overflow_arg_area vs. reg_save_area Message-ID: <bug-207175-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207175 Bug ID: 207175 Summary: projects/clang380-import for TARGET_ARCH=3Dpowerpc : clang 3.8.0 sometimes mishandles va_list overflow_arg_area vs. reg_save_area Product: Base System Version: 11.0-CURRENT Hardware: ppc OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: markmi@dsl-only.net in a projects/clang380-import context libxo code use by "ls -l -n /" gets a segmentation violation (SEGV) for TARGET_ARCH=3Dpowerpc for buildworld/installworld. The later simplified code reproduces the problem. The issue is complicated alignment/placement handling of va_list content between overflow_arg_area and reg_save_area that can happen when things lar= ger than 4 bytes in size are involved in the mix, such as intmax_t. It can be that only 4 bytes are left in reg_save_area when the next things = is, say, 8 bytes in size. The next thing after that can be 4 bytes in size --wh= ich place does the 4 byte item go and which is it extracted from? The code generated is not consistent with itself. The following short progr= am demonstrates the problem. #include <stdarg.h> // for va_list, va_start, va_arg, va_end #include <stdint.h> // for intmax_t intmax_t va_test (char *s, ...) { va_list vap; va_start(vap, s); char* t0 =3D va_arg(vap, char*); unsigned int o0 =3D va_arg(vap, unsigned int); int c0 =3D va_arg(vap, int); unsigned int u0 =3D va_arg(vap, unsigned int); int c1 =3D va_arg(vap, int); char * t1 =3D va_arg(vap, char*); intmax_t j0 =3D va_arg(vap, intmax_t); // This spans into overflow_arg_area. int c2 =3D va_arg(vap, int); // A copy was put in the=20 // overflow_arg_area because of the // above. // But this tries to extract f= rom the // last 4 bytes of the reg_save_area. // It does not increment the // overflow_arg_area position pointer // past the copy that is there. char * t2 =3D va_arg(vap, char*); // The lack of increment bef= ore makes // this extraction off by 4 by= tes. char t2fc =3D *t2; // <<< This gets SEGV. t2 actually got what should be // the c2 value. intmax_t j1 =3D va_arg(vap, intmax_t); va_end(vap); return (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+t2fc); // Avoid any optimize-away for lack of use. } int main(void) { char s[1025] =3D "test string for this"; char* t0 =3D s + 5; unsigned int o0 =3D 3; int c0 =3D 1; unsigned int u0 =3D 1; int c1 =3D 3; char * t1 =3D s + 12; intmax_t j0 =3D 314159265358979323; int c2 =3D 4; char * t2 =3D s + 16; intmax_t j1 =3D ~314159265358979323; intmax_t result =3D va_test(s,t0,o0,c0,u0,c1,t1,j0,c1,t2,j1); return (int) (result - (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+*t2)); // Avoid any optimize-away for lack of use. } Context: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r295351M: Sat Feb 6 16:27:58 PST 2016=20=20=20=20 markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERIC= vtsc-NODEBUG powerpc 1100097 1100097 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207175-8>