• State Not Answered
  • Replies 1 reply
  • Subscribers 137 subscribers
  • Views 44 views
  • Users 0 members are here
Options
Related

[ERROR] Linker build ID not found in GNU notes

Former Member
Former Member

I have come across this error that originates in libmali (0.46). I have a Mali G510. I have a aarch64 kernel, but the vendor uses a 32-bit userspace so there is no 64-bit driver available. So the only option I have to run aarch64 compiled code is to use software rendering in mesa, which is far too slow for my use case.

So I came up with the idea of using a proxy - that runs in a 64-bit userspace, which my application can link against. The proxy then forwards any GLES/EGL calls to the vendor supplied libGLES and libEGL and thus libmali (which are all 32-bit and untouched).

However, I came across this error here which originates from inside libmali, just when it is linking a very small shader from my application:

[gles_stub] - glLinkProgram(program = 7)
[proxy] === [proxy] h_glLinkProgram - before glLinkProgram(program = 7) ===
[proxy] [CTX [proxy] h_glLinkProgram - before link] dpy=0xa2b780 ctx=0xb123c0 draw=0x1068658 read=0x1068658
[22779.803454] (gles2_proxy) MALISW: build_add_driver_sha1 <unknown>
==>[ERROR] Linker build ID not found in GNU notes
[bridge_core] proxy (pid 32384) exited with status 0

Now from what I can understand, the driver is checking for PT_NOTE sections of ELFs loaded in memory, looking for build id (SHA1) or something like that? and for some reason failing to find it? I am not sure exactly what is scanning or why.

I have no problem running code normally in the 32-bit userspace, so it can obviously find the SHA1 usually as I don't see this error elsewhere. The file system has build IDs!

But for some reason a bug in libmali is not finding SHA1 (I even added them to my app and libs, which are not normally required) and it didn't fix it. I'm thinking maybe it is scanning a aarch64 compiled file and getting confused as its packaged differently compared to armv7a?

Is there any solution to this?

Parents
  • 0 Arm Employee Badge

    Hi,

    Unfortunately this isn't a supported use-case.

    • The 32-bit Mali stack is scanning ELF images for a BuildID. Many Mali releases use it to derive shader cache keys. If it can’t find a BuildID for the “linker/driver” it cares about, it errors out. 

    • In a 64-bit process, the 32-bit code can’t safely parse 64-bit ELF program headers/notes. If your proxy loads or runs 32-bit Mali inside a 64-bit PID, any dl_iterate_phdr or /proc/self/maps parsing will see 64-bit objects and produce “not found”.

    So sorry, no solution. Other than pressuring vendor that with G510 they really should be providing armv8 driver.

Reply
  • 0 Arm Employee Badge

    Hi,

    Unfortunately this isn't a supported use-case.

    • The 32-bit Mali stack is scanning ELF images for a BuildID. Many Mali releases use it to derive shader cache keys. If it can’t find a BuildID for the “linker/driver” it cares about, it errors out. 

    • In a 64-bit process, the 32-bit code can’t safely parse 64-bit ELF program headers/notes. If your proxy loads or runs 32-bit Mali inside a 64-bit PID, any dl_iterate_phdr or /proc/self/maps parsing will see 64-bit objects and produce “not found”.

    So sorry, no solution. Other than pressuring vendor that with G510 they really should be providing armv8 driver.

Children
No data