[Bug ports/15505] New: ARM glibc missing __aeabi_ctype_table_C and __aeabi_ctype_table_

[Bug ports/15505] New: ARM glibc missing __aeabi_ctype_table_C and __aeabi_ctype_table_

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15505

             Bug #: 15505
           Summary: ARM glibc missing __aeabi_ctype_table_C and
                    __aeabi_ctype_table_
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ports
        AssignedTo: unassigned@sourceware.org
        ReportedBy: jsm28@gcc.gnu.org
                CC: carlos@redhat.com, roland@gnu.org
    Classification: Unclassified


The ABI for the ARM Architecture defines various __aeabi_* symbols that are
supposed to be provided by the C library.  Most are provided by glibc (some in
the shared library, some libc_nonshared), but not the required arrays

extern unsigned char const __aeabi_ctype_table_C[257];
extern unsigned char const __aeabi_ctype_table_[257];

defined in CLIBABI (section 5.3.1 of IHI 0039C).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug ports/15505] ARM glibc missing __aeabi_ctype_table_C and __aeabi_ctype_table_

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=15505

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
I understand the EABI requires these, but is there any practical use for them?
Some __aeabi_* function calls could obviously be generated by the compiler, but
I see no reason to believe these would ever be generated by a compiler and thus
I'm a bit confused what usefulness they might have...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ports/15505] ARM glibc missing __aeabi_ctype_table_C and __aeabi_ctype_table_

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15505

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The point of the CLIBABI symbols (such as the ones in this bug report) is 
to support .o files that can be used with more than one C library 
implementation.  The glibc headers can't be used to compile such objects, 
but given objects built with C library headers that support 
_AEABI_PORTABILITY_LEVEL != 0, it should be possible to link those objects 
with glibc and have the code work as expected.

The symbols intended for compiler rather than library portability of .o 
files are generally those defined in RTABI; most of those are in libgcc, 
with only a few such as __aeabi_memcpy* and __aeabi_read_tp being in 
glibc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ports/15505] ARM glibc missing __aeabi_ctype_table_C and __aeabi_ctype_table_

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=15505

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
> The point of the CLIBABI symbols (such as the ones in this bug report) is 
> to support .o files that can be used with more than one C library 
> implementation.

This makes no sense to me. Any conforming C library will have the
function named "localeconv". Is the issue the layout of the structure,
i.e. is the CLIBABI defining special functions like this for each
standard library function that has structure-layout, choice-of-type,
etc. issues for the argument or return types? I question whether glibc
or any other libc implementation should bother to support such a
thing, anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ports/15505] ARM glibc missing __aeabi_ctype_table_C and __aeabi_ctype_table_

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15505

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 31 May 2013, bugdal at aerifal dot cx wrote:

> This makes no sense to me. Any conforming C library will have the
> function named "localeconv". Is the issue the layout of the structure,

Yes.  (As noted in bug 15500, glibc's __aeabi_localeconv is broken.)

> i.e. is the CLIBABI defining special functions like this for each
> standard library function that has structure-layout, choice-of-type,
> etc. issues for the argument or return types? I question whether glibc

Yes, for the cases where the use of the library facilities in question in 
portable .o files is supported and CLIBABI doesn't just require a 
particular value or layout that is de facto universal.  All the 
ports/sysdeps/arm/aeabi_* files, except aeabi_mem*.c and 
aeabi_unwind_cpp_pr1.c, are in support of this feature.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/15505] [arm] ARM glibc missing __aeabi_ctype_table_C and __aeabi_ctype_table_

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15505

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drepper.fsp at gmail dot com
          Component|ports                       |libc
               Host|                            |arm*-*-*
            Summary|ARM glibc missing           |[arm] ARM glibc missing
                   |__aeabi_ctype_table_C and   |__aeabi_ctype_table_C and
                   |__aeabi_ctype_table_        |__aeabi_ctype_table_

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/15505] [arm] ARM glibc missing __aeabi_ctype_table_C and __aeabi_ctype_table_

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15505

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.