Opened 3 years ago
Last modified 3 years ago
#8288 new bug
Undefined weak symbols should get a value of 0
| Reported by: | hamish | Owned by: | bonefish |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | System/runtime_loader | Version: | R1/Development |
| Keywords: | undefined weak symbols | Cc: | cian |
| Blocked By: | Blocking: | ||
| Has a Patch: | yes | Platform: | All |
Description
This has apparently already been fixed for kernel code in #6272 but persists in runtime_loader. Weak symbols that are unresolved should get set to 0.
For example, this program should run and return successfully:
#include <stdlib.h>
extern void func() __attribute__ ((weak));
int main() {
// Always false but won't be optimized away.
if (malloc(1)==(void*)1) func();
return 0;
}
But instead runtime_loader complains about unresolved symbols.
Attachments (1)
Change History (7)
comment:1 Changed 3 years ago by X512
comment:2 Changed 3 years ago by bonefish
I could have sworn the feature was implemented in the runtime loader at the same time, but obviously that's not the case.
The implementation is rather easy: In resolve_symbol() lookupError simply needs to remain ERROR_UNPATCHED, if sym is weak (i.e. put the assignment in a respective "if").
I can't promise that I get to implement it anytime soon. So, if there are any takers ...
Changed 3 years ago by hamish
comment:3 Changed 3 years ago by hamish
- Has a Patch set
comment:4 Changed 3 years ago by bonefish
Mmh, the symbol patcher stuff makes that all a bit more complicated. The interface has to be changed, I'm afraid. We should also fix the incorrect assumption that a value of NULL means the symbol is undefined.
comment:5 Changed 3 years ago by cian
This is currently affecting doing a clean build of VLC/libvlc - weak symbol in the core library leads to runtime errors when trying to run the application or even test suites.
If the code is edited to use the non-weak version (intended for non-ELF targets), it works.
comment:6 Changed 3 years ago by cian
- Cc cian added

Is this related to unsolved symbols of reserved methods like «_ZN5BView15_ReservedView12Ev» when this virtual methods are implemented?