cross-compiling eix for k6 [WORKAROUND:use gcc<8]

[Tony0945]

I was never a professional software person, I just had to do some now and again.

??? Were you a hardware engineer, then? Perhaps, the mirror image of me, who had to do some hardware now and then.
Nonetheless, your knowledge of Gentoo and Linux are encyclopedic. I started out doing physical simulations of tractors, and hydraulic systems in FORTRAN, which were things I was college trained for. At the dawn of the microprocessor age, I moved into Assembly language programming of the 8085 and 8048 while also simulating the complete control system in FORTRAN. The 8051 was a miracle chip! With some more training, I moved into C programming of 8086/8088 control systems and some plant control with IBM minicomputers. I wrote a simple C compiler that ran on TNIX and emitted Assembly Code for the Z80. C was coming on strong and I worked on a variety of control projects in C including one on the PowerPC, mostly using small real-time embedded operating systems. That's about the shortest 25 year resume you will ever see.

I presume your objection to 17.0 profiles on i686 and below are the default USE=pie setting, which demands the use of a base address register on an arch that doesn't have enough registers to start with?
You don't have to have pie on the 17.0 and later profiles. The profile forces USE=pie but you are free to unforce it and turn it off. That's the path of least resistance.
With the 17.0 profiles, you also get package mask changes that you may or may not find useful.

As I said I use the 17.0 profile on the 64 bit desktops with pie. I used it for the laptop that I updated for my sister, replacing the Win 8 drive with a customized Gentoo (redundant, all Gentoo installations are custom). Much faster, and IMHO more secure than Windoze 8 with Norton. Told her to stop paying Norton $200 a year for "protection". I just think it's (pie) too heavy for 32 bits. We did some great work with 16 bit hardware and, as I noted, even 8 bit, but it all has to be customized and honed. (sixteen bits were the Cadillac systems, the IBM 4331 was God at a blistering 80 megabits per second, 20X our micros.

[ville.aakko]

Hi again,

Thanks for all your input.

I've double checking everything I can think of and with the help of the information in this thread, and only thing I can think of is removing the pie use flag. Still a shot with a shotgun into the dark...

NeddySeagoon: I'm a bit confused with this:

You may not mix PIE and not PIE code. It breaks all your static libraries.

Does this mean I need to build only *some* parts of my system, or the whole toolchain again, or whole @world after disabling (or changing) use flag for gcc? Could I test this with something like "emerge -1 gcc" (after disabling pie) and then emerge -e eix?

Just to make sure, the right procedure is to remove the force and then bootstrap.sh again (... or no? Please see my question above). I could also start from a fresh chroot, but I suppose it shouldn't matter (either way, I need to recompile @system - and @world doesn't include much as it stands currently). I.e. I'll do as follows:

• * Remove forced pie use flag (i.e. either via /etc/portage/profile/package.use.force or /etc/portage/profile/package.use.mask)
  • * In the former sys-devel/gcc -pie, in the latter sys-devel/gcc pie is needed (both wont hurt but either one should suffice)
  * Put -pie in make.conf (also red the part about checking per-package)
  * Make the above changes in this list both in the chroot slave build environment and on the target box
  * Rebuild toolchain on the slave chroot via bootstrap.sh
  * Rebuild (emerge -e ...) @system (emerge -e) for the chroot
  * Rebuild @system packages for the target (I do not need to care about order here, as it's the slaves toolchain which is getting used?)
  * Rebuild @world packages (actually, can skip @system)
  * emerge -Ge @world on the target box

Also a few things: the eix binary runs fine if compiled locally on the k6-3 box. The only reason I'm bothering with this is that the compiles take a prohibitively long time on the box - which is why a powerful build slave is quite needed - and, we have not determined why the eix build fails; that means broken binaries - which I haven't found (besides eix) so far - could be found elsewhere, too ...

I feel like changing the profile could be something I should not have any problems with. After all, I suppose it is a matter of choosing the 13.0 profile, running boostrap.sh again, and them emerge @world? However, I'm not sure the differences besides -pie/pie change (from 17.0 -> 13.0), and if it is worth to make that another shot into dark ...

[Tony0945]

the eix binary runs fine if compiled locally on the k6-3 box

I would quickpkg eix on the k6-3 box. Then, I would copy everything to the VM, making the VM a clone of the k6-3 box.

Don't know which VM you are using, but on the virtualbox site there are some instructions for cloning from a harddrive. Or maybe, maybe, you can use scp to copy everything from the physical box to the virtual. Something got mixed up on the virtual box.
Or rsync per this thread: https://forums.gentoo.org/viewtopic-t-1 ... ight-.html
I would use scp, but that may be just curmudgeon talk.

Neddy, do you concur?

[NeddySeagoon]

ville.aakko,

Its not USE=pie if you have the 17.0 profile on the k6-3 and in the build environment.
PIE related issues usually show up at link time, not run time.

The USE=pie flag on gcc is a bit odd as USE flags go.
It controls the default gcc behaviour, when -fpie or -fno-pie are not specified explicitly when gcc is invoked.
On other packages, it changes how the packages are built.

Be aware that setting USE=-pie on gcc will have no effect.
USE=pie is forced on by the profile. It appears as (pie). If you really want to turn pie off, you must first unforce it.

[Tony0945]

Here is my build system's make.conf http://dpaste.com/3RXTH3K
Note the FEATURES, it builds a package every time.
Per NeddySeagoon, i586 should be OK in CHOST in place of i486. i686 is definitely bad.
Adjust MAKEOPTS="-j6" for your build CPU.
Set USE as you desire. If you already are on profile 17.0 with pie default, I'd leave it that way. As I said before, I'm on 13.0 without pie. But a performance penalty is better than a crash.
The first thing is to get it to run. 17.0 wasn't available when I set this all up and later, when it was, I thought it not worth the performance penalty, as I said before.

PORTAGE_BINHOST won't work for you because that address is on my LAN. You can't reach it.
I run an old version of OpenRC. If you don't, you may have to adjust INSTALL_MASK

Good luck!

[NeddySeagoon]

Tony0945, ville.aakko,

PORTAGE_BINHOST won't work for you because that address is on my LAN. You can't reach it.

Well, I just had to try :)

Now the more serious part of my post.
From an earlier post we know

Code: Select all

# lddtree $(which eix)
eix => /usr/bin/eix (interpreter => /lib/ld-linux.so.2)
    libstdc++.so.6 => /usr/lib/gcc/i586-pc-linux-gnu/8.2.0/libstdc++.so.6
        libm.so.6 => /lib/libm.so.6
        ld-linux.so.2 => /lib/ld-linux.so.2
    libgcc_s.so.1 => /usr/lib/gcc/i586-pc-linux-gnu/8.2.0/libgcc_s.so.1
    libc.so.6 => /lib/libc.so.6

Tony,

I guess that a) this works for you b) you have all the binaries required?

Are you able to host them, so that ville.aakko can try them one at a time to see which one fixes the problem?
If not, PM me and we can arrange something.

[ville.aakko]

Hi,

I believe this thread is getting a bit difficult to follow for some. Some things I need to clear up:

• * The problem in the beginning was: I was using a i686 VM, running a Gentoo with CHOST=i586 -> binary package of eix errors with illegal instruction
  * I ditched the VM (to reduce complexity) and changed to a 32-bit Gentoo chroot (on a Arch Linux multilib system). Eix binary package built there still fails with "illegal instruction".
  * I can run eix compiled locally on any of the environments.
  * The only problem is that a binary package compiled in a chroot (or a VM) fails with illegal instruction

I would quickpkg eix on the k6-3 box. Then, I would copy everything to the VM, making the VM a clone of the k6-3 box.

I'm not sure I'm following; what would the point be here? I mean, I can get locally compiled eix to run on the k6-3 box, and I can get eix to run on the chroot (or VM - but I'm not using a VM currently!). The problem is that a eix binary package built on the slave chroot on a more powerful box errors with "Illegal Instruction" on the K6-3 box.

Are you suggesting I'd make a clone of the k6-3 box and start compiling there in a VM? Which VM can run -march=k6-3 code on some processor which does not have the AMD-specific instructions (I believe Virtualbox can not do this)? Would qemu work? I have no previous experience with VMs before this endeavor...

Don't know which VM you are using, but on the virtualbox site there are some instructions for cloning from a harddrive. --

I find cloning hard drives, disks filesystems etc. quite trivial, that is not a problem here. Thanks anyways!

Its not USE=pie if you have the 17.0 profile on the k6-3 and in the build environment.
PIE related issues usually show up at link time, not run time.

Ok, I misunderstood some of the comments on this thread them. I though some were suggesting that binaries compiled with pie enabled might fail on i586 (or -march=k6-3) for some reason, in some situations... or a compilation bug surfaces this way?

The USE=pie flag on gcc is a bit odd as USE flags go.
It controls the default gcc behaviour, when -fpie or -fno-pie are not specified explicitly when gcc is invoked.
On other packages, it changes how the packages are built.

Be aware that setting USE=-pie on gcc will have no effect.
USE=pie is forced on by the profile. It appears as (pie). If you really want to turn pie off, you must first unforce it.

Yes, I think I got how it works, thank you .

FWIW, I unforced pie use flag, and rebuild gcc without pie (and this was reported by emerge as expected). Also emerge -e @system (for the slave build box, and generated the @system packages for the k6-3 box). Actually, I found the command in my history on the chroot slave:

Code: Select all

emerge -uDNvat world
emerge -e @system && COMMON_FLAGS="-O2 -march=k6-3 -pipe -fomit-frame-pointer" FEATURES=buildpkg emerge -eB @system && emerge -e @world

The first one reported the changed use flags for gcc, and recompiled it (along with openssh and pam). I didn't use bootstrap.sh (I figured it is not needed in this case?).

(I know I recompiled things needlessly by running emerge -e @system and emerge -e @world - this was done overnight so I didn't care)

After that emerge -1 --rebuilt-binaries eix on the k6-3 box. Still eix fails with "illegal instruction". However, I didn't install system-wide all binary packages (the k6-3 box is slow even with binary pacakge installations). I will update them with the new non-pie binaries and see if that has any effect.

Here is my build system's make.conf http://dpaste.com/3RXTH3K

Thanks for that, here are mine (again - the only difference to previous should be that I've disabled pie): build slave chroot make.conf and the k6-3 box make.conf.

Some things different:

• * I don't have -m32 in CFLAGS. Didn't see it before anywhere, should I use it on the build slave?
  * As already pointed previously, I've gone the trouble needed to change CHOST to i586.

As suggested previously in this thread by NeddySeagoon, there is another major difference (?), too: systemset is build with -march=i586 and with "FEATURES=-buildpkg", and when I built @system set packages for the k6-3 box, I override these on the command line. I've verifies from the binary pacakges environments and they seem to be built correctly (with -march=k6-3 for the @system set binaries). In case you're curious, see my env/systemset and systemset file.

I could try CHOST=i486 on the build host. I could make another chroot on the k6-3 box (without i586) and install binary packages there and see if they work (maybe I should have done that before!). Any other ideas?

EDIT: Jsut to make sure, my chroot script on the Arch Linux. Anyone spot anything which could cause problems here?

Code: Select all

$ cat chgentoo.sh 
#!/bin/bash


CHROOTDIR=$1

if [ ! -d "$CHROOTDIR" ] ; then
  echo Not dir $CHROOTDIR
  exit 1
fi

mount --types proc /proc/ "${CHROOTDIR}"/proc/
mount --rbind /sys/ "${CHROOTDIR}"/sys
mount --rbind /dev/ "${CHROOTDIR}"/dev
mount --make-rslave "${CHROOTDIR}"/sys/
mount --make-rslave "${CHROOTDIR}"/dev

linux32 chroot "${CHROOTDIR}" /bin/bash -l

umount "${CHROOTDIR}"/proc/ "${CHROOTDIR}"/sys "${CHROOTDIR}"/dev

In any case, thanks for everybodys time! Especially considering this is a completely secondary project for me and in a very fringe compilation environment/situation. Would be nice to see what the error is, however! After all, it could be a gcc (or some other?) bug which only surfaces in specific situations, and could benefit the thing as a whole...

[NeddySeagoon]

ville.aakko,

You don't need -m32. That tells a 64 bit multilib gcc to output 32 bit code.
Likewise -m64 tells gcc to output 64 bit code.
As your gcc in the chroot is 32 bit only -m32 is not required.

For completeness, multlib users build some packages twice, once with -m32 and once with -m64

CHOST= controls the arch the toolchain will run on and is hard coded into the tool chain so that it can find bits of itself.
It has no effect on the code emitted by the toolchain.
A CHOST=i586 toolchain might be marginally faster than a CHOST=i486 toolchain but the time spent doing the conversion will never be regained in faster builds.
Both will emit the same binaries.

Code: Select all

mount --types proc /proc/ "${CHROOTDIR}"/proc/ 

should be -type (no s) but as the type is not used for proc, it will probably have no effect.

[Tony0945]

Are you suggesting I'd make a clone of the k6-3 box and start compiling there in a VM? Which VM can run -march=k6-3 code on some processor which does not have the AMD-specific instructions (I believe Virtualbox can not do this)?

Yes, I was. That is what I do. Effectively I build on a six core 3.2GHZ k6-3. I was not aware of the part that I have bolded. My build box is an AMD Phenom II. All my boxes are AMD, from Socket 7 through AM4.
I missed that yours was not. I probably missed a hyperlink in one of your posts because I need eye surgery and for me, the contrast on hyperlinks in this forum is very poor.

This could be the crux of the problem as, until Ryzen, AMD was backward compatible. Still, cross-compilers exist to build completely different architectures. I recall a major project I headed where PowerPC code was built on IBM PC's running Windows. This use case is not that extreme and there is some common subset (i386/i486/i586).
There are probably redundant/unnecessary items in my make.conf , as NeddySeagoon has pointed out, that entered as I felt my way toward success.
They are just lint. It won't hurt to leave them or omit them.

I'll address the many voluminous points raised since my last post later. I have to leave now on personal business.

[ville.aakko]

I missed that yours was not. I probably missed a hyperlink in one of your posts because I need eye surgery and for me, the contrast on hyperlinks in this forum is very poor.

These kind of threads are difficult to follow as it is. The state the problem was at the beginning is not the same anomore later! Or, I've noticed, at least I have too short of an attention span to follow this kind of threads

This could be the crux of the problem as, until Ryzen, AMD was backward compatible. Still, cross-compilers exist to build completely different architectures. I recall a major project I headed where PowerPC code was built on IBM PC's running Windows. This use case is not that extreme and there is some common subset (i386/i486/i586).
There are probably redundant/unnecessary items in my make.conf , as NeddySeagoon has pointed out, that entered as I felt my way toward success.
They are just lint. It won't hurt to leave them or omit them.

I'll address the many voluminous points raised since my last post later. I have to leave now on personal business.

Thanks for your efforts in any case!

One thing that occurred to me, is that maybe the Kernel I've compiled can cause this issue? In either case, I've put the Kernel config of the running Kernel on the k6-3 box here. Probably not the cause, I believe.

I'm in the process of making another chroot on the k6-3 box, and another build slave chroot, identical to the current config except I will leave CHOST unchanged (at i486) on both. We'll see if that takes us anywhere... if that will work, I will leave CHOST at i486. As pointed out by NeddySeagoon, I will lose little in the process.

I will return to this tomorrow. I also got some other stuff to attend to, soon. Have a nice evening (or whatever time it is where you live), everyone!

[ville.aakko]

EDIT: Nevermind this post! I was confused by virtual/* -etc and some packages just emerge crazy fast on an i7. Leaving it here just for completeness sake...

Ok, I've noticed something peculiar. Not sure how I didn't notice this before!

From earlier in this thread:

So

Code: Select all

emerge -eB @system

will build the system set without installing anything but will make packages with -march=k6-3 for you.

So, I made another chroot (not changing CHOST this time), upgraded it, and started to rebuild packages for the k6-3 box like this:

Code: Select all

COMMON_FLAGS="-O2 -march=k6-3 -pipe -fomit-frame-pointer" FEATURES=buildpkg emerge -eBavt @system

Binary packages are created, but portage does not rebuild anything! It seems it only uses some kind of facility to make packages from the binaries already present on the chroot.

I'm quite certain this does not explain why the "invalid instruction" happens, as the chroot @system set is i586, and as such fine fot the k6-3. However, if some binaries (not in @system) have k6-3 specific optimizations, maybe those don't play well with the rest?

EDIT: I'm not actually sure if there is anything wrong after all. Portage does rebuild gcc, for example. Maybe it intelligently skips compilation for packages which do not have k6-3 specific optimizations, and uses the existing binaries? Still seems weird what I'm observing..

[Hu]

So, I made another chroot (not changing CHOST this time), upgraded it, and started to rebuild packages for the k6-3 box like this:

Code: Select all

COMMON_FLAGS="-O2 -march=k6-3 -pipe -fomit-frame-pointer" FEATURES=buildpkg emerge -eBavt @system

Binary packages are created, but portage does not rebuild anything! It seems it only uses some kind of facility to make packages from the binaries already present on the chroot.

Assuming the emerge --info from your first post is still valid, that is because you told it to do this. You put -g in EMERGE_DEFAULT_OPTS, which implies -k.

[ville.aakko]

Hi Hu,

That's on the retro box. This is on the slave chroot. It does not have -g in the EMERGE_DEFAULT_OPTS, but:

Code: Select all

EMERGE_DEFAULT_OPTS="--jobs 3 --load-average 3.2" 

Thanks anyways!


However, I believe I was mistaken! Some packages are virtual/ -something, some are so small they will compile very fast on the i7. It's just these combined it made be suspect something is wrong, as it was emerging so fast. Looking at process tree, there definitely are .confgure and make jobs there for all packages that actually compile something. I will double check the resulting binaries are actually compiled! So, sorry for the noise!

[ville.aakko]

Ok, I still haven't given up on this, although got other things to do so things are progressing (if you can call this progress) slowly!

Since my last post, I've installed Gentoo in a Pentium MMX VM in Qemu (to rule out a real or a virtual i686 polluting the environment). However, I still get Illegal Instruction while trying to run eix binary compiled in the slave environment on the target k6-3.

The configuration on the slave is exactly the same as on the target, save for protecting the build environment (I'll put links at the end of this post).

I've tried the binaries compiled for the k6-3 on the Pentium VM and they run fine there! As does a binary compiled for the VM. To summarize eix binaries:

• * Binary run on slave, compiled on slave, for slave -> success
  * Binary run on slave, compiled on slave, for target -> success (EDIT:despite compiled with 3dnow!)
  * Binary run on target, compiled on slave, for target -> Illegal instruction
  * Binary run on target, compiled on target (for target) -> success!

To summarize (again), different iterations of the build slave how I got this result:

• * Virtualbox i686 VM, running Gentoo, CHOST=i586-(etc), crossdev for k6-3
  * Arch Linux -> 32bit Gentoo chroot, CHOST=i586-(etc), @system set protected
  * Arch Linux -> 32bit Gentoo chroot, CHOST=i486-(etc), @system set protected
  * QEMU VM, emulated Pentium MMX, running Gentoo, CHOST=i486-(etc), @system set protected

Slave (Qemu VM) /proc/cpuinfo (4 cores enabled to speed up compilation, just once here):

Code: Select all

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 5
model           : 4
model name      : Pentium MMX
stepping        : 3
cpu MHz         : 4006.952
physical id     : 3
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 3
initial apicid  : 3
fdiv_bug        : no
f00f_bug        : yes
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 apic mmx cpuid tsc_known_freq x2apic hypervisor cpuid_fault
bugs            : f00f
bogomips        : 8013.90
clflush size    : 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual

Target:

Code: Select all

cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 13
model name      : AMD-K6(tm)-III Processor
stepping        : 4
cpu MHz         : 501.136
cache size      : 128 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnowext 3dnow k6_mtrr cpuid 3dnowprefetch vmmcall
bugs            : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 1002.03
clflush size    : 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management: ts fid vid

AFAIK no cpu flags which should make a difference. So I believe this rules the hypothesis of i686 code polluting i586 binaries. There must be something in glibc (or gcc libraries), which are slightly different on the target - and the compiled code fails here for some reason (makes wrong assumptions?), but only on the target.

I really don't know what I am supposed to do with gdb. I've enabled split debugging, installed sources for eix, and disabled stripping for everything for the target. So I can get backtraces, but I have no idea what to do with these / how to progress.

We already know the result, which can be seen from this gdb output, save for the backtrace:

Code: Select all

GNU gdb (Gentoo 8.1 p1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from eix...Reading symbols from /usr/lib/debug//usr/bin/eix.debug...done.
done.
(gdb) run
Starting program: /usr/bin/eix

Program received signal SIGILL, Illegal instruction.
_GLOBAL__sub_I_spaces () at eixTk/stringutils.cc:645
(gdb) bt
#0  _GLOBAL__sub_I_spaces () at eixTk/stringutils.cc:645
#1  0x0814ff9f in __libc_csu_init ()
#2  0xb7c10c63 in __libc_start_main () from /lib/libc.so.6
#3  0x08064771 in _start () at eixTk/stringutils.cc:645
(gdb) 

Link to: stringutils.cc

However I'm not sure that is useful, except now I know libc is failing.

• slave make.conf and emerge --info
  target make.conf and emerge --info
  slave system set protection
  slave protected @system set

I'm compiling @system binaries on the slave with:

Code: Select all

COMMON_FLAGS="-O2 -march=k6-3 -pipe -fomit-frame-pointer" emerge -eB @world

The resulting "emerge --info"

Any ideas? Can I get something more usefull out of gdb? Should I enable split debugging for glibc?

Assuming this would be a sensible next step:

If you can isolating the offending instruction, in hexadecimal, I will endeavor to research what 8086 derived instruction it may be. This will take quite a while, but is easier than trying to decipher someone else's code since 90+% of programmer's disdain the idea of properly documenting their code.

How do I do that?

I would be happy to make a bug report, but I have no idea what the failure actually is, what component to report the bug report against - and, this is (perhaps?) somewhat obscure / EOL platform in any case, so I'm not sure anyone is interested - unless, of course, there is something more generic at fault here, which might affect other things, too.

Thanks for all help so far!

p.s. as a subnote, things definitely are/were compiling on the slave, so the previous three posts can be ignored - I was just confused as things were progressing suspiciously fast for smaller packages. I've confirmed the resulting .btz2 packages, and environments, build logs etc. contained are there and set as expected.

[NeddySeagoon]

ville.aakko,

Code: Select all

#3  0x08064771 in _start () at eixTk/stringutils.cc:645 

That file contains 646 lines, so I'm not sure that it points to the function that's failing, just the file.

Can you pastebin the entire build log of one of the versions that fails on the k6-3.
I want to check if the make system is doing something naughty.

A build log from one that works on the k6-3 would be good too.

[ville.aakko]

Hi NeddySeagoon,


Of course I'll be happy to post build logs:

From the slave and the target compiling locally .
Also, environment the slave .


FWIW, I've also compared the environments of the resulting binary packages of eix to locally (on target) compiled, and I've seen nothing out of order there. Also, too a look of the gcc, glibc packages environment.

[ville.aakko]

ville.aakko,

Code: Select all

#3  0x08064771 in _start () at eixTk/stringutils.cc:645 

That file contains 646 lines, so I'm not sure that it points to the function that's failing, just the file.

Yes, I know. I was assuming gdb is working as intended, are you saying it should print something else? That line is the end of a function (string::size_type utf8size(const string &t, string::size_type begin, string::size_type end) {) , though (at least that stringutils.cc source file seems identical at git, though of course I must admit as I've linked to git, this might not be true). Is gdb supposed to print out something else instead?

EDIT: more specifically, I've followed this guide (don't remember why I put in binpkg-dostrip, I believe it is extraneous there). I have in /etc/portage/env/debugsyms:

Code: Select all

CFLAGS="${CFLAGS} -ggdb"
CXXFLAGS="${CXXFLAGS} -ggdb"
FEATURES="${FEATURES} binpkg-dostrip splitdebug compressdebug -nostrip"

and in installsources

Code: Select all

FEATURES="${FEATURES} installsources"

In /etc/portage/package.env/eix:

Code: Select all

app-portage/eix debugsyms installsources

and in FEATURES=nostrip (as per linked make.conf's in the previous post).

This changes have been made on both the slave and the target. Is this correct if attempting debugging eix?

EDIT2:I realized I still had "-fomit-frame-pointer" in COMMON_FLAGS (and CXX, C...). I believe I should have disabled it for debugging, is that correct?

[Tony0945]

I realized I still had "-fomit-frame-pointer" in COMMON_FLAGS (and CXX, C...). I believe I should have disabled it for debugging, is that correct?

I believe that is correct. Certainly it can't hurt. Also, make sure there is no optimization i.e. -O0 not -O2 or -O3 or not even -Os as I like to do on low memory machines. And, I think you should use USE="debug" when building eix. Not sure of the latter. Try it.

For what it's worth, I built eix with no use flags and using gcc 7.3.0 and it worked fine on the target box. But my build machine is a superset of k6 (k10) not i9, so I run the code I build on the build box as well as the target box.

Code: Select all

[I] app-portage/eix
     Available versions:  0.32.4[1] 0.33.7{tbz2} {debug doc nls sqlite}
     Installed versions:  0.33.7{tbz2}(09:37:34 AM 03/28/2019)(sqlite -debug -doc -nls)
     Homepage:            https://github.com/vaeth/eix/
     Description:         Search and query ebuilds

I'm suspecting a bug in qemu or the qemu setup.

[ville.aakko]

Hi Tony,

Thanks for your input. I will remove -fomit-frame-pointer and try debugging again, and get back to this.

I'm suspecting a bug in qemu or the qemu setup.

If you will read my previous post, you'll notice this has been reproduced in various different environments, such as a 32 bit chroot, VirtualBox VM, and only at the last time in QEMU VM. I suspect this is not a QEMU bug but something more generic failing at compile time.

I don't have HW which would be a superset of the K6-3 (my other computer is Intel). Any suggestions to get a working compiler slave (from not a superset CPU environment), are welcome.

FWIW, I've yet to see anyone here who is using gcc 8.X compilig for a K6 box. MAybe this is a GCC (8.X) bug?

Thanks!

[Tony0945]

FWIW, I've yet to see anyone here who is using gcc 8.X compilig for a K6 box. MAybe this is a GCC (8.X) bug?
Thanks!

Ah! I used 4.9 for a long time, recently changing to 7.3.0 But I didn't rebuild everything. I'll experiment when I can.

Didn't you say above that building on the k6 box worked? What was your compiler, binutils, and glibc versions and exact CFLAGS, if you didn't give them above. IIRC, all building on the k6 worked and all building off the k-6 didn't work. Unfortunately I don't have an Intel chip to work with. My only Intel is my i486DX-100 and the mobo failed a long time ago. I still have the box though. I hate to throw anything away. The monitor is gone because the CRT failed.

[ville.aakko]

Didn't you say above that building on the k6 box worked? What was your compiler, binutils, and glibc versions and exact CFLAGS, if you didn't give them above. IIRC, all building on the k6 worked and all building off the k-6 didn't work. Unfortunately I don't have an Intel chip to work with. My only Intel is my i486DX-100 and the mobo failed a long time ago. I still have the box though. I hate to throw anything away. The monitor is gone because the CRT failed.

Hi,

I have linked them above:

• slave make.conf and emerge --info
  target make.conf and emerge --info
  slave system set protection
  slave protected @system set

The CFLAG, glibc, gcc, binutil versions are exactly the same. Only differences in make.conf are because the other one looks for binary packages via ssh from the compiler slave, and the system set is protected on the slave. I override these protections when compiling @system set for the target (however, that part is kind of irrelevant since the exact same issue was present in many different situations; again: crossdev in a Gentoo VM, 32bit chroot without crossdev, and now a VM (Pentium target CPU) without crossdev).


Also, noticed a small error (fixed in my post also):

• * Binary run on slave, compiled on slave, for slave -> success
  * Binary run on slave, compiled on slave, for target -> success (EDIT:despite compiled with 3dnow!)
  * Binary run on target, compiled on slave, for target -> Illegal instruction (Above comment about 3dnow! was erroneously here ... by which I mean -march=k6-3)
  * Binary run on target, compiled on target (for target) -> success!

[Tony0945]

Aha! Paydirt! I built packages for eix on my K10 fake k6 box and transferred them to my real k6.

"eix -e" built on the build box using gcc 8.2.0 fails with "illegal instruction"
"eix -e" built on the build box using gcc 8.3.0 fails with "illegal instruction"
"eix -e" built on the build box using gcc 7.3.0 (I think?) succeeds

"eix -e" built on the k6 box using gcc 4.9.4 succeeds

I have to very that third result by building on the build box with 4.9.4 6.4.0 and 7.30
Building eix native on the k6 with 8.2.0 now.

EDIT: still building at 5:54PM. k6 builds S-L-O-W

EDIT2: "eix -e" build on target (k-6 box) using gcc 8.2.0 succeeds!

I think there is a bug in gcc-8.2.0

I will build eix on the build box using gcc 6.4.0, 7.3.0, and 4.9.X , transfer the packages to the build box and run them. Probably on Sunday.

If you have a gcc version prior 8.X try it yourself. (Sorry, I didn't scroll up to check). I'll still do my tests since they impact my build on K10 run on k-6 situation.

[ville.aakko]

Hi Tony0945!

Your results are identical to mine (just confirming)!

I believe I could of course install 7.3.0 (on all of the boxes), and rebuild relevant toolchain (from the top of my head, I'm not sure do I need bootstrap.sh or is emerge -1 bintools glibc enough... reading trough https://wiki.gentoo.org/wiki/Upgrading_GCC - but it doesn't mention if downgrading is a special case).

In any case, do you (everyone reading this thread) think this is enough information for a bug report (against gcc)?

[NeddySeagoon]

ville.aakko,

Ideally, a trivial test case is required. You have a file in a program. That's a great help to debugging.
A function would be even better and a line of code better still.

Include in your bug report the entire content of the file that causes the fail.
Also include the Illegal Instruction Exception report in dmesg.

Before you post a new bug, search existing reports in case you should be adding to an existing report.

Be sure to listen for requests for more info and patch testing too.

The build log might be useful too. That's why I was asking for a good and bad build log.
The workaround may be a -mno-<something> in CFLAGS.

[Tony0945]

Just to be sure I built eix packages on the build box for all five compilers and transferred them directories on the target box.

Then I ran them, but I wasn't sure I hadn't made a mistake running them, so I spent the last four hours writing and debugging a test script. (I'm very bad at shell)
This shows that I built five different packages:

Code: Select all

 
rw-r--r-- 1 portage portage 464998 May 27 13:39 gcc-4.9.4/eix-0.33.7.tbz2
-rw-r----- 1 portage portage 468430 May 27 13:31 gcc-6.4.0/eix-0.33.7.tbz2
-rw-r--r-- 1 portage portage 471249 May 27 13:35 gcc-7.3.0/eix-0.33.7.tbz2
-rw-r--r-- 1 portage portage 466906 May 27 13:41 gcc-8.2.0/eix-0.33.7.tbz2
-rw-r--r-- 1 portage portage 467116 May 27 13:44 gcc-8.3.0/eix-0.33.7.tbz2

This is the results:

Code: Select all

gcc-4.9.4 "eix -e eix "succeeded
gcc-6.4.0 "eix -e eix "succeeded
gcc-7.3.0 "eix -e eix "succeeded
gcc-8.2.0 "eix -e eix " failed with return code 1
gcc-8.3.0 "eix -e eix " failed with return code 1

The failure message was "illegal instruction"

This is the script:

Code: Select all

#! /bin/bash

echo " ">results
for i in 4.9.4 6.4.0 7.3.0 8.2.0 8.3.0
do
  	rm  /usr/portage/packages/app-portage/eix*
        cp  /root/packages/gcc-${i}/eix-0.33.7.tbz2  /usr/portage/packages/app-portage/
        emerge -1v eix --binpkg-respect-use=n

	eix -e eix 
        RETVAL=$?
        if [ $RETVAL -eq 0 ]; then
                echo "gcc-${i} \"eix -e eix \"succeeded" >>results
        else
            	echo "gcc-${i} \"eix -e eix \" failed with return code $?" >>results
        fi
done