Adrien, Urias, Jerome, and Rene, thank you for the information.
Here is where I am puzzled:
strace -t (stuff)
[119613] _kern_reserve_address_range([0x200000], 0x1, 0x67000) =
0x80000005 Invalid Argument (3 us)
[119613] _kern_debug_output("runtime_loader:
/boot/system/non-packaged/lib/ccom: Could not map image: Out of memory
") (293 us)
system/develop/headers/os/kernel/OS.h:#define B_EXACT_ADDRESS 1
The best I can figure is that in runtime_loader calls
get_image_region_load_address which defaults to B_EXACT_ADDRESS if the
section is not relocatable. Possibly I have a mismatch in some
metadata, since the output is supposed to be PIC.
The odd thing is that this error occurs about every other build of an
executable. I can run the compile immediately again and it will
succeed. Run it again and it fails, with an out of memory issue. Run
it again and it succeeds, etc.
However, I can run through some of the options in vm.cpp and see if I
can figure out which one is failing and why.
Thank you again,
tim
Rene Gollent wrote:
On Tue, Mar 15, 2016 at 5:12 PM, Tim Kelly <gtkelly@xxxxxxxxxxxxxxxxx> wrote:
Retract that statement - trying to get clarification. Are
_user_reserve_address_range and _kernel_reserve_address_range effectively
the same?
And regardless of if it is private or not, isn't the code available
somewhere?
_kern is the userspace stub that maps to the corresponding system call
_user_reserve_address_range, which is what Jerome pointed to. The
reason being, the actual syscall mechanism is specific to each CPU
architecture, and as such the build system takes care of generating
the "real" arch-specific code for said stubs.
Regards,
Rene
