Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gollvm: add 32bit (i386) port #40244

Open
advancedwebdeveloper opened this issue Jul 16, 2020 · 13 comments
Open

gollvm: add 32bit (i386) port #40244

advancedwebdeveloper opened this issue Jul 16, 2020 · 13 comments
Milestone

Comments

@advancedwebdeveloper
Copy link

@advancedwebdeveloper advancedwebdeveloper commented Jul 16, 2020

What version of Go are you using (go version)?

$ go version

go1.14.4

Does this issue reproduce with the latest release?

Not yet - that is yet to be implemented

What operating system and processor architecture are you using (go env)?

386
Intel® Core™2 Quad CPU Q9400

Suggesting patches, while would allow https://go.googlesource.com/gollvm/ to support 32bit version of Golang.
Currently suggesting tests on Linux (Fedora 25; Ubuntu 16) and Windows 10 (32bit).

Ivan

@ianlancetaylor ianlancetaylor changed the title 32bit (i386) port for gollvm gollvm: add 32bit (i386) port Jul 16, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 16, 2020

CC @thanm @cherrymui

I'm not clear: do you have patches to send? Thanks.

@ianlancetaylor ianlancetaylor added this to the gollvm milestone Jul 16, 2020
@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 16, 2020

@ianlancetaylor , I am on my way to find what to patch. Would require some verification from the committers.

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 16, 2020

In driver/GollvmOptions.td:
https://go.googlesource.com/gollvm/+/refs/heads/master/driver/GollvmOptions.td?autodive=0%2F#350 and https://go.googlesource.com/gollvm/+/refs/heads/master/driver/GollvmOptions.td?autodive=0%2F#352 appear to be pretty related.
I am not clearly understanding the purpose of mx32 flag. Is it for i686? Or that is something for pointing on a scenario for compiling 32bit binary/libraries on 64bit machine?
Some comments would be much appreciated at https://go.googlesource.com/gollvm/+/refs/heads/master/driver/GollvmOptions.td?autodive=0%2F#355.

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 17, 2020

In cmake/modules/LibbacktraceUtils.cmake :
https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibbacktraceUtils.cmake?autodive=0%2F%2F#8 has no options for Intel's i686 and i386 CPUs.
Regarding
message(SEND_ERROR "Libbacktrace config setup not implemented for ${goarch}"
on https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibbacktraceUtils.cmake?autodive=0%2F%2F#15 : there is no message for end-users regarding whether this should be an issue of gollvm project or that is the responsibility of libbacktrace project.
@ianlancetaylor , please help to resolve this.

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 17, 2020

In cmake/modules/GoVars.cmake :
https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#8 has no hardcode scenarios for i686 and i386 architectures.
Line https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#15 should have both llarch and goarch logged.
Similar situation around https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#24 .
Week strategy to rely on linker's/loader's naming convention, at https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#31.
Line https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#29 should have underlying comments on what/where tracing is available, since that is an external library - so a tryout on loading a specific one (that should be trackable thew stdout) would be observable.
No blocks of code are dealing with i686 and i386 - a good reason to patch here.

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 17, 2020

In cmake/modules/AutoGenGo.cmake :
Two elseif blocks (i386 and i686 related ones) should added somewhere after https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/AutoGenGo.cmake?autodive=0%2F#63.
More democracy should be reflected at https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/AutoGenGo.cmake?autodive=0%2F#65 and, eventually, amd64 and aarch64 wouldn't be the only reflected architectures.
Some status and URLs for issues, related to other architectures, could be messaged here.

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 17, 2020

  • In driver/CompileGo.cpp :

Function CompileGoImpl::setCConv() , at https://go.googlesource.com/gollvm/+/refs/heads/master/driver/CompileGo.cpp#816 should have switches for i386 and i686 related scenarios.
I am unsure how CallingConv::... should look like - I am unsure if I can find where their definitions are defined (headers).
Is it coming from LLVM's libraries?

  • In driver/Driver.cpp :
    There should be some de-facto separated sub-folders for i386 and i686 in the directory/folder hierarchy (where?), to satisfy definitions at https://go.googlesource.com/gollvm/+/refs/heads/master/driver/Driver.cpp#67.
    As for
    // NOTE: set aarch64's lib dir to "lib64" temporarily, until necessary // change is made to cmake module files
  • that should be changed ASAP and I do not see anything obvious in consider one of the arch., having 64 bit instructions, as something obviously "default". i386 and i686 should be covered, among those options.
@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 17, 2020

  • In Libgo/CMakeLists.txt :

not clear if there is something that should be hardcode, specifically for scenarios of i386 and i686 CPUs (respectively), as it is done for x86_64 - at https://go.googlesource.com/gollvm/+/refs/heads/master/libgo/CMakeLists.txt#447.
Since the status of gollvm project/feature coverage for Golang's runtime considers documented per-arch. instructions sets - those should be documented and hardcoded, as done at https://go.googlesource.com/gollvm/+/refs/heads/master/libgo/CMakeLists.txt#483.

  • In driver/ArchCpusAttrs.h :

Add attributes for i38 and i686 architectures, respectively.

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 17, 2020

@aregm , @fexolm - feel free to share your vision.
Thanks in advance

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 17, 2020

@thanm, why can't your project integrate https://github.com/intel-go/cpuid ?

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Jul 17, 2020

@linux4life798 , @bramp - please follow up

@thanm
Copy link
Member

@thanm thanm commented Aug 10, 2020

Lots of comments and observations here, sounds like the next step is to write some patches.

@advancedwebdeveloper
Copy link
Author

@advancedwebdeveloper advancedwebdeveloper commented Aug 15, 2020

@thanm , I was trying to say that a cooperated review is required (a reason for a community call?).
Perhaps during Go engineering community calls or LLVM user group community calls.
I guess a PR is required/an agenda.
I am investigating what is required on Windows and Linux (i386) - and Microsoft's vision of Windows port (X86;X86_64) would help to support it natively (to mingw or cygwin).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.