From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36239 invoked by alias); 23 Apr 2015 14:55:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 36219 invoked by uid 89); 23 Apr 2015 14:55:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-HELO: cvs.linux-mips.org Received: from eddie.linux-mips.org (HELO cvs.linux-mips.org) (148.251.95.138) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Apr 2015 14:55:19 +0000 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S27011514AbbDWOzPuFljO (ORCPT ); Thu, 23 Apr 2015 16:55:15 +0200 Date: Thu, 23 Apr 2015 14:55:00 -0000 From: "Maciej W. Rozycki" To: Petar Jovanovic cc: gcc-patches@gcc.gnu.org, Catherine_Moore@mentor.com, Matthew Fortune Subject: RE: [PATCH v3][MIPS] fix CRT_CALL_STATIC_FUNCTION macro In-Reply-To: <004301d07d12$ee45f5b0$cad1e110$@rt-rk.com> Message-ID: References: <005001d07c5a$8c9e9b90$a5dbd2b0$@rt-rk.com> <004301d07d12$ee45f5b0$cad1e110$@rt-rk.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01420.txt.bz2 On Wed, 22 Apr 2015, Petar Jovanovic wrote: > > I think this will best be > > reduced to a link-only test on bare iron, hoping for a link failure. > > I am not sure how we can reduce the test to a link failure (today), if > ld will not report an error (today). Me neither, offhand; hopefully someone is. > What exactly is wrong with the run time test as is in the last patch? Addresses like 0x10000000 or 0x0FF00000 are in the KUSEG kernel/user segment address space. They are mapped, that is translated through the TLB (the translation lookaside buffer, a small contents-addressed memory in the CPU that maps virtual addresses to physical ones). A TLB refill exception will trigger when such an address is used for a data access or an instruction fetch. A proper OS that implements virtual memory management will then handle it and use its page tables to refill the TLB and restart the faulting instruction that will usually succeed. Further exceptions may follow if e.g. the page has been marked absent and has to be pulled first from swap or from a file it has been mmap(2)ed from, or a copy-on-write page has been marked read-only and a copy needs to be made on the first write, etc. and the OS will handle them one by one. In a bare-iron environment there's usually no virtual memory management, so a TLB refill exception will result in a crash. Or a hang. Either way the test case will fail, and sometimes it will take long to time out. On the MIPS processor bare-iron programs will usually use unmapped addresses that have a fixed association with corresponding physical addresses and as such bypass the TLB. These will usually be ones in the KSEG0 (on 32-bit targets) or the XKPHYS (on 64-bit targets) kernel segments. For example 0x90000000 and 0x8FF00000 would be KSEG0 addresses suitable for your test case, that map to 0x10000000 and 0x0FFF0000 physical addresses respectively. As the mapping is fixed, you need to make sure there is actual memory across the 256MB boundary spanned here. Also these addresses will not work for a user program[*], such as under Linux, as the kernel segments, as the name implies, can only be referred to in the kernel mode. Consequently an Address Error exception will trigger and the kernel will kill the user process that misbehaved. If such addresses are used to lay out an executable, in ELF file's segment headers, then the kernel will refuse to run it in the first place. I hope you find this explanation satisfactory, however if you still find anything unclear or have any other questions or concerns, then please shout. BTW, can you please change 0x0FF00000 to 0x0FFF0000 or suchlike to avoid making the executable larger than absolutely necessary, or is 0x0FF00000 actually required due to section/segment alignment constraints? You didn't mention in your patch description why you picked up these particular addresses. [*] Recently addresses in the 32-bit 0x80000000-0xbfffffff address space have been enabled for user access with the use of the EVA (enhanced virtual addressing) mode. This mode is not universally supported across hardware or OS software though and is still an exception rather than a norm so we cannot assume it will be available. > As of ld issue you have mentioned, it has been reported - see BZ#18297 > [1]. Thanks, I've added myself as a watcher and will see what I can do about it. Unless someone else beats me to it, that is. Maciej