From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104724 invoked by alias); 6 Jul 2017 04:42:56 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 104704 invoked by uid 89); 6 Jul 2017 04:42:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:9188614, H*f:sk:9188614, expert, Best X-HELO: esa1.microchip.iphmx.com Received: from Unknown (HELO esa1.microchip.iphmx.com) (68.232.147.91) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Jul 2017 04:42:53 +0000 Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa1.microchip.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2017 21:42:45 -0700 Received: from jaguar.microchip.com (10.10.76.4) by chn-sv-exch07.mchp-main.com (10.10.76.108) with Microsoft SMTP Server id 14.3.352.0; Wed, 5 Jul 2017 21:42:44 -0700 References: <20170705083621.GB30902@calimero.vinschen.de> <3194afba-248d-a10e-1393-91bfbe744d43@nadler.com> <91886142-6bd1-54cd-6bc7-3f00569a3e60@nadler.com> User-agent: mu4e 0.9.18; emacs 25.2.1 From: Senthil Kumar Selvaraj To: Dave Nadler CC: Tamar Christina , "newlib@sourceware.org" , nd Subject: Re: [Newlib][libgloss]ARM - semihosting use of __end__symbol in crt0.S In-Reply-To: <91886142-6bd1-54cd-6bc7-3f00569a3e60@nadler.com> Date: Thu, 06 Jul 2017 04:42:00 -0000 Message-ID: <87bmoy5g9s.fsf@microchip.com> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017/txt/msg00572.txt.bz2 Dave Nadler writes: > Thanks Tamar - but, what is the heap base address _used_ for in semihosting? > IIRC, the sbrk system call implementation in libnosys uses it, not sure about rdimon. Regards Senthil > The heap storage is allocated starting during early start-up; > so hopefully it is not trying to use this memory... > > Thanks! > Best Regards, Dave > > On 7/5/2017 11:16 AM, Tamar Christina wrote: >> Hi Dave, >> >> The use of __end__ relates to the semihosting call SYS_HEAPINFO. >> Likely the link originally pointed tohttp://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471f/Bacbefaa.html. >> >> Basically at the startup r0 will contain the given 4 byte structure, where the first entry is the heap_base. >> If this is 0 it means the system was unable to calculate it. >> __end__ is then used as a fall back for this. >> The reason __end__ is used instead of __bss_end___ has to do with the alignment requirements. >> >> The same question was asked on the bug-fix patch that introduced it: >> http://newlib.sourceware.narkive.com/bcyUamAh/rfa-libgloss-arm-handle-zero-heap-base-from-semihosting >> >> I am not completely certain, but this seems to indicate that not all of semihosting is supported on systems with multiple stacks. >> >> Cheers, >> Tamar >> ________________________________________ >> From: Dave Nadler >> Sent: Wednesday, July 5, 2017 2:32:18 PM >> To: Tamar Christina;newlib@sourceware.org >> Cc: nd >> Subject: [Newlib][libgloss]ARM - semihosting use of __end__symbol in crt0.S >> >> Hi Tamar - Perhaps as you are working on ARM crt0 and semihosting, you >> can help >> with a question regarding crt0's use of the symbol __end__ for semihosting. >> I read the code but I'm not expert at ARM assembly and do not understand >> what __end__ is being used for, and the comments do not explain the >> intent/purpose... >> >> I am concerned that there is an assumption within semihosting about >> available memory or memory boundaries that may be incorrect in systems where >> heap and stack are not contiguous, for example embedded systems with multiple >> stacks. >> >> I asked the question on stack exchange but (surprise) didn't get any >> useful response: >> https://stackoverflow.com/questions/44853442/meaning-of-gnu-symbol-end-especially-arm-embedded >> >> Thanks in advance for any clarification, >> Best Regards, Dave