ASM doesn't build on Fedora about visualboyadvance-m

[ZachBacon]

The asm flags recently changed in cmake.
ENABLE_ASM now controls enabling asm scalers and cores.
If asm is causing the issues I suggest throwing in -DENABLE_ASM=OFF

[Mystro256]

I think I see the issue, I believe 7b0baad fixed the 32bit detection, and before my 32bit builds weren't actually building ASM by default. I'll fix the issue title.

[rkitover]

@Mystro256 trying to take a look at this now.

I have a 64bit fedora VM, so I'm teaching ./installdeps and cmake to support making 32 bit builds on 64 bit hosts, this is a bit tricky because of how the multiarch wxGTK3 packages are set up, but I'll figure something out today.

[rkitover]

@Mystro256 well, I'm still at it, you can see what I have so far in the cross-32bit branch. It almost finishes building, but then 32bit libs which are deps of the main deps are missing, so I need to figure out how to make ./installdeps install them.

As far as your asm issue, I think I may know what the problem is. For me on rawhide, I do not get this problem. At least vbamcore gets linked successfully.

Can you try cherry-picking 01b388e and seeing if the build works?

[rkitover]

@Mystro256 this is the issue I ran into getting 32 bit cross builds to work on Fedora in case you were wondering:

https://lists.fedoraproject.org/archives/list/[email protected]/thread/AUELI2MN3VLCBWACS6ASHBR5G7DEWYY3/#AUELI2MN3VLCBWACS6ASHBR5G7DEWYY3

I'll figure something out.

[Mystro256]

01b388e seems to work great.

I'm not sure what's the best way to cross build on fedora, as I've always used a chroot with a minimum 32bit buildroot. It's also what's used on the fedora build servers to cross compile. It tends to be the "cleanest" way of doing it, albeit not the most convenient.

[rkitover]

@Mystro256 awesome, I actually did just get it working, although this an ugly hack 😃

here: aa5b7d1

[Mystro256]

On second thought, it maybe too ugly ;)
When testing the binaries, it seems like it crashes on starting a game, which I tried with and without using filters.

Throwing it through Fedora's static package/binary analyser, I get this warning output:

visualboyadvance-m.i686: W: executable-stack /usr/bin/visualboyadvance-m
visualboyadvance-m-sdl.i686: W: executable-stack /usr/bin/vbam

executable-stack:
The binary declares the stack as executable. Executable stack is usually an
error as it is only needed if the code contains GCC trampolines or similar
constructs which uses code on the stack. One common source for needlessly
executable stack cases are object files built from assembler files which don't
define a proper .note.GNU-stack section.

[rkitover]

Yeah I get a crash on startup on my rawhide VM with a 32 bit build too.

I'm not sure we've tested the asm on linux yet, it works fine on windows.

[rkitover]

Here is the backtrace, it looks to be asm core related:

(gdb) where
#0  0x081b79f0 in thumb20(uint32_t) (opcode=<optimized out>) at /home/rkitover/src/visualboyadvance-m/src/gba/GBA-thumb.cpp:908
#1  0x081c4072 in thumbExecute() () at /home/rkitover/src/visualboyadvance-m/src/gba/GBA-thumb.cpp:2153
#2  0x081af05c in CPULoop(int) (ticks=250000) at /home/rkitover/src/visualboyadvance-m/src/gba/GBA.cpp:3748
#3  0x0815e148 in GameArea::OnIdle(wxIdleEvent&) (this=<optimized out>, event=...) at /home/rkitover/src/visualboyadvance-m/src/wx/panel.cpp:1066
#4  0xf68b5cb8 in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () at /lib/libwx_baseu-3.0.so.0
#5  0xf6a7c494 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () at /lib/libwx_baseu-3.0.so.0
#6  0xf6a7c5de in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /lib/libwx_baseu-3.0.so.0
#7  0xf6a7cab3 in wxEvtHandler::TryHereOnly(wxEvent&) () at /lib/libwx_baseu-3.0.so.0
#8  0xf6a7cb64 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at /lib/libwx_baseu-3.0.so.0
#9  0xf6a7cbe5 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib/libwx_baseu-3.0.so.0
#10 0xf6a7c8ae in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at /lib/libwx_baseu-3.0.so.0
#11 0xf6ec4a56 in wxWindowBase::HandleWindowEvent(wxEvent&) const () at /lib/libwx_gtk3u_core-3.0.so.0
#12 0xf6ec4aef in wxWindowBase::SendIdleEvents(wxIdleEvent&) () at /lib/libwx_gtk3u_core-3.0.so.0
#13 0xf6ec4ac2 in wxWindowBase::SendIdleEvents(wxIdleEvent&) () at /lib/libwx_gtk3u_core-3.0.so.0
#14 0xf6d1869e in wxFrame::SendIdleEvents(wxIdleEvent&) () at /lib/libwx_gtk3u_core-3.0.so.0
#15 0xf6d641e4 in wxAppBase::ProcessIdle() () at /lib/libwx_gtk3u_core-3.0.so.0
#16 0xf6c718f9 in wxApp::DoIdle() () at /lib/libwx_gtk3u_core-3.0.so.0
#17 0xf6c71a2f in wxapp_idle_callback () at /lib/libwx_gtk3u_core-3.0.so.0
#18 0xf4627dc3 in g_idle_dispatch () at /lib/libglib-2.0.so.0
#19 0xf462c029 in g_main_context_dispatch () at /lib/libglib-2.0.so.0
#20 0xf462c450 in g_main_context_iterate.isra () at /lib/libglib-2.0.so.0
#21 0xf462c801 in g_main_loop_run () at /lib/libglib-2.0.so.0
#22 0xf4d08b0d in gtk_main () at /lib/libgtk-3.so.0
#23 0xf6c95d75 in wxGUIEventLoop::DoRun() () at /lib/libwx_gtk3u_core-3.0.so.0
#24 0xf6903062 in wxEventLoopBase::Run() () at /lib/libwx_baseu-3.0.so.0
#25 0xf68bdaf7 in wxAppConsoleBase::MainLoop() () at /lib/libwx_baseu-3.0.so.0
#26 0xf6d640ff in wxAppBase::OnRun() () at /lib/libwx_gtk3u_core-3.0.so.0
#27 0xf6961069 in wxEntry(int&, wchar_t**) () at /lib/libwx_baseu-3.0.so.0
#28 0xf6961db6 in wxEntry(int&, char**) () at /lib/libwx_baseu-3.0.so.0
#29 0x080a995f in main(int, char**) (argc=<optimized out>, argv=0xffaa2ce4) at /home/rkitover/src/visualboyadvance-m/src/wx/wxvbam.cpp:32
(gdb) 

Building with -DENABLE_ASM_CORE=OFF fixes the issue, the asm core is inline assembly in the core and not .asm files.

[Mystro256]

Perhaps it would be wise to consider disabling ASM by default for Linux if it doesn't work on other distros.

[rkitover]

Well I pretty much have my 32 bit cross-build support working Fedora, I will try Arch today and maybe Ubuntu. I should be able to get something working on Arch, but I'm not sure about Ubuntu, Debian multi-arch is really really bad.

So I will try that and get back to you about whether it works on other distros.

The asm filters are not effected by this by the way, and those are the .asm files, this is only asm core related (the ARM CPU implementation in inline assembly.)

That said, it may be a good idea to disable the ASM core entirely, this is another issue that's related to it: #54 and that's on Windows.

[rkitover]

@Mystro256 got 32 bit cross builds working on Arch, can confirm the same ASM core crash.

[Mystro256]

Gotcha, maybe change the default for now? Unless you would prefer to fix it.

…

On March 18, 2017 5:08:19 PM EDT, Rafael Kitover ***@***.***> wrote: @Mystro256<https://github.com/Mystro256> got 32 bit cross builds working on Arch, can confirm the same ASM core crash. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#98 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AATWuEiQAySPjebNDEIsZjznS_IfPSsuks5rnEfDgaJpZM4MgIvL>.

[rkitover]

@Mystro256 pushed e1c1a5c and 6af5525 to master, will wait for you to confirm that this fixes your 32 bit Fedora build.

[Mystro256]

Seems to work for me, no issues from what I can see.

Although on a side note, I've noticed I still get this executable-stack warning, which I have no idea what's causing it. I'm not sure if this affects older builds, as I haven't actually been looking at the warnings for the 32bit builds.

[rkitover]

@Mystro256 I'll look into it, I wanted to add support for yasm anyway.

[rkitover]

@Mystro256 this is fixed in master in 5d4ce82 , as per:

https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart

[rkitover]

@Mystro256 is your 32 bit fedora build free of warnings now? Let me know and I will close thos.

[Mystro256]

Sorry I've been meaning test this but I haven't had time over the last week. I'll try to get it done no later than this weekend.

[Mystro256]

Sorry again for the delay, but looks good to me. Thanks for your help.

[ZachBacon]

Thanks for testing.