| Message ID | 1409959394-14936-1-git-send-email-behanw@converseincode.com |
|---|---|
| State | New |
| Headers | show |
On Friday 05 September 2014 16:23:14 behanw@converseincode.com wrote: > --- /dev/null > +++ b/arch/arm64/lib/eabi.c > @@ -0,0 +1,32 @@ > +/* > + * linux/lib/eabi.c Please don't put the file names in the files themselves, it's redundant and in this case actually wrong. > + * Copyright (C) 2012 Mark Charlebois > + */ > + > +/* > + * EABI routines Does EABI specify these function names? I would think that they are just random libgcc (whatever that is called in clang) functions. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 09/06/14 07:16, Arnd Bergmann wrote: > On Friday 05 September 2014 16:23:14 behanw@converseincode.com wrote: >> --- /dev/null >> +++ b/arch/arm64/lib/eabi.c >> @@ -0,0 +1,32 @@ >> +/* >> + * linux/lib/eabi.c > Please don't put the file names in the files themselves, it's redundant > and in this case actually wrong. Will fix. >> + * Copyright (C) 2012 Mark Charlebois >> + */ >> + >> +/* >> + * EABI routines > Does EABI specify these function names? I would think that they are > just random libgcc (whatever that is called in clang) functions. These specialized functions are part of the ABI for the ARM architecture (AEABI). They aren't random. Memcpy and memmove *could* might be satisfied with linker magic instead. But memset uses the reverse parameter list. Behan
On Sat, Sep 6, 2014 at 7:16 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Friday 05 September 2014 16:23:14 behanw@converseincode.com wrote: > > --- /dev/null > > +++ b/arch/arm64/lib/eabi.c > > @@ -0,0 +1,32 @@ > > +/* > > + * linux/lib/eabi.c > > Please don't put the file names in the files themselves, it's redundant > and in this case actually wrong. Sorry, will fix. > > > + * Copyright (C) 2012 Mark Charlebois > > + */ > > + > > +/* > > + * EABI routines > > Does EABI specify these function names? I would think that they are > just random libgcc (whatever that is called in clang) functions. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf See section 4.3.4 Memory copying, clearing, and setting > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 7 Sep 2014, at 03:30, Mark Charlebois <charlebm@gmail.com> wrote: > On Sat, Sep 6, 2014 at 7:16 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Friday 05 September 2014 16:23:14 behanw@converseincode.com wrote: >>> + * Copyright (C) 2012 Mark Charlebois >>> + */ >>> + >>> +/* >>> + * EABI routines >> >> Does EABI specify these function names? I would think that they are >> just random libgcc (whatever that is called in clang) functions. > > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf > > See section 4.3.4 Memory copying, clearing, and setting What does this document have to do with arm64 (AArch64, A64)? We don’t need such symbols on arm64. Also, the arm64 kernel links with libgcc (no immediate need AFAICT but the compiler does not guarantee the intrinsics would always be generated inline). Catalin-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Sun, Sep 7, 2014 at 12:30 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On 7 Sep 2014, at 03:30, Mark Charlebois <charlebm@gmail.com> wrote: >> On Sat, Sep 6, 2014 at 7:16 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>> >>> On Friday 05 September 2014 16:23:14 behanw@converseincode.com wrote: >>>> + * Copyright (C) 2012 Mark Charlebois >>>> + */ >>>> + >>>> +/* >>>> + * EABI routines >>> >>> Does EABI specify these function names? I would think that they are >>> just random libgcc (whatever that is called in clang) functions. >> >> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf >> >> See section 4.3.4 Memory copying, clearing, and setting > > What does this document have to do with arm64 (AArch64, A64)? We don’t > need such symbols on arm64. Also, the arm64 kernel links with libgcc (no > immediate need AFAICT but the compiler does not guarantee the intrinsics > would always be generated inline). [reposting in plain text] This patch was made early in the arm64 kernel support. I just retested and you are correct, it is no longer needed. My apologies to all. -Mark > > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 09/08/14 16:01, Mark Charlebois wrote: > On Sun, Sep 7, 2014 at 12:30 AM, Catalin Marinas > <catalin.marinas@arm.com> wrote: >> On 7 Sep 2014, at 03:30, Mark Charlebois <charlebm@gmail.com> wrote: >>> On Sat, Sep 6, 2014 at 7:16 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>>> On Friday 05 September 2014 16:23:14 behanw@converseincode.com wrote: >>>>> + * Copyright (C) 2012 Mark Charlebois >>>>> + */ >>>>> + >>>>> +/* >>>>> + * EABI routines >>>> Does EABI specify these function names? I would think that they are >>>> just random libgcc (whatever that is called in clang) functions. >>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf >>> >>> See section 4.3.4 Memory copying, clearing, and setting >> What does this document have to do with arm64 (AArch64, A64)? We don’t >> need such symbols on arm64. Also, the arm64 kernel links with libgcc (no >> immediate need AFAICT but the compiler does not guarantee the intrinsics >> would always be generated inline). > [reposting in plain text] > > This patch was made early in the arm64 kernel support. I just retested > and you are correct, it is no longer needed. My apologies to all. Whoops. I normally check whether a patch is still needed before posting them. I seem to have missed that step this time. My apologies as well. That all being said, I prefer to see patches no longer required, than needing them to be upstreamed, so in that this is a win. Behan
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile index d98d3e3..0d3407c 100644 --- a/arch/arm64/lib/Makefile +++ b/arch/arm64/lib/Makefile @@ -3,3 +3,7 @@ lib-y := bitops.o clear_user.o delay.o copy_from_user.o \ clear_page.o memchr.o memcpy.o memmove.o memset.o \ memcmp.o strcmp.o strncmp.o strlen.o strnlen.o \ strchr.o strrchr.o + +ifeq ($(COMPILER),clang) +lib-y += eabi.o +endif diff --git a/arch/arm64/lib/eabi.c b/arch/arm64/lib/eabi.c new file mode 100644 index 0000000..41b27b2 --- /dev/null +++ b/arch/arm64/lib/eabi.c @@ -0,0 +1,32 @@ +/* + * linux/lib/eabi.c + * + * Copyright (C) 2012 Mark Charlebois + */ + +/* + * EABI routines + */ + +#include <linux/types.h> +#include <linux/string.h> +#include <linux/ctype.h> +#include <linux/export.h> + +void __aeabi_memcpy(void *dest, const void *src, size_t n) +{ + (void)memcpy(dest, src, n); +} +EXPORT_SYMBOL(__aeabi_memcpy); + +void __aeabi_memmove(void *dest, const void *src, size_t n) +{ + (void)memmove(dest, src, n); +} +EXPORT_SYMBOL(__aeabi_memmove); + +void __aeabi_memset(void *s, size_t n, int c) +{ + (void)memset(s, c, n); +} +EXPORT_SYMBOL(__aeabi_memset);