[PATCH] D85774: [XCOFF][AIX] Enable tooling support for 64 bit symbol table parsing

[James Henderson via Phabricator via llvm-commits]

jhenderson added inline comments.


================
Comment at: llvm/test/tools/llvm-objdump/XCOFF/disassemble-symbol-description64.test:13-14
+
+## xcoff-section-headers64.o Compiled with IBM XL C/C++ for AIX, V16.1.0
+## compiler command: xlc -q64 -qtls -o xcoff-section-headers64.o -c test.c
+
----------------
jasonliu wrote:
> jhenderson wrote:
> > I'm not going to stop you checking in a pre-compiled object, as I'm not an XCOFF maintainer, but as you are continuing to add more functionality here, I strongly advise you to write a yaml2obj XCOFF port, to avoid pre-canned binaries. You'll find pre-built binaries extremely inconvenient to work with as you maintain things going forward. Not only that, but they are harmful to the git repository size, especially if you have to occasionally rebuild them.
> > 
> > Using yaml2obj may also be about the only way you can test most parse failure paths.
> > 
> > If yaml2obj isn't viable, at least consider llvm-mc or similar, if possible.
> I agree that we would want to move away from pre-canned binaries at some point.
> When writing a yaml2obj port, we would still require tools such as llvm-readobj and llvm-objdump to make sure our yaml2obj implementation is correct. So we still have a chicken-or-egg problem here. 
> I think the current plan is to use pre-canned binary to develop the tooling support first. Then use the verified tooling support to verify XCOFF object file generation from llc. Then we could replace the pre-canned binary with llvm-mc/llc.
Yeah, chicken-or-egg problem is a bit of an issue. I'm not sure there's always a clear answer to this. The one I've encouraged for yaml2obj DWARF support testing is to actually inspect the hex output (with sufficient additional commenting to make it clear what the output represents). By keeping the initial functionality small enough, you can boostrap up from there.

The issue is that a lot of our low-level tool testing (i.e. testing of things like llvm-readobj) has switched over to yaml2obj, but clearly we can't (in theory) then use llvm-readobj to test the basic output of yaml2obj or we end up with a circular test dependency - a bug in a common library might not obviously manifest itself in this context, but would if using a tool from outside the ecosystem.

Another strategy which I've used occasionally for testing DWARF parsing before the yaml2obj support existed was writing assembly using just .byte/.quad etc directives to craft the input format precisely, without relying on the higher-level assembly directives (like .file/.loc etc). This may not work in all situations though.


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

https://reviews.llvm.org/D85774