[PATCH] D60974: Clang IFSO driver action.

[Jake Ehrlich via Phabricator via cfe-commits]

jakehehrlich added a comment.

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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60974/new/

https://reviews.llvm.org/D60974