Fix calls to allocation functions from within mozglue
Categories
(Core :: mozglue, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox69 | --- | fixed |
People
(Reporter: glandium, Assigned: glandium)
References
Details
Attachments
(1 file)
See the goop we have in several files, like mozglue/build/UntrustedDllsHandler.cpp, mozglue/build/WindowsDllBlocklist.cpp.
In bug 1547519 comment 4, we see the same kind of problem the goop works around, but in MFBT code linked into mozglue.
We're in dire need for a more generic fix.
|
Assignee | |
Comment 1•6 years ago
|
||
It seems we're saved on "MSVC" Windows builds by mozglue.def, and the linker associating internal calls to free to je_free as per the .def file. This suggests binutils doesn't do the same (and maybe it should).
In any case, it's still better overall not to rely on the linker fixing things up.
I'll need this for bug 1492121, thanks! 😬
In the meantime, in my WIP I've put the "goop" in one header that I include in every cpp file -- a bit fragile if later on I add another cpp but forget this #include.
E.g.: https://hg.mozilla.org/try/rev/7359a1284b290cd0b8a0f2860c43fd5b078886fc
But if you can whip up a better generic fix, I'm very interested. Any ETA?
|
|
Assignee | |
Comment 3•6 years ago
|
||
The current situation is suboptimal, where we have the same goop
repeated in multiple files, and where things kinda sorta work out fine
thanks to the linker for files that would have been forbidden, except
when the linker doesn't do its job, which apparently happen on
mingwclang builds.
This change only really covers C++ code using operator new/delete, and
not things that would be using malloc/free, because it's easier.
malloc/free is left for a followup.
|
||
Comment 5•6 years ago
|
||
| bugherder | ||
Description
•