This is the mail archive of the
mailing list for the glibc project.
Re: Fix sysdeps/unix/sysv/linux/arm/libc-do-syscall.S warning
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Mike Frysinger <vapier at gentoo dot org>, libc-alpha at sourceware dot org
- Date: Thu, 05 Mar 2015 17:22:47 -0500
- Subject: Re: Fix sysdeps/unix/sysv/linux/arm/libc-do-syscall.S warning
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1411261513490 dot 27454 at digraph dot polyomino dot org dot uk> <20150302041414 dot GR19363 at vapier> <alpine dot DEB dot 2 dot 10 dot 1503022312530 dot 32749 at digraph dot polyomino dot org dot uk> <54F8AF68 dot 9090803 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1503052213010 dot 31721 at digraph dot polyomino dot org dot uk>
On 03/05/2015 05:14 PM, Joseph Myers wrote:
> On Thu, 5 Mar 2015, Carlos O'Donell wrote:
>>>> should we update features.h to avoid that define when __ASSEMBLER__ is defined ?
>>>> seems like this warning can impact external code too.
>>> I don't know. To what extent do we support users including glibc header
>>> files from assembler code?
>> To the extent that it builds glibc without warnings?
> That answer bears no relation to my intended question. Users = users of
> glibc including headers in non-glibc applications, built outside of the
> glibc build process. Such uses are completely independent of whether
> glibc itself builds without warnings.
If compiling libc-do-syscall.S generates a warning, we should fix it so it
doesn't generate a warning. Any fixes beyond those which fix the warning
We should not do any active work to support including glibc header files
from assembly unless we have specific requests from users for specific
Does that answer your question?