I think this patch is better than https://reviews.llvm.org/D44775.
Details
Diff Detail
- Build Status
Buildable 16498 Build 16498: arc lint + arc unit
Event Timeline
lld/ELF/Writer.cpp | ||
---|---|---|
2210 | Does it really make sense to optimize here? If so, then probably my patch was better, | |
2212 | I do not think it is the correct assertion. So I think what you want to check here that all bytes of TrapInstr are the same. |
lld/ELF/Writer.cpp | ||
---|---|---|
2210 | Writing to a single page is extremely fast, so no. And your patch is not straightforward because the code is more complicated. The point of this patch is that you don't need to iterate over Phdrs. You should just iterate over OutputSections. |
lld/ELF/Writer.cpp | ||
---|---|---|
2211 | Iterating over OutputSections seems like a good idea, but couldn't this fill just the area between two sections? |
lld/ELF/Writer.cpp | ||
---|---|---|
2211 | We can. The reason why I'm doing this is because this way, trap instructions are always 4 byte aligned even if the last segment is not 4 byte aligned. But I can fix it some way. |
lld/ELF/Writer.cpp | ||
---|---|---|
2211 | Interesting. We have the same latent bug in OutputSection::writeTo. I guess we have to add nop for ppc (where not all bytes are the same) to test a fix. |
LGTM + nit/suggestion.
lld/ELF/Writer.cpp | ||
---|---|---|
2209 | So, should this check be removed for simplicity of code? Then, btw, code could be: for (OutputSection *Sec : OutputSections) if (Sec->PtLoad && Sec->PtLoad == PT_LOAD && (Sec->PtLoad->p_flags & PF_X)) fillTrap(Buf + alignDown(Sec->Offset + Sec->Size, Target->PageSize)); |
lld/ELF/Writer.cpp | ||
---|---|---|
2209 | No it can't. If a section ends exactly at a page boundary, no padding is needed. | |
2211 | I thought about how to fill only gaps between sections, but there seems no easy way of doing it. It's doable , but it's perhaps not worth writing more code for it. So I think I'd prefer the current code. |
lld/ELF/Writer.cpp | ||
---|---|---|
2209 | Ah, I see now, it would fill the next page with traps without this check. |
This has been accepted for quite some time, any reason why we're not landing it?
The bug is now #36201.
So, should this check be removed for simplicity of code?
(basing on comments, it makes no sense to have it, right?)
Then, btw, code could be: