Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
cross-compiling eix for k6 [WORKAROUND:use gcc<8]
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Tue May 28, 2019 7:30 am    Post subject: Reply with quote

Hi Tony and NeddySeagoon!

NeddySeagoon wrote:
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.


I've red the bug reporting instructions at https://www.gnu.org/software/gcc/bugs/ and I believe I need to pinpoint the actual failure. I'm not sure how to go about that. Need to read some documentation / Google around :-) Any pointers what it is I should actually do at this point? Should I be looking at the .o files in the source dir? With what? How do I know where gcc has actually failed?

If it is helpful, eix (or any binary in eix) fails as soon as run. No matter even if I try "eix --help" - unless compiled locally, or with gcc-7.3.0.

NeddySeagoon wrote:

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

I did find while I searched for "march k6" this : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88906

I'm really lost while reading that bug report :lol:

I have no idea if it is related (or not). The version numbers kind of match, and supposedly fixed in "8.3.0+ too". Maybe that doesn't include 8.3.0, then?

NeddySeagoon wrote:

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.


I already posted build logs from the slave (which will fail on the target) and the locally compiled (on target) build log.

ville.aakko wrote:

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


The problem here is, there is no failure in the build logs (AFAICT)!

(I noticed the build logs don't include gcc versions; I believe they are 8.2.0 or 8.3.0 - they should be the same, although at one point my slave was using gcc-8.3.0 and the target 8.2.0 by mistake (forgot to run eselec/gcc-config) - but the target should not be compiling anyways).

I have no idea what kind of -mno-<something> I could try.

FWIW I build eix on the build slave with FEATURES=keepwork with gcc 7.3.0, 8.2.0 and 8.3.0 (these latter two fail while run on the target only!), and this time copied the workdirs away from the temp dir for later inspections :-) . I can post any of those logs again, if that is needed (or compile on the target with any gcc version).

However, I noticed this (on the compiler slave):

Code:
diff -Naur ./gcc-7.3.0-portage-work-app-portage-eix-0.33.7/temp/build.log ./gcc-8.2.0-portage-work-app-portage-eix-0.33.7/temp/build.log
--- ./gcc-7.3.0-portage-work-app-portage-eix-0.33.7/temp/build.log      2019-05-28 00:51:42.408910076 +0300
+++ ./gcc-8.2.0-portage-work-app-portage-eix-0.33.7/temp/build.log      2019-05-28 00:50:42.284726331 +0300
@@ -84,9 +84,9 @@
 checking whether CXXFLAGS=-mindirect-branch=thunk is known... yes
 checking whether CXXFLAGS=-mfunction-return=thunk is known... yes
 checking whether CXXFLAGS=-mcet is known... no
-checking whether CXXFLAGS=-fcf-protection=full is known... no
-checking whether CXXFLAGS=-fstack-clash-protection is known... no
-checking whether CXXFLAGS=-D_FORTIFY_SOURCE=2 is known... no
+checking whether CXXFLAGS=-fcf-protection=full is known... yes
+checking whether CXXFLAGS=-fstack-clash-protection is known... yes
+checking whether CXXFLAGS=-D_FORTIFY_SOURCE=2 is known... yes
 checking whether ln -s works... yes
 checking for a sed that does not truncate output... /bin/sed
 checking whether NLS is requested... yes
@@ -257,7 +257,7 @@
 CXX: i586-pc-linux-gnu-g++
 
 CXXFLAGS: -O2 -march=k6-3 -pipe -fomit-frame-pointer -ggdb -std=c++14
-PREPEND_CXXFLAGS: -fdata-sections -ffunction-sections -mindirect-branch=thunk -mfunction-return=thunk
+PREPEND_CXXFLAGS: -fdata-sections -ffunction-sections -mindirect-branch=thunk -mfunction-return=thunk -fcf-protection=full -fstack-clash-protection -D_FORTIFY_SOURCE=2
 
 LDFLAGS: -Wl,-O1 -Wl,--as-needed
 PREPEND_LDFLAGS: -Wl,--gc-sections


Other differences in the build logs were mostly because the source was compiled in different order (nothing out of order AFAICT - I could temporarily set MAKEOPTS=-j1 to alleviate that).

I could try without "-fcf-protection=full -fstack-clash-protection" to see if that makes a difference.

Cheers!

EDIT: Cleared a few TYPOs and possible ambiquities
_________________
- Ville
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43012
Location: 56N 3W

PostPosted: Tue May 28, 2019 9:36 am    Post subject: Reply with quote

ville.aakko,

Both the build lines for the failing file are the same.
i486-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -DSYSCONFDIR=\"/etc\" -DLOCALEDIR=\"/usr/share/locale\" -fdata-sections -ffunction-sections -mindirect-branch=thunk -mfunction-return=thunk -fcf-protection=full -fstack-clash-protection -D_FORTIFY_SOURCE=2 -O2 -march=k6-3 -pipe -fomit-frame-pointer -ggdb -std=c++14 -c -o eixTk/stringutils.o eixTk/stringutils.cc

The
Code:
i486-pc-linux-gnu-g++
shows that you have not done the CHOST dance, or if you have, the i486 CHOST tool chain is still selected.
Code:
-mindirect-branch=thunk -mfunction-return=thunk
is for defeating speculative execution. Can the k6-3 do speculative execution?
Code:
-ggdb
tays to include debugging symbols.
Code:
-O2 -fomit-frame-pointer
includes optimisations that make using gdb difficult going on impossible.

The two gcc commands are identical, that strongly suggests that different versions of gcc are doing something different.

The gcc man page says
Code:
           i586
           pentium
               Intel Pentium CPU with no MMX support.

           pentium-mmx
               Intel Pentium MMX CPU, based on Pentium core with MMX
               instruction set support.

           ...

           k6  AMD K6 CPU with MMX instruction set support.

           k6-2
           k6-3
               Improved versions of AMD K6 CPU with MMX and 3DNow! instruction
               set support.


Does it work with -march=i586 ?
If that works, you can add in the -mmmx and -m3dnow

For testing, you only need to build eix in the build chroot, so it should be fairly fast.

-march=k6-3 should be the same as
Code:
-march=i586 -mmmx  -m3dnow


-- edit --

Maybe not. I suspect the scheduling is different between -march=i586 and -march=k6 so -march=k6 may be a better place to start.
If you want to start from the other end, -mno-mmx turns off mmx and so on.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3031
Location: Illinois, USA

PostPosted: Tue May 28, 2019 2:20 pm    Post subject: Reply with quote

NeddySeagoon wrote:
-march=k6-3 should be the same as
Code:
-march=i586 -mmmx -m3dnow

No, because the optimum sequence of instructions for a Pentium is definitely not optimal for a k6. That caused the k6 family to perform poorly on windows as most code was optimized for Pentium.

This might work:
Quote:
-march=i586 -mmmx -m3dnow -mtune=k6
assuming it does what I think.
But it appears that GCC 8.x is leaking the build instruction set into the target or that some register or stack is overflowing because of improper handling of m32. The latter seems less likely. I can see a developer thinking "I'll hard code this sequence, every x86 supports it" when, in fact, every x86 doesn't.
Looking into the kernel code for support of the chipset of my AM4 board, I found that substantial stylistic rewrites (that do exactly the same thing) are fairly common in the kernel code ("Real men do it their way"). I suspect gcc code is the same.

It would be good to nail down the illegal instruction and at what line of code it appears for the bug report.
It would be a good exercise for the OP to re-compile eix with -O0 and debug support, verify that the bug still exists (trivially running "eix -e eix" on the target), then running gdb to find the offending line and machine instruction.
It would be a good exercise for me too, since I have rarely used gdb.
I'll do so, for my own edification, but it may take a few days again because of pressing personal business.

Meanwhile, I urge the OP to switch back to gcc-7.3.0 or earlier for his k6-3 build box.
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Sun Jun 02, 2019 7:14 pm    Post subject: Reply with quote

NeddySeagoon wrote:

Both the build lines for the failing file are the same.
i486-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -DSYSCONFDIR=\"/etc\" -DLOCALEDIR=\"/usr/share/locale\" -fdata-sections -ffunction-sections -mindirect-branch=thunk -mfunction-return=thunk -fcf-protection=full -fstack-clash-protection -D_FORTIFY_SOURCE=2 -O2 -march=k6-3 -pipe -fomit-frame-pointer -ggdb -std=c++14 -c -o eixTk/stringutils.o eixTk/stringutils.cc

The
Code:
i486-pc-linux-gnu-g++
shows that you have not done the CHOST dance, or if you have, the i486 CHOST tool chain is still selected.

What I have done during the duration of this thread has become quite difficult to follow :lol: . I tried to summarize things in this post. In short, I created yet-another-chroot environment during my "shotgun and mortar" -approach to this problem, where the chroot is still i486. I created another chroot on the target box (I forgot to mention this earlier). Obviously (Not) changing the CHOST had no effect.
_________________
- Ville
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Sun Jun 02, 2019 7:17 pm    Post subject: cross-compiling eix for k6 [WORKAROUND:use gcc<8] Reply with quote

Hi Tony and NeddySeagoon again!

Tony0945 wrote:

It would be good to nail down the illegal instruction and at what line of code it appears for the bug report.
It would be a good exercise for the OP to re-compile eix with -O0 and debug support, verify that the bug still exists (trivially running "eix -e eix" on the target), then running gdb to find the offending line and machine instruction.
It would be a good exercise for me too, since I have rarely used gdb.
I'll do so, for my own edification, but it may take a few days again because of pressing personal business.

Meanwhile, I urge the OP to switch back to gcc-7.3.0 or earlier for his k6-3 build box.


I will be using gcc-7.3.0 from now on (on the slave chroot) to work around this (actually, already have been since we noticed this).

I believe using gdb to nail down where the error actually is, is a bit over my head - unless someone here is willing to walk trough it with me. Looking forward to your efforts, if you can find the error!

FWIW, I re-compiled eix with -O0 and no -fomit-frame-pointer. The whole build log is available here, in case I made an error while building. I changed CFLAGS and CXXFLAGS via /etc/portage/env/debugsymbols (which is enabled for eix).

But, gdb still doesn't give any more useful output:

Code:
(gdb) run
Starting program: /usr/bin/eix

Program received signal SIGILL, Illegal instruction.
_GLOBAL__sub_I_spaces () at eixTk/stringutils.cc:645
645     }
(gdb) q
A debugging session is active.


Maybe I'm still not compiling eix correctly for debugging?

Looking forwards to Tony0945's efforts on this. Or I could debug this further myself if someone can walk me trough it!

But I'll be using 7.3.0 as a workaround. Will change subject accordingly!

EDIT:I could try the different -march and -mtune options as suggested, but it is getting a bit late here. And, not sure if that is useful, as I think what is needed for a proper bug report is to get useful output from gdb. Also, I could try gcc>8.3.0, in case this is related to the bug report I posted, but there is none yet in portage.
_________________
- Ville
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3031
Location: Illinois, USA

PostPosted: Sun Jun 02, 2019 8:08 pm    Post subject: Re: cross-compiling eix for k6 [WORKAROUND:use gcc<8] Reply with quote

ville.aakko wrote:
FWIW, I re-compiled eix with -O0 and no -fomit-frame-pointer. The whole build log is available here, in case I made an error while building. I changed CFLAGS and CXXFLAGS via /etc/portage/env/debugsymbols (which is enabled for eix).

But, gdb still doesn't give any more useful output:

Same here. I looked at the (rather simple) source code and I'm wondering if the problem isn't the default C++ version.
Also, not sure if glib was built with same version since the debugging I've done seems to show thew problem is in libc.so.6
But I'm still working on it! (in between other obligations)
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43012
Location: 56N 3W

PostPosted: Sun Jun 02, 2019 8:23 pm    Post subject: Reply with quote

ville.aakko,

Look at the function names in the stringutils.cc file.
Set breakpoints in gdb at the entry points of each function.
Tell gdb to run.

When one of your breakpoints is encountered gdb will stop the code executing.
You can now single step it. gdb can show the source code that its executing.
When you get the the illegal instruction, the source line will still be on the screen.

That's far easier to say than to do. I'm not a gdb user.

Code:
man gdb
looks useful. In particular,
Code:
break [file:]function
    Set a breakpoint at function (in file).
c

Continue running your program (after stopping, e.g. at a breakpoint).

next

Execute next program line (after stopping); step over any function calls in the line.

step

Execute next program line (after stopping); step into any function calls in the line.

_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3031
Location: Illinois, USA

PostPosted: Sun Jun 02, 2019 10:27 pm    Post subject: Reply with quote

I miss my old GUI debuggers. Of course, I think they cost like $6,000 per seat to license. But then my employer (actually their clients) was paying.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3031
Location: Illinois, USA

PostPosted: Fri Jun 07, 2019 3:24 am    Post subject: Reply with quote

No easy fixes here. It seems to blow up almost immeditely in glibc. So I tried to build glibc with debugging info.
The ebuild cranked for a while then blew up with
Code:
{standard input}: Assembler messages:
{standard input}: Error: `loc1@GLIBC_2.0' can't be versioned to common symbol 'loc1'
{standard input}: Error: `loc2@GLIBC_2.0' can't be versioned to common symbol 'loc2'
{standard input}: Error: `locs@GLIBC_2.0' can't be versioned to common symbol 'locs'

I'd pastebin the build.log but it's four megabytes.

I tried again with gcc 7.3.0 with the same results.

Sorry, this isn't going to be quick.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum