Hi Ken,
On Tue, 2020-04-14 at 18:50 +0100, Ken Moffat wrote:
> > > > Oh boy, I'm so glad to have tested my rpms on a VM before doing it
> > > > on
> > > > the real system but now, I would like to have some help to find a
> > > > solution to my SIGSEGV issue.
> > > >
> > > > Again, I have few ideas of things to try out:
> > > > 1. I'm guilty of having built glibc with -march=native
> > > > -mtune=native
> > > > which translate to sandybridge. My QEMU host is a skylake
> > > > processor.
> > > > Maybe despite using QEMU switch (-cpu SandyBridge), some unique
> > > > SandyBridge instructions aren't well emulated by QEMU. I'm going to
> > > > rule out this possibility by rebuilding glibc without those evil
> > > > switches and report back my findings if someone in the list tells
> > > > that
> > > > he would be interested to know.
> > >
> > > I don't think so. It should cause SIGILL instead of SIGSEGV.
> >
> > If it was happening to a real machine, what you say makes sense and
> > this is what I would expect as well. This comment did make me doubt
> > that trying out recompiling glibc without '-march=native -mtune=native'
> > would do anything.
> >
> > but I did nonetheless and it did work! No more SEGV. Perhaps the QEMU
> > machine emulation isn't 100% accurate.
> >
>
> That seems very possible, particularly if your qemu is old.
My desktop is running ArchLinux, therefore everything is bleeding edge:
$ pacman -Qs qemu
local/qemu 4.2.0-2
A generic and open source machine emulator and virtualizer
>
> > This has been a big lesson. I'll think twice from now on before
> > compiling a system library with those switches. Using them to build a
> > program is ok. If it fails down the road, no big deal. but a system
> > library, especially glibc, it is asking for trouble. Maybe if it is
> > your computer, you can get away with it.
> >
> > My production CentOS is also a VM. My SandyBridge build was working
> > fine on that machine but the VM could be moved on a new machine anytime
> > without prior notice and instantly become bricked as it did happen on
> > my test VM.
> >
> > That is my big lesson here. Dont' use those evil switches...
> > >
>
> On real hardware, -march=native -mtune=native generally provides
> speed-ups. There has been case where (from memory) an old version
> of gcc with newer hardware misidentified what it could use and did
> not use some options it could have used - in that case, specifying
> a slightly earlier machine type was faster.
>
> For real hardware, the possible problem is that you may not be able
> to move the binaries to a newer machine.
>
> On my own machines I definitely use -march=native with glibc (and
> with almost everything) to try to recover some of the loss from
> hardening the build.
>
> But on a VM ? Even if the toolchain agrees that the current VM is a
> SandyBridge, who knows what will turn up if hte VM is migrated.
You are 100% correct. My first laptop was an Atom based HP mini laptop.
I extracted a lot of satisfaction to squeeze out the most of that small
computer. recompiling key libs with -mtune=native was one of the mean
along with running a Con Kolivas patched kernel compiled with the
march/mtune switches.
If there is a big takeaway here is knowing when to use those switches
and when avoiding them. Clearly using them for widely used system libs
on a VM where you don't control the underneath platform should be a big
no-no.
As a closing comment, I don't know exactly what did it because I did
the following 2 things:
1. Upgrade system glibc to 2.25
2. compile the latest 2.25 git branch with a lot of fixes since the
official 2.25 release (2017-02-05).
As a result, my system is still running :-)
and I got rid of the weird dl issue that I reported in my first email:
relocation error: /home/juicingf/dev/glibc-
install/home/juicingf/lib/libc.so.6: symbol _dl_find_dso_for_object,
version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with
link time reference
I tend to stretch to the possible maximum my machines. I have a very
old desktop. Running my app on the CentOS VM is crazy fast compared to
what I'm used to. All the trouble was worth the result!
Talk soon LFS champs!
Olivier
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
