[Toybox] A couple of minor fixes
Rob Landley
rob at landley.net
Wed Jun 15 07:40:29 PDT 2016
On 06/14/2016 02:54 AM, Paul Barker wrote:
> On Mon, 13 Jun 2016 16:49:46 +0100
> Paul Barker <paul at paulbarker.me.uk> wrote:
>
>> On Mon, 13 Jun 2016 16:13:19 +0100
>> Paul Barker <paul at paulbarker.me.uk> wrote:
>>>
>>> I still agree that this should be fixed in glibc if possible though.
>>> I'll build a test app later and see what happens for different trim
>>> values (INT_MAX, INT_MAX/2, INT_MAX/4, etc) with glibc in an
>>> OpenEmbedded build.
>>>
>>
>> #include <limits.h>
>> #include <stdio.h>
>>
>> int main(int argc, char *argv[])
>> {
>> const char *str = "Hello, World!";
>> int trim[] = { INT_MAX, INT_MAX/2, INT_MAX/4,
>> INT_MAX/8, INT_MAX/16, INT_MAX/32, INT_MAX/64,
>> INT_MAX/128, INT_MAX/256, INT_MAX/512 };
>> int i;
>>
>> for (i = 0; i < 10; i++) {
>> printf("trim=%d : ", trim[i]);
>> printf("%.*s", trim[i], str);
>> printf("\n");
>> }
>>
>> return 0;
>> }
>>
>
> I've now tried this on:
> * Debian 8 (aka jessie or stable with glibc 2.19-18+deb8u4), x86_64
> * Debian testing (aka stretch with glibc 2.22-11), x86_64.
> * glibc 2.23 built from source on Debian testing, x86_64
> * glibc built from source on Debian testing, x86_64
I've just been bisecting the glibc git repository to see where they
introduced the bug. So far I've hit the fact that glibc-2.15 build
breaks on current gcc:
In file included from <command-line>:0:0:
../misc/syslog.c: In function ‘__vsyslog_chk’:
../misc/syslog.c:123:30: error: inlining failed in call to always_inline
‘syslog’: function not inlinable
ldbl_strong_alias (__syslog, syslog)
And I'm bisecting between 2.15 and 2.16 to see where that got fixed.
(Isn't it nice how often gcc "upgrades" fail to build existing packages?)
But I've been bisecting on a slow netbook during a series of meetings
that run through Thursday (an engineering summit thing) so it's a slow
background thing.
Interestingly, when the printf aborts it doesn't print anything _after_
the field in question either:
printf("one %.*s three", INT_MAX, "two");
It doesn't print the "three" either. This is very, very clearly a glibc
bug...
> I've also tried:
> * OpenEmbedded master branch built for x86_64 (glibc post-2.23 release
> from git repository)
> * OpenEmbedded krogoth branch (mid-2016 release, glibc 2.23)
> * OpenEmbedded fido branch (mid-2015 release, glibc 2.21)
> * OpenEmbedded daisy branch (mid-2014 release, glibc 2.19)
They use a glibc since the bug was introduced.
> That's the same issue I saw on OE master built for i586 so this isn't a
> 32-bit vs 64-bit issue. It's down at INT_MAX/16 before anything is
> printed out. It's also not a recent bug as it exists in code from 2014.
Yes, it was introduced sometime after ubuntu 12.04 but before ubuntu
14.04. It would have to be in code from 2014 to be in ubuntu 14.04,
which shipped in April 2014.
> I'll investigate further and then raise this on the OpenEmbedded
> bugzilla. It's either an effect of patches/configuration applied by
> OpenEmbedded or it's an upstream bug that's only triggered when
> cross-compiling.
No, I'm getting it in native compiling from the stock glibc repository.
Clone the repo:
git clone git://sourceware.org/git/glibc.git
Build the repo:
$ cd ~linux; make headers_install INSTALL_HDR_PATH=~/glibc/headers
$ (rm -rf build && mkdir build && cd build && ../glibc/configure \
--prefix=$PWD/../install --host=x86_64-unknown-linux \
--disable-profile --enable-kernel=2.6.32 \
--with-headers=/home/landley/glibc/headers/include \
libc_cv_forced_unwind=yes libc_cv_ctors_header=yes \
libc_cv_c_cleanup=yes && make -j 2 && make install)
Test the repo:
$ cat test.c
#include <stdio.h>
#include <limits.h>
int main(int argc, char *argv[])
{
printf("test=[%.*s]", INT_MAX, "hello");
printf("\n");
}
$ gcc -nostdinc -isystem install/include -isystem headers/include \
-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/include -isystem \
/usr/lib /gcc/x86_64-linux-gnu/4.8/include-fixed -nostdlib -static \
-Linstall/lib -L /usr/lib/gcc/x86_64-linux-gnu/4.8 \
install/lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginT.o \
install/lib/crt1.o test.c -Wl,--start-group,--as-needed -lgcc \
-lgcc_eh -lc -Wl,--no-as-needed,--end-group \
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtend.o install/lib/crtn.o
$ ./a.out
That gcc line uses paths for the ubuntu 14.04 gcc install.
Rob
More information about the Toybox
mailing list