Page MenuHomePhabricator

elua doesn't work on aarch64 due to 47bit pointer restrictions
Open, Pending on user inputPublic

simotek created this task.Nov 23 2017, 12:45 AM

<_ami_> raster,
<raster> _ami_: and how to not use lightuserdata then?
<raster> also 47 bits is just not enough ... certainly not
<_ami_> raster,
<Simotek> raster maybe, but i'll have to set up a build environment on one of my rpi's
<raster> this seems to be a general issue that has no solution :(
<raster> it's probably now not an eoid but a real ptr
<raster> and on arm64 a real ptr is getting high bits set
<raster> which basically is malloc returns
<raster> and ... there isnt much we can do
<raster> well ok maybe its something internal to luajit doing it
<raster> like that thread says
<_ami_> lua_pushlightuserdata() is used in efl code.
<raster> yes
<_ami_> they suggest to use static variable for lua_pushlightuserdata
<raster> we need it to pass referneces to native stuff around
<_ami_> raster,

  • antoinef ( has joined
  • Puppet_Master has quit (Ping timeout: 250 seconds)

<raster> they are doing non-portable things there to make it happen
<raster> the allocation and double-ref thing i mentioned earlier
<raster> with a custom allocator to ensure the addr uses only 47 bits (i assume lj_mem_newt does)
<raster> i mean edje does this, elua does it and the evas filters do it too
<_ami_> seems like they fixed in ljit 2.1?
<raster> no
<raster> Simotek is having the issues with 2.1
<_ami_> hmm
<raster> its even in luajit git master (the 47 bit check)
<raster> its just horrible to remove 17 bits of our pointers on 64bit
<raster> why it cant do what it does for 32bit... i don't know
<raster> thatrs an explicit choice
<raster> but i know i can limit our eoid's to 47 bits
<raster> but not generic pointers
<raster> he says to use ffi+cdata
<raster> now we need q66
<raster> Simotek: need to bug q66
<Simotek> ok
<jpeg> oh sweet. there's a solution then :)
<raster> but we have lots of instances
<raster> src/lib/evas/filters/evas_filter_parser.c
<raster> src/lib/elua/elua.c
<raster> src/lib/edje/edje_lua2.c
<raster> src/lib/edje/edje_lua.c
<_ami_> yup, a lot.
<raster> lots of lua_pushlightuserdata
<jpeg> do we have anyone besides felipe who's well knowledgeable about c++ (and hopefully efl too)
<jpeg> nah evas filters don't matter. lightuserdata is not eo
<jpeg> evas filters don't require luajit
<raster> but if we build with luajit this will be a problem
<raster> the problem isnt now eoid
<raster> i can fix that
<raster> the problem is pointers with high values
<raster> stack values can have the high bits set on arm
<raster> thats a crux of things
<jpeg> hmm
<jpeg> right
<raster> lua_pushlightuserdata(L, (void *) &this_is_not_a_cat);
<raster> that isnt stack but in theory it could have high bits set
<raster> lua_pushlightuserdata(L, pgm);
<raster> that pgm is a stack val so on arm64 apparently it will have high bits set
<jpeg> yeah but you're missing the point: it's not a cat
<jpeg> j/k
<raster> ahahahha
<raster> but this is in various places
<raster> so i guess i could try and hack around and convert ptrs into id's in a table to keep values low
<jpeg> just poke q66 :)
<raster> q66: evil luajit stuff.... above ^^^^^^^^^^^^^66

  • Puppet_Master ( has joined

<raster> well one way is to do an indirection for all lightuserdata + touserdata which gets it back

q66 edited projects, added Restricted Project; removed efl.Apr 13 2018, 3:42 AM
q66 triaged this task as High priority.Apr 13 2018, 2:49 PM

Please give this a try after b8f28e2a99535a8e9780f9ea15572693bf0f7148

Apparently still no luck. I'll try amd get a raspberry pi + gdb out on my desk later.

[ 1407s] ELUA_EOLIAN_LIBRARY_PATH=../src/lib/eolian/.libs ELUA_EINA_LIBRARY_PATH=../src/lib/eina/.libs ../src/bin/elua/elua -I/home/abuild/rpmbuild/BUILD/efl-1.20.7/src/bindings/luajit -C/home/abuild/rpmbuild/BUILD/efl-1.20.7/src/scripts/elua/core -M/home/abuild/rpmbuild/BUILD/efl-1.20.7/src/scripts/elua/modules -A/home/abuild/rpmbuild/BUILD/efl-1.20.7/src/scripts/elua/apps lualian -I. -o lib/ecore_audio/ecore_audio.eo.lua lib/ecore_audio/ecore_audio.eo
[ 1407s] make[4]: *** [Makefile:54389: lib/ecore_audio/ecore_audio.eo.lua] Segmentation fault (core dumped)

q66 added a comment.Apr 16 2018, 1:39 AM

Yeah, that'd help.

q66 lowered the priority of this task from High to Pending on user input.Jun 25 2018, 11:50 AM
q66 added a comment.Jun 28 2018, 6:11 AM

@simotek think you could get me the backtrace so that i can finally deal with this?