Re: GCC?, was Re: Running m68k on qemu with external initramfs?

[Rob Landley <rob@landley.net>]

On 4/12/20 6:30 PM, Finn Thain wrote:
> On Sun, 12 Apr 2020, Rob Landley wrote:
> 
>>
>> 2) THEN the problem was that gcc is doing something in cd_main so that 
>> the "chdir ." at the start of the shell setup (to set $PWD and friends) 
>> is segfaulting, but it's a segfault that went away when I got near it 
>> with printf() calls, and even write(1, "", 0); right before it made it 
>> go away. Given that this code has run on 32 and 64 bit, big and little 
>> endian, glibc musl and bionic, and on a target that's both nommu and 
>> cares about alignment?
> 
> Are you sure that "gcc is doing something [wrong]"? Do you think it could 
> be a QEMU bug? Can you provide some information about your tool chain?

I provided the reproduction sequence to build the toolchain from source a post
or two back as part of the general reproduction sequence?

Here's the version and config stuff:

m68k-linux-musl-cc --version
m68k-linux-musl-cc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

m68k-linux-musl-ld --version
GNU ld (GNU Binutils) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

$ ./m68k-linux-musl-cc -v
Using built-in specs.
COLLECT_GCC=./m68k-linux-musl-cc
COLLECT_LTO_WRAPPER=/home/landley/mcm/clean/ccc/m68k-linux-musl-cross/bin/../libexec/gcc/m68k-linux-musl/9.2.0/lto-wrapper
Target: m68k-linux-musl
Configured with: ../src_gcc/configure --enable-languages=c,c++ CFLAGS=' -g0 -Os'
CXXFLAGS=' -g0 -Os' LDFLAGS=' -s' CC='i686-linux-musl-gcc -static --static'
CXX='i686-linux-musl-g++ -static --static' --disable-nls --disable-libquadmath
--disable-decimal-float --disable-multilib --enable-languages=c,c++
--disable-bootstrap --disable-assembly --disable-werror --target=m68k-linux-musl
--prefix= --libdir=/lib --disable-multilib --with-sysroot=/m68k-linux-musl
--enable-tls --disable-libmudflap --disable-libsanitizer
--disable-gnu-indirect-function --disable-libmpx --enable-libstdcxx-time=rt
--with-build-sysroot=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_sysroot
AR_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/binutils/ar
AS_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/gas/as-new
LD_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/ld/ld-new
NM_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/binutils/nm-new
OBJCOPY_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/binutils/objcopy
OBJDUMP_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/binutils/objdump
RANLIB_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/binutils/ranlib
READELF_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/binutils/readelf
STRIP_FOR_TARGET=/home/landley/mcm/clean/build/local/m68k-linux-musl/obj_binutils/binutils/strip-new
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
Thread model: posix
gcc version 9.2.0 (GCC)

(I build toolchains statically linked on against musl on the host so they're
portable and you can just extract the tarball of binaries and run it). And it's
built with i686 instead of x86-64 because that runs faster due to cache
locality: 90% of the reason for x32 was the 32 bit time_t and that got fixed
anyway, so just "statically link 32 bit binary" and you get all the benefits of
that these days...)

I have a todo item to pare my 2700 line toysh source file (plus however much of
main.c and lib/*.c it's pulling in, "LDFLAGS=--static
CROSS_COMPILE=ccc/m68k-linux-musl-cross/bin/m68k-linux-musl- make sh" makes a
99k m68k binary) down into a minimal reproduction thingy, but I'm trying to get
the other targets to finish parsing the init script so I can cut a toybox release.

>> Because I'm still halfway through teaching toysh about all the ${} 
>> constructs. (Also, remind me to stick echo -e '\e[?7h' at the start of 
>> my init script to undo the STUPID wordwrap disable escape that qemu's 
>> bios outputs, which screws up bash's command line history too!)
> 
> How awful. It baffles me every time bash manages to mishandle unprintable 
> output from a command such that it somehow becomes command line input 
> which bash then attempts to execute! I wish I knew how to prevent that.

This isn't bash's fault, this is qemu using a deeply obscure escape sequence
("man 4 console_codes" search for DECAWM) to leave the terminal in a weird state.

Bash is assembling the command line fine, you just can't see the output because
the cursor alignment's off (and it keeps cursoring up one line every time you
edit stuff because bash thinks the cursor went to the next line and it didn't
because line wrap disabled). When it does this I hit home # enter to comment out
the line I'm editing, and then run "reset", then cursor up twice and resume
editing the line.

I just stuck the "fix it" escape sequence at the end of my qemu wrapper script.
I'd submit a patch to qemu, but the last few I've posted to that list got lost
in the noise.

Rob