plotfi marked an inline comment as done. plotfi added a comment. In D60974#1486631 <https://reviews.llvm.org/D60974#1486631>, @jakehehrlich wrote:
> In D60974#1486384 <https://reviews.llvm.org/D60974#1486384>, @compnerd wrote: > > > @jakehehrlich - unfortunately, removing the attributes on the sections will > > make the content look different with `nm` which is something we do need to > > appear proper for consumers of the interface libraries. Versioning has a > > number of problems inherent to it (unfortunately, its the closest to > > multi-level namespaces in ELF). I think that getting something in tree and > > iterating on it is far better than continuing to argue over this in the > > dream of something that unifies the TAPI approach and this approach. The > > section names are relevant (you can add attributes to put symbols into > > alternate sections and you can have section relative relocations). I think > > that you are loosing fidelity in the final output which is sufficient for > > your needs, but I think that there are places where the full fidelity can > > be needed. > > > > This currently works and allows us to generate the interface library which > > means that this is actually further than what you are proposing still. Is > > there something technical that this is doing incorrectly or breaking > > something? Otherwise, this really does seem like it is devolving into a > > bike shedding argument that isn't really going anywhere. This is not a > > large amount of code and there is backing to maintain it, so it is not an > > issue of "this is adding un-maintained complexity" either. > > > > Just like the LLVM APIs, this can/will evolve. I don't see why this needs > > to be set in stone from the initial implementation. There are use cases > > which can come up which require reworking the solution. > > > > > 1. The output of nm when you give it what exactly is different? What output > are you expecting? You aren't making that specific. Passing the unmerged > output though nm doesn't make any sense. If you have a precise use case for > section names you should mention it. We can always add symbol information > back as needed if we first start with something more minimal. What output of > nm are you expecting a > 2. We're basically in agreement on what should happen here. I don't think > it's a dream of unifying these things. It looks like a very close reality to > me. > 3. You mention sections and relocation as being relevant information. Can you > give a specific use case? Section names in general are not meaningful > information. They're just there for humans to debug things. Putting symbols > in different sections lets the linker treat them specially but in the end > binary sections are not relevant to much of anything. Jake, I am still not sure what you would prefer for moving forward. The current patch can output the yaml format I originally proposed or the one that looks similar to the one you proposed. What I need to know is: - Do you want the merging if the "ifo" files to happen inside of llvm-elfabi? - Do you care if we upstream the yaml we proposed as a first step (which is really a distilled version of that yaml2obj can consume anyways. this right now functions actually) ??? - Or, would you rather the ifo files be merged by a different separate tool (something maybe called llvm-ifsogen)??? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60974/new/ https://reviews.llvm.org/D60974 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
