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

Can't add 16K+ (4*PageSize) object file to MCJIT. #21096

Closed
bader opened this issue Aug 21, 2014 · 7 comments
Closed

Can't add 16K+ (4*PageSize) object file to MCJIT. #21096

bader opened this issue Aug 21, 2014 · 7 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla

Comments

@bader
Copy link
Contributor

bader commented Aug 21, 2014

Bugzilla Link 20722
Resolution FIXED
Resolved on Dec 08, 2014 10:49
Version trunk
OS Linux
CC @lhames

Extended Description

I'm trying to add an object file created with object::ObjectFile::createObjectFile to MCJIT using addObjectFile the same way lli is doing it.
I found that if file size is > 4*PageSize MCJIT crashes with seg. fault trying to load it.

The problem is that if object file exceeds 4*PageSize MemoryBufferMMapFile is used to allocate memory and it marks allocated memory as read-only.
MCJIT creates ObjectImage from ObjectFile, but it simply sets internal pointers to the memory allocated for ObjectFile.
The crash happens during the ObjectImage loading when loader tries to update emitted ELF section address, which resides in read-only memory.

In order to reproduce the issue almost any ELF object is enough. For instance lli.o can be used:

bin/lli -use-mcjit -extra-object=./tools/lli/CMakeFiles/lli.dir/lli.cpp.o < ../llvm/test/ExecutionEngine/Interpreter/intrinsics.ll
0 lli 0x0000000000a088e2 llvm::sys::PrintStackTrace(_IO_FILE*) + 34
1 lli 0x0000000000a08494
2 libpthread.so.0 0x00007fd0b2f03340
3 lli 0x0000000000b61365
4 lli 0x0000000000b524e3 llvm::RuntimeDyldImpl::emitSection(llvm::ObjectImage&, llvm::object::SectionRef const&, bool) + 627
5 lli 0x0000000000b52bc0 llvm::RuntimeDyldImpl::findOrEmitSection(llvm::ObjectImage&, llvm::object::SectionRef const&, bool, std::map<llvm::object::SectionRef, unsigned int, std::lessllvm::object::SectionRef, std::allocator<std::pair<llvm::object::SectionRef const, unsigned int> > >&) + 176
6 lli 0x0000000000b53674 llvm::RuntimeDyldImpl::loadObject(llvm::ObjectImage*) + 2452
7 lli 0x0000000000b53af3 llvm::RuntimeDyld::loadObject(std::unique_ptr<llvm::object::ObjectFile, std::default_deletellvm::object::ObjectFile >) + 131
8 lli 0x0000000000841bab llvm::MCJIT::addObjectFile(std::unique_ptr<llvm::object::ObjectFile, std::default_deletellvm::object::ObjectFile >) + 43
9 lli 0x0000000000516a29 main + 2489
10 libc.so.6 0x00007fd0b232eec5 __libc_start_main + 245
11 lli 0x0000000000527230
Stack dump:
0. Program arguments: bin/lli -use-mcjit -extra-object=./tools/lli/CMakeFiles/lli.dir/lli.cpp.o
zsh: segmentation fault (core dumped) bin/lli -use-mcjit -extra-object=./tools/lli/CMakeFiles/lli.dir/lli.cpp.o <

@bader
Copy link
Contributor Author

bader commented Aug 21, 2014

assigned to @lhames

@lhames
Copy link
Contributor

lhames commented Sep 12, 2014

Hi Bader,

Sorry - it has taken a while for me to get back to this. I haven't tried this myself yet, but I suspect I know the cause: RuntimeDlydELF always tries to fix up the object image for the debugger (regardless of whether there's actually a debugger attached). When the object is backed by an ordinary memory buffer (true for all objects spat out from the JIT) this just works, but when an object file is loaded from disk it can (as you saw) be backed by a read-only mmapped buffer. We ran in to this exact problem with on the MachO side of RuntimeDyld and decided to remove the debugger registration system for this reason (there are plans to re-introduce a more sane implementation).

I think this makes a good case for removing debugger registration from RuntimeDyldELF as soon as reasonably possible.

Cheers,
Lang.

@bader
Copy link
Contributor Author

bader commented Sep 15, 2014

Hi Lang,

Thanks for the hint.
Does it mean that I won't be able to debug JIT-ed code?
If so I'm afraid this workaround won't work for me. I need debugger support.

Currently I just do not use setObjectCache EE API and recompile the object each time. This approach introduce additional overhead that I would like to avoid.
I'm going to try using ordinary memory buffer for object files loaded from disk.

BTW, setObjectCache works fine with LLVM 3.3 and doesn't work with LLVM 3.4+.

Thanks again,
Alexey

@lhames
Copy link
Contributor

lhames commented Sep 15, 2014

Hi Bader,

Sorry, I should have gone in to slightly more detail: What I mean is that we want to remove the current debugger registration system and replace it with something better.

For now I'm working on a work-around: The RuntimeDyldELF debugger registration system will duplicate objects before registering them with the debugger. This means higher memory consumption for the JIT, but at least everything will keep working. It will also provide a good motivation for us to get to work on the new registration system.

I'll update this bug when my fix goes in.

  • Lang.

@llvmbot
Copy link
Member

llvmbot commented Nov 12, 2014

Hi Lang,

Thanks for the hint.
Does it mean that I won't be able to debug JIT-ed code?
If so I'm afraid this workaround won't work for me. I need debugger support.

Currently I just do not use setObjectCache EE API and recompile the object
each time. This approach introduce additional overhead that I would like to
avoid.
I'm going to try using ordinary memory buffer for object files loaded from
disk.

BTW, setObjectCache works fine with LLVM 3.3 and doesn't work with LLVM
3.4+.

Thanks again,
Alexey

Hi.
I made a really ugly workaround. I just switched off using mmap in lib/Support/MemoryBuffer.cpp. It seems to work fine.

Regards.

@lhames
Copy link
Contributor

lhames commented Nov 26, 2014

Hi Alexey, Radek,

This should be fixed as of r222841. It works for me on the suggested test case. Can you confirm that it has fixed your issues?

Radek - You should be able to remove your workaround in lib/Support/MemoryBuffer.cpp now.

Cheers,
Lang.

@lhames
Copy link
Contributor

lhames commented Dec 8, 2014

Yep - r222841 seems to have fixed this.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

3 participants