[PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

[PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

[Tamar Christina]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

Hi All, 


This patch adds the general build system changes needed 
in order to compile and create the new libraries for Semihosting v2.

This works by creating a similar recursive make target that is modeled
after the existing multilib makefile config-ml.in.

OK for master?

PS. I do not have commit rights so if OK can someone apply for me?

Thanks,
Tamar


libgloss/
2017-07-03  Tamar Christina  <tamar.christina@arm.com>

	* multi-build.in (multi-do): New.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: semihosting-patch-1.patch --]
[-- Type: text/x-patch; name="semihosting-patch-1.patch", Size: 2178 bytes --]

diff --git a/libgloss/multi-build.in b/libgloss/multi-build.in
new file mode 100644
index 0000000000000000000000000000000000000000..0bd12cfd95769d9ec193936b2781bc5cc4db7809
--- /dev/null
+++ b/libgloss/multi-build.in
@@ -0,0 +1,61 @@
+PWD_COMMAND=$${PWDCMD-pwd}
+
+# FIXME: There should be an @-sign in front of the `if'.
+# Leave out until this is tested a bit more.
+multi-do:
+	if [ -z "$(MULTIDIRS)" ]; then \
+	  true; \
+	else \
+	  rootpre=`${PWD_COMMAND}`/; export rootpre; \
+	  srcrootpre=`cd $(srcdir); ${PWD_COMMAND}`/; export srcrootpre; \
+	  lib=`echo "$${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$$,\1,'`; export lib; \
+	  compiler="$(CC)"; \
+	  for dir in $(MULTIDIRS); do \
+	    if [ "$${dir}" = "." ]; then \
+	      true; \
+	    else \
+	      destpre=`echo $${rootpre}/$${dir}`/; export destpre; \
+	      if ! test -d $${destpre} ; then \
+		mkdir -p $${destpre}; \
+		cp config.status $${destpre}; \
+		cd $${destpre}; \
+		$(SHELL) config.status; \
+		sed -e "s:^MULTIDIRS\s*+=.*$$:MULTIDIRS = :" \
+		    -e "s:^MULTILIBNAME\s*=.*$$:MULTILIBNAME = MULTIDIR_$${dir}_NAME:" \
+		    -e "s:^MULTI_FLAGS_FOR_TARGET\s*=.*$$:MULTI_FLAGS_FOR_TARGET = MULTIDIR_$${dir}_FLAGS:" \
+		    -e "s:^objdir\s*=.*$$:objdir = ..:" \
+			Makefile > Makefile.tem; \
+		rm -f Makefile; \
+		mv Makefile.tem Makefile; \
+	      else \
+		cd $${destpre}; \
+	      fi; \
+	      if ($(MAKE) $(FLAGS_TO_PASS) \
+		    CFLAGS="$(CFLAGS)" \
+		    CCASFLAGS="$(CCASFLAGS)" \
+		    FCFLAGS="$(FCFLAGS)" \
+		    FFLAGS="$(FFLAGS)" \
+		    ADAFLAGS="$(ADAFLAGS)" \
+		    prefix="$(prefix)" \
+		    exec_prefix="$(exec_prefix)" \
+		    GCJFLAGS="$(GCJFLAGS)" \
+		    GOCFLAGS="$(GOCFLAGS)" \
+		    CXXFLAGS="$(CXXFLAGS)" \
+		    LIBCFLAGS="$(LIBCFLAGS)" \
+		    LIBCXXFLAGS="$(LIBCXXFLAGS)" \
+		    LDFLAGS="$(LDFLAGS)" \
+		    MULTIFLAGS="" \
+		    DESTDIR="" \
+		    SOURCE="${srcdir}/" \
+		    INSTALL="$(INSTALL)" \
+		    INSTALL_DATA="$(INSTALL_DATA)" \
+		    INSTALL_PROGRAM="$(INSTALL_PROGRAM)" \
+		    INSTALL_SCRIPT="$(INSTALL_SCRIPT)" \
+		    $(DO)); then \
+		cd $${rootpre}; \
+	      else \
+		exit 1; \
+	      fi; \
+	    fi; \
+	  done; \
+	fi

Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

Hi Tamar,

On Jul  3 16:53, Tamar Christina wrote:
> Hi All, 
> 
> 
> This patch adds the general build system changes needed 
> in order to compile and create the new libraries for Semihosting v2.
> 
> This works by creating a similar recursive make target that is modeled
> after the existing multilib makefile config-ml.in.
> 
> OK for master?
> 
> PS. I do not have commit rights so if OK can someone apply for me?
> 
> Thanks,
> Tamar
> 
> 
> libgloss/
> 2017-07-03  Tamar Christina  <tamar.christina@arm.com>
> 
> 	* multi-build.in (multi-do): New.

We don't use ChangeLog format anymore.  Rather we would prefer
informative git commit messages and patches in `git format-patch'
format.

These 5 patches qualify as patch series, so it would be nice if
you could resend them that way.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

[Tamar Christina]

Hi Corinna,

Ah sure, I will resend them today.

Thanks,
Tamar
________________________________________
From: newlib-owner@sourceware.org <newlib-owner@sourceware.org> on behalf of Corinna Vinschen <vinschen@redhat.com>
Sent: Wednesday, July 5, 2017 9:36:21 AM
To: newlib@sourceware.org
Subject: Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

Hi Tamar,

On Jul  3 16:53, Tamar Christina wrote:
> Hi All,
>
>
> This patch adds the general build system changes needed
> in order to compile and create the new libraries for Semihosting v2.
>
> This works by creating a similar recursive make target that is modeled
> after the existing multilib makefile config-ml.in.
>
> OK for master?
>
> PS. I do not have commit rights so if OK can someone apply for me?
>
> Thanks,
> Tamar
>
>
> libgloss/
> 2017-07-03  Tamar Christina  <tamar.christina@arm.com>
>
>       * multi-build.in (multi-do): New.

We don't use ChangeLog format anymore.  Rather we would prefer
informative git commit messages and patches in `git format-patch'
format.

These 5 patches qualify as patch series, so it would be nice if
you could resend them that way.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

[Tamar Christina]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

Hi All,

resubmitting these as git-am patches.

Thanks,
Tamar
________________________________________
From: newlib-owner@sourceware.org <newlib-owner@sourceware.org> on behalf of Tamar Christina <Tamar.Christina@arm.com>
Sent: Wednesday, July 5, 2017 9:44:10 AM
To: newlib@sourceware.org
Cc: nd
Subject: Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

Hi Corinna,

Ah sure, I will resend them today.

Thanks,
Tamar
________________________________________
From: newlib-owner@sourceware.org <newlib-owner@sourceware.org> on behalf of Corinna Vinschen <vinschen@redhat.com>
Sent: Wednesday, July 5, 2017 9:36:21 AM
To: newlib@sourceware.org
Subject: Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

Hi Tamar,

On Jul  3 16:53, Tamar Christina wrote:
> Hi All,
>
>
> This patch adds the general build system changes needed
> in order to compile and create the new libraries for Semihosting v2.
>
> This works by creating a similar recursive make target that is modeled
> after the existing multilib makefile config-ml.in.
>
> OK for master?
>
> PS. I do not have commit rights so if OK can someone apply for me?
>
> Thanks,
> Tamar
>
>
> libgloss/
> 2017-07-03  Tamar Christina  <tamar.christina@arm.com>
>
>       * multi-build.in (multi-do): New.

We don't use ChangeLog format anymore.  Rather we would prefer
informative git commit messages and patches in `git format-patch'
format.

These 5 patches qualify as patch series, so it would be nice if
you could resend them that way.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Create-a-recursive-make-target-that-is-modeled.patch --]
[-- Type: text/x-patch; name="0001-Create-a-recursive-make-target-that-is-modeled.patch", Size: 2799 bytes --]

From a51926437ca158775196bd4c60129ed7d72e7fd0 Mon Sep 17 00:00:00 2001
From: Tamar Christina <tamar.christina@arm.com>
Date: Wed, 5 Jul 2017 12:54:52 +0100
Subject: [PATCH 1/5] Create a recursive make target that is modeled after the
 existing multilib makefile config-ml.in which can be used to build the same
 files within a target multiple ways.

e.g. from the same source file produce multiple libs by varying the
options passed to the compiler.

Signed-off-by: Tamar Christina <tamar.christina@arm.com>
---
 libgloss/multi-build.in | 61 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 libgloss/multi-build.in

diff --git a/libgloss/multi-build.in b/libgloss/multi-build.in
new file mode 100644
index 000000000..0bd12cfd9
--- /dev/null
+++ b/libgloss/multi-build.in
@@ -0,0 +1,61 @@
+PWD_COMMAND=$${PWDCMD-pwd}
+
+# FIXME: There should be an @-sign in front of the `if'.
+# Leave out until this is tested a bit more.
+multi-do:
+	if [ -z "$(MULTIDIRS)" ]; then \
+	  true; \
+	else \
+	  rootpre=`${PWD_COMMAND}`/; export rootpre; \
+	  srcrootpre=`cd $(srcdir); ${PWD_COMMAND}`/; export srcrootpre; \
+	  lib=`echo "$${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$$,\1,'`; export lib; \
+	  compiler="$(CC)"; \
+	  for dir in $(MULTIDIRS); do \
+	    if [ "$${dir}" = "." ]; then \
+	      true; \
+	    else \
+	      destpre=`echo $${rootpre}/$${dir}`/; export destpre; \
+	      if ! test -d $${destpre} ; then \
+		mkdir -p $${destpre}; \
+		cp config.status $${destpre}; \
+		cd $${destpre}; \
+		$(SHELL) config.status; \
+		sed -e "s:^MULTIDIRS\s*+=.*$$:MULTIDIRS = :" \
+		    -e "s:^MULTILIBNAME\s*=.*$$:MULTILIBNAME = MULTIDIR_$${dir}_NAME:" \
+		    -e "s:^MULTI_FLAGS_FOR_TARGET\s*=.*$$:MULTI_FLAGS_FOR_TARGET = MULTIDIR_$${dir}_FLAGS:" \
+		    -e "s:^objdir\s*=.*$$:objdir = ..:" \
+			Makefile > Makefile.tem; \
+		rm -f Makefile; \
+		mv Makefile.tem Makefile; \
+	      else \
+		cd $${destpre}; \
+	      fi; \
+	      if ($(MAKE) $(FLAGS_TO_PASS) \
+		    CFLAGS="$(CFLAGS)" \
+		    CCASFLAGS="$(CCASFLAGS)" \
+		    FCFLAGS="$(FCFLAGS)" \
+		    FFLAGS="$(FFLAGS)" \
+		    ADAFLAGS="$(ADAFLAGS)" \
+		    prefix="$(prefix)" \
+		    exec_prefix="$(exec_prefix)" \
+		    GCJFLAGS="$(GCJFLAGS)" \
+		    GOCFLAGS="$(GOCFLAGS)" \
+		    CXXFLAGS="$(CXXFLAGS)" \
+		    LIBCFLAGS="$(LIBCFLAGS)" \
+		    LIBCXXFLAGS="$(LIBCXXFLAGS)" \
+		    LDFLAGS="$(LDFLAGS)" \
+		    MULTIFLAGS="" \
+		    DESTDIR="" \
+		    SOURCE="${srcdir}/" \
+		    INSTALL="$(INSTALL)" \
+		    INSTALL_DATA="$(INSTALL_DATA)" \
+		    INSTALL_PROGRAM="$(INSTALL_PROGRAM)" \
+		    INSTALL_SCRIPT="$(INSTALL_SCRIPT)" \
+		    $(DO)); then \
+		cd $${rootpre}; \
+	      else \
+		exit 1; \
+	      fi; \
+	    fi; \
+	  done; \
+	fi
-- 
2.13.0

Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 183 bytes --]

On Jul  5 12:13, Tamar Christina wrote:
> Hi All,
> 
> resubmitting these as git-am patches.

Pushed.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[Newlib][libgloss]ARM - semihosting use of __end__symbol in crt0.S

[Dave Nadler]

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


On 7/5/2017 4:44 AM, Tamar Christina wrote:
> Hi Corinna,
>
> Ah sure, I will resend them today.
>
> Thanks,
> Tamar
> ________________________________________
> From:newlib-owner@sourceware.org  <newlib-owner@sourceware.org>  on behalf of Corinna Vinschen<vinschen@redhat.com>
> Sent: Wednesday, July 5, 2017 9:36:21 AM
> To:newlib@sourceware.org
> Subject: Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)
>
> Hi Tamar,
>
> On Jul  3 16:53, Tamar Christina wrote:
>> Hi All,
>>
>>
>> This patch adds the general build system changes needed
>> in order to compile and create the new libraries for Semihosting v2.
>>
>> This works by creating a similar recursive make target that is modeled
>> after the existing multilib makefile config-ml.in.
>>
>> OK for master?
>>
>> PS. I do not have commit rights so if OK can someone apply for me?
>>
>> Thanks,
>> Tamar
>>
>>
>> libgloss/
>> 2017-07-03  Tamar Christina<tamar.christina@arm.com>
>>
>>        * multi-build.in (multi-do): New.
> We don't use ChangeLog format anymore.  Rather we would prefer
> informative git commit messages and patches in `git format-patch'
> format.
>
> These 5 patches qualify as patch series, so it would be nice if
> you could resend them that way.
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat


-- 
Dave Nadler, USA East Coast voice (978) 263-0097,drn@nadler.com, Skype
  Dave.Nadler1

Re: [Newlib][libgloss]ARM - semihosting use of __end__symbol in crt0.S

[Tamar Christina]

Hi Dave,

The use of __end__ relates to the semihosting call SYS_HEAPINFO.
Likely the link originally pointed to http://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 <drn@nadler.com>
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


On 7/5/2017 4:44 AM, Tamar Christina wrote:
> Hi Corinna,
>
> Ah sure, I will resend them today.
>
> Thanks,
> Tamar
> ________________________________________
> From:newlib-owner@sourceware.org  <newlib-owner@sourceware.org>  on behalf of Corinna Vinschen<vinschen@redhat.com>
> Sent: Wednesday, July 5, 2017 9:36:21 AM
> To:newlib@sourceware.org
> Subject: Re: [PATCH][Newlib][libgloss] - Semihosting v2 general build changes (1 / 5)
>
> Hi Tamar,
>
> On Jul  3 16:53, Tamar Christina wrote:
>> Hi All,
>>
>>
>> This patch adds the general build system changes needed
>> in order to compile and create the new libraries for Semihosting v2.
>>
>> This works by creating a similar recursive make target that is modeled
>> after the existing multilib makefile config-ml.in.
>>
>> OK for master?
>>
>> PS. I do not have commit rights so if OK can someone apply for me?
>>
>> Thanks,
>> Tamar
>>
>>
>> libgloss/
>> 2017-07-03  Tamar Christina<tamar.christina@arm.com>
>>
>>        * multi-build.in (multi-do): New.
> We don't use ChangeLog format anymore.  Rather we would prefer
> informative git commit messages and patches in `git format-patch'
> format.
>
> These 5 patches qualify as patch series, so it would be nice if
> you could resend them that way.
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat


--
Dave Nadler, USA East Coast voice (978) 263-0097,drn@nadler.com, Skype
  Dave.Nadler1

Re: [Newlib][libgloss]ARM - semihosting use of __end__symbol in crt0.S

[Dave Nadler]

Thanks Tamar - but, what is the heap base address _used_ for in semihosting?

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<drn@nadler.com>
> 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


-- 
Dave Nadler, USA East Coast voice (978) 263-0097,drn@nadler.com, Skype
  Dave.Nadler1

Re: [Newlib][libgloss]ARM - semihosting use of __end__symbol in crt0.S

[Senthil Kumar Selvaraj]

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<drn@nadler.com>
>> 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

RE: [Newlib][libgloss]ARM - semihosting use of __end__symbol in crt0.S

[Tamar Christina]

> 
> 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...

Our default implementations don't use this for anything, it just makes it available.
The sbrk implementation in rdimon only uses __heap_limit from the SYS_HEAPINFO call.

That said the sbrk implementation is currently using "end" as the heap base.

> >
> > 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<drn@nadler.com>
> >> 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-
> en
> >> d-especially-arm-embedded
> >>
> >> Thanks in advance for any clarification, Best Regards, Dave