Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/wasm/MapFile.cpp | ||
---|---|---|
128 | Since wasm functions don't have addresses, you decided to print out "0" as an address, right? I wonder if we should something other than "0" (like "-") since "0" is still a valid address. |
lld/test/wasm/map-file.s | ||
---|---|---|
28 | Maybe a noob question, but is that significant? For ELF and COFF, we emit an offset within an output section for each input section, but we don't print out an offset within a file. |
lld/test/wasm/map-file.s | ||
---|---|---|
28 | It hard to say what the most useful information to present is. Do you have rational for why offset within an output section for each input section is useful? I happy to modify this PR to display that information instead. I imagine we could change this based on consumer feedback in the future too. |
lld/test/wasm/map-file.s | ||
---|---|---|
4 | --match-full-lines --strip-whitespace --strip-whitespace alone still ignores leading or trailing spaces. See test/ELF/map-file-64bit.s for an example |
lld/test/wasm/map-file.s | ||
---|---|---|
4 | Sure thing.. I was copying lld/test/ELF/map-file.s which just uses -strict-whitespace. At least it did until today when you changed it in cece7af58682a2122b108d7af270a31043ac1825 :) Any reason you also changed all the comments from // to # in that change? I think we should try to be consistent across all the .s tests in lld so maybe we change all of them at once? (Assuming we prefer the hash mark). Also, I looks like you didn't send it for review (or at least no here on phabicator)? Was that deliberate? Sorry, I don't mean to sound picky.. happy for the feedback here. |
lld/test/wasm/map-file.s | ||
---|---|---|
4 | I think lld/test/ELF/map-file.s should have been fixed earlier before you copied it to wasm. About // -> #, the description of that commit mentioned that since I had to change so many lines (adding leading spaces), just change the comments to use the more common way. For other tests, it might just create churn if we do so. So I would not want to do that unless there is just motivation and I have to change a majority of lines (then optimizing for diff no longer counts)
Yes. It is NFC and likely community consensus plus I have made sufficient changes to lld/ELF. I probably would not want to do that if you did not copy it here. |
Use # over \\ is a comments in .s files
lld/test/wasm/map-file.s | ||
---|---|---|
28 | Ping. Would you prefer I output "offset with output section for each input section" ? Looking at test/ELF/map-file.s only see LMA and VMA (which I assume stands for virtual memory address?). I'm not sure what LMA has a logical correspondence in wasm. Is this what you call " offset with output section for each input section" ? For the test code LMA and VMA seems to be the same in all cases. I'm happy to change this however you like but I also think its find to land as is and get feedback as to what information is the most useful to present. |
lld/test/wasm/map-file.s | ||
---|---|---|
4 |
It looks like lld/test/ELF/map-file.s was only fixed 2 days ago. This PR has been open a lot longer than that. Of course it makes no difference at all, I'm just pointing this out for the record to explain why this change started life like this and that it was based on an existing test in the ELF linker. |
lld/test/ELF/map-file.s | ||
---|---|---|
14 | I know some people prefer the double-dash options for FileCheck now. If you are going to add new lines or touching existing lines, you may use the double-dash form. | |
lld/wasm/MapFile.cpp | ||
133 | os.indent(8) << toString(chunk) << '\n' | |
lld/wasm/OutputSections.cpp | ||
234 | This order shuffle is not needed. | |
lld/wasm/OutputSegment.h | ||
41 ↗ | (On Diff #259729) | Add a comment what this means. It seems that outputSec is purely for debugging purposes (-M). |
Can we pick this up again?
It looks like the only unresolved issues are the question of whether we should print section offsets or file offsets, and whether to put "-" or "0" for function addresses. I don't really have any opinion on the latter.
For the former question in general it's unfortunately slightly annoying, because for sections like data and debug info, section offsets are more relevant. But for code, VMs tend to print code addresses as file offsets.
But for the view mentioned above, (printing the offsets of each output section especially the official known sections such as CODE, DATA, etc where there can be only one), file offset probably makes the most sense to me.
lld/wasm/MapFile.cpp | ||
---|---|---|
39 | The public functions should use the style: void wasm::xxxxxxx |
lld/wasm/MapFile.cpp | ||
---|---|---|
39 | Interesting, thanks. I guess I should update all the source files in lld/wasm to conform. Sadly wasm:: is ambiguous so I had to use llvm::wasm:: |
I know some people prefer the double-dash options for FileCheck now. If you are going to add new lines or touching existing lines, you may use the double-dash form.