[PATCH] D70557: [lld][COFF] Add support for /map
Sylvain Audi via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Mar 10 10:53:05 PDT 2020
saudi marked 2 inline comments as done.
saudi added inline comments.
================
Comment at: lld/COFF/LLDMapFile.cpp:69
+ return a->getRVA() < b->getRVA();
+ });
+ }
----------------
amccarth wrote:
> Stupid question: Is it possible for two symbols to share an address? If so, should this be a `std::stable_sort` for deterministic build outputs?
There definitely are symbols that share an address.
Note that LLDMapFile.cpp was previously MapFile.cpp which was renamed and mostly unchanged (just adapted for the rename).
But I don't mind fixing it on top, should I do that in this commit?
================
Comment at: lld/COFF/MapFile.cpp:81
+ return a.first < b.first || (a.first == b.first && a.second < b.second);
+ });
+ auto end = std::unique(v.begin(), v.end(), [](const auto &a, const auto &b) {
----------------
amccarth wrote:
> Is the lambda necessary in this sort? Don't `std::pair`s naturally use lexicographic ordering?
>
> Do all the `Defined *`s live inside a single object l(ike an array)? If not, then comparing pointers to individual ones is technically undefined behavior though it's very likely to work as expected.
Indeed, the `Define*`s come from various `ObjFile`s so we can't expect them to come from the same array.
This sort is just to regroup entries with the same pointer value, for std::unique to work.
I just noticed:
- comparing the entire pair is not necessary here (we just need to regroup same pointers)
- we just need to compare the value of the pointers, so maybe converting to size_t would be more relevant?
I guess the sort could become :
```
parallelSort(v, [](const auto &a, const auto &b) {
return (size_t)a.first < (size_t)b.first;
});
```
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70557/new/
https://reviews.llvm.org/D70557
More information about the llvm-commits
mailing list