Open Bug 1521991 Opened 7 years ago Updated 3 years ago

Audit/refactor xptc_stubs code to reduce chances of broken casts / wrong argument passing

Categories

(Core :: XPCOM, enhancement, P3)

enhancement

Tracking

()

Tracking Status
firefox66 --- affected

People

(Reporter: Gijs, Unassigned)

References

Details

We've now run into this twice. There also seems to be a significant quantity of duplicate code in these files.

Bobby, this sounds like something we should clean up. Your thoughts/inputs?

Flags: needinfo?(bobbyholley)
Priority: -- → P2

xptcall is obviously a mess, and I certainly wouldn't object if someone was motivated enough to refactor it in a nice way with more shared code. It's a pretty uphill climb though, because all the code is platform-specific. The code is isolated and rarely changes, so it feels unlikely to move the needle.

So I think we can live with what we've got and don't recommend that we prioritize a grand refactoring here. I'm certainly open to targeted improvements, or a grand refactoring if it doesn't take time away from something more important.

Flags: needinfo?(bobbyholley)
Component: XPConnect → XPCOM

These stubs files are under xpcom/, so generally related bugs get filed in XPCOM instead of XPConnect. Bug 1476121 and bug 1510781 have some other stubs related cleanup ideas.

(In reply to :Gijs (he/him) from comment #0)

We've now run into this twice. There also seems to be a significant quantity of duplicate code in these files.

Do you have some bug numbers handy for this? If it isn't too much trouble, it would be nice to have some more concrete specifics on that.

Flags: needinfo?(gijskruitbosch+bugs)

I assume it's the two blocked bugs.

Oops, I failed to see that. Thanks.

Flags: needinfo?(gijskruitbosch+bugs)

There's also things like bug 1478655, which would be an excellent precursor to this work, so the xptcall files would focus more on the processor-specific things and less on all the copy-paste glue that has accumulated over the years.

The only problem is that these files get touched so rarely, generally only when Firefox is ported to a new platform, which is a pretty rare event. I think we're only likely to get one more set of files (when some brave soul ports Firefox to RISC-V) in the next five years or so. And the specific ask here is to come up with some abstraction for platform ABIs, which would certainly reduce code duplication, but doesn't buy you a lot of stuff on its own.

Priority: P2 → P3

MinGW builds revealed another instance of this issue.

Blocks: 1570563
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.