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.

Sign up for GitHub

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

Jump to bottom

When using C-bindings, on x86_64 ELF, fails to generate the correct instruction for external call #31975

Closed
llvmbot opened this issue Apr 11, 2017 · 4 comments
Closed

When using C-bindings, on x86_64 ELF, fails to generate the correct instruction for external call #31975

llvmbot opened this issue Apr 11, 2017 · 4 comments
Assignees
@lhames
Labels
bugzilla Issues migrated from bugzilla orcjit wontfix Issue is real, but we can't or won't fix it. Not invalid

Comments

@llvmbot
Copy link
Member

llvmbot commented Apr 11, 2017

Bugzilla Link 32628
Version 4.0
OS Linux
Attachments Code to reproduce the problem
Reporter LLVM Bugzilla Contributor

Extended Description

Debian 8, using llvm 4.0, as well as the trunk, when running the attached code I get a segfault.

It looks like the generated call is of the near, ip-relative type, and when the symbol is resolved, the offset is incorrect, as it can't fit into 32-bit allowed for that type of instruction.

$ clang -g min.c llvm-config --cflags --ldflags --system-libs --libs core orcjit native -rdynamic -lstdc++ -o min
$ gdb min
$ (gdb) run
$ Program received signal SIGSEGV, Segmentation fault.
$ 0x00007ffff7ff0001 in ?? ()
$ (gdb) x/i 0x00007ffff7ff0001
$ => 0x7ffff7ff0001: callq 0x800000edbd50
@llvmbot
Copy link
Member Author

llvmbot commented Apr 11, 2017

assigned to @lhames

@llvmbot
Copy link
Member Author

llvmbot commented Apr 12, 2017

Might not be a bug, because using LLVMRelocPIC for the relocation model solves the problem.

@lhames
Copy link
Contributor

lhames commented Mar 13, 2020

Hi Vlad,

Sorry for the late response. Were you able to solve this?

For now, even in LLM 10, JIT'd code on Linux requires use of the large code model to avoid direct PC-relative calls (calls should be indirect through registers instead). If you're seeing a direct branch my first inclination would be to check the code model.

This situation should change soon: We already support the small code model for MachO objects linked with JITLink (LLVM's new JIT linker). Hopefully we will get an ELF version of JITLink soon and we will be able to avoid this issue on Linux too.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@lhames
Copy link
Contributor

lhames commented Mar 14, 2023

Closing as stale. RuntimeDyld still requires specific code and relocation models, and the original issue was likely due to that. The solution is to move to JITLink, which we're in the process of doing.

@lhames lhames closed this as not planned Won't fix, can't repro, duplicate, stale Mar 14, 2023
@EugeneZelenko EugeneZelenko added wontfix Issue is real, but we can't or won't fix it. Not invalid obsolete Issues with old (unsupported) versions of LLVM and removed obsolete Issues with old (unsupported) versions of LLVM labels Mar 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lhames lhames

Labels
bugzilla Issues migrated from bugzilla orcjit wontfix Issue is real, but we can't or won't fix it. Not invalid
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lhames @EugeneZelenko @llvmbot