The semihosting and FDT code makes use of libc style string functions implemented in our string.c, however it relies of the system providing the string.h header file.
This causes problems on toolchains that don't provide these headers, like Android toolchains, and it also means that we include declaration for functions which aren't implemented in the bootwrapper.
Resolve this by providing our own string.h which declares only the functions we implement and add the base directory to the include path so this header is found.
Signed-off-by: Jon Medhurst tixy@linaro.org --- Makefile | 2 +- string.h | 16 ++++++++++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 string.h
diff --git a/Makefile b/Makefile index 995fd8f..f8fc841 100644 --- a/Makefile +++ b/Makefile @@ -57,7 +57,7 @@ monitor.o: $(MONITOR) $(CC) $(CPPFLAGS) -c -o $@ $<
%.o: %.c - $(CC) $(CPPFLAGS) -O2 -ffreestanding -Ilibfdt -c -o $@ $< + $(CC) $(CPPFLAGS) -O2 -ffreestanding -I. -Ilibfdt -c -o $@ $<
model.lds: $(LD_SCRIPT) Makefile $(CC) $(CPPFLAGS) -E -P -C -o $@ $< diff --git a/string.h b/string.h new file mode 100644 index 0000000..f1aebdf --- /dev/null +++ b/string.h @@ -0,0 +1,16 @@ +#ifndef STRING_H +#define STRING_H + +#include <stddef.h> + +extern void *(memcpy)(void *__dest, __const void *__src, size_t __n); +extern void *(memmove)(void *__dest, __const void *__src, size_t __n); +extern void *(memchr)(void const *s, int c, size_t n); +extern size_t (strlen)(const char *s); +extern void *(memset)(void *s, int c, size_t count); +extern int (memcmp)(void const *p1, void const *p2, size_t n); +extern int (strcmp)(char const *s1, char const *s2); +extern int (strncmp)(char const *s1, char const *s2, size_t n); +extern char *(strchr)(char const *s, int c); + +#endif
On 4 September 2012 15:57, Jon Medhurst (Tixy) tixy@linaro.org wrote:
Thanks for this patch; looks pretty good.
The semihosting and FDT code makes use of libc style string functions implemented in our string.c, however it relies of the system
"relies on". (I can fix this when I commit the patch.)
providing the string.h header file.
This causes problems on toolchains that don't provide these headers, like Android toolchains, and it also means that we include declaration for functions which aren't implemented in the bootwrapper.
Resolve this by providing our own string.h which declares only the functions we implement and add the base directory to the include path so this header is found.
Signed-off-by: Jon Medhurst tixy@linaro.org
Makefile | 2 +- string.h | 16 ++++++++++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 string.h
diff --git a/Makefile b/Makefile index 995fd8f..f8fc841 100644 --- a/Makefile +++ b/Makefile @@ -57,7 +57,7 @@ monitor.o: $(MONITOR) $(CC) $(CPPFLAGS) -c -o $@ $<
%.o: %.c
$(CC) $(CPPFLAGS) -O2 -ffreestanding -Ilibfdt -c -o $@ $<
$(CC) $(CPPFLAGS) -O2 -ffreestanding -I. -Ilibfdt -c -o $@ $<model.lds: $(LD_SCRIPT) Makefile $(CC) $(CPPFLAGS) -E -P -C -o $@ $< diff --git a/string.h b/string.h new file mode 100644 index 0000000..f1aebdf --- /dev/null +++ b/string.h @@ -0,0 +1,16 @@ +#ifndef STRING_H +#define STRING_H
+#include <stddef.h>
I guess to be fully consistent we should provide our own stddef.h and stdint.h, but if it's not causing problems it's not worth the effort.
+extern void *(memcpy)(void *__dest, __const void *__src, size_t __n);
I was going to complain about the weird parens around function names and inconsistent use of __ prefix on parameter names, but I see these all come straight from the existing string.c, so never mind :-)
+extern void *(memmove)(void *__dest, __const void *__src, size_t __n); +extern void *(memchr)(void const *s, int c, size_t n); +extern size_t (strlen)(const char *s); +extern void *(memset)(void *s, int c, size_t count); +extern int (memcmp)(void const *p1, void const *p2, size_t n); +extern int (strcmp)(char const *s1, char const *s2); +extern int (strncmp)(char const *s1, char const *s2, size_t n); +extern char *(strchr)(char const *s, int c);
+#endif
1.7.10.4
Reviewed-by: Peter Maydell peter.maydell@linaro.org
-- PMM
On 4 September 2012 16:10, Peter Maydell peter.maydell@linaro.org wrote:
I guess to be fully consistent we should provide our own stddef.h and stdint.h, but if it's not causing problems it's not worth the effort.
Actually, I'm wrong there. We're using gcc's -ffreestanding so it's being a conforming freestanding implementation, and has to provide us with stddef.h and stdint.h.
-- PMM
On Tue, 2012-09-04 at 16:10 +0100, Peter Maydell wrote:
On 4 September 2012 15:57, Jon Medhurst (Tixy) tixy@linaro.org wrote:
diff --git a/string.h b/string.h new file mode 100644 index 0000000..f1aebdf --- /dev/null +++ b/string.h @@ -0,0 +1,16 @@ +#ifndef STRING_H +#define STRING_H
+#include <stddef.h>
I guess to be fully consistent we should provide our own stddef.h and stdint.h, but if it's not causing problems it's not worth the effort.
That was my thinking, especially as the definitions might depend on non-standard types and toolchain version - let sleeping dogs lie ;-)
+extern void *(memcpy)(void *__dest, __const void *__src, size_t __n);
I was going to complain about the weird parens around function names and inconsistent use of __ prefix on parameter names, but I see these all come straight from the existing string.c, so never mind :-)
Yes, I thought they looked weird too, but I just copied the non-static function prototypes straight out of string.c.
On Tue, Sep 04, 2012 at 04:26:32PM +0100, Jon Medhurst (Tixy) wrote:
On Tue, 2012-09-04 at 16:10 +0100, Peter Maydell wrote:
On 4 September 2012 15:57, Jon Medhurst (Tixy) tixy@linaro.org wrote:
diff --git a/string.h b/string.h new file mode 100644 index 0000000..f1aebdf --- /dev/null +++ b/string.h @@ -0,0 +1,16 @@ +#ifndef STRING_H +#define STRING_H
+#include <stddef.h>
I guess to be fully consistent we should provide our own stddef.h and stdint.h, but if it's not causing problems it's not worth the effort.
That was my thinking, especially as the definitions might depend on non-standard types and toolchain version - let sleeping dogs lie ;-)
+extern void *(memcpy)(void *__dest, __const void *__src, size_t __n);
I was going to complain about the weird parens around function names and inconsistent use of __ prefix on parameter names, but I see these all come straight from the existing string.c, so never mind :-)
Yes, I thought they looked weird too, but I just copied the non-static function prototypes straight out of string.c.
The parentheses are there to suppress some inline macro expansions which happen if you build the GCC headers with optimisation turned on.
We really should have our own versions of the relevant headers, but I avoided it out of laziness, on the assumption that we could fix it as needed.
The nonstandard types are there out of simplicity/laziness ... this was never intended to remotely resemble a C environment. Since almost C types are equivalent to int or unsigned anyway, the simplified types "work". In a freestanding environment which isn't supposed to be C it would probably be overkill to define all the types, but it could be done if needed.
Cheers ---Dave
On 4 September 2012 15:57, Jon Medhurst (Tixy) tixy@linaro.org wrote:
The semihosting and FDT code makes use of libc style string functions implemented in our string.c, however it relies of the system providing the string.h header file.
This causes problems on toolchains that don't provide these headers, like Android toolchains, and it also means that we include declaration for functions which aren't implemented in the bootwrapper.
Resolve this by providing our own string.h which declares only the functions we implement and add the base directory to the include path so this header is found.
Signed-off-by: Jon Medhurst tixy@linaro.org
Applied, thanks.
-- PMM
-
Dave Martin -
Jon Medhurst (Tixy) -
Peter Maydell