Correct recognition of NetBSD images
Changes PlannedPublic

Authored by krytarowski on Feb 2 2018, 2:25 PM.

Details

Summary

Split the recognition into NetBSD executables
& shared libraries and core(5) files.

Introduce new owner type: "NetBSD-CORE",
as core(5) files are not tagged in the same way
as regular NetBSD executables.

Stop using incorrectly ABI_TAG and ABI_SIZE.
Introduce IDENT_TAG, IDENT_DECSZ,
IDENT_NAMESZ and PROCINFO.

The new values detects correctly the NetBSD
images.

Sponsored by <The NetBSD Foundation>

Diff Detail

Repository
rL LLVM
krytarowski created this revision.Feb 2 2018, 2:25 PM

Extracted from: D32149.

davide requested changes to this revision.Feb 2 2018, 2:58 PM
davide added a subscriber: davide.

Please add a test case.

This revision now requires changes to proceed.Feb 2 2018, 2:58 PM

What would the test do?

Probably take a ELF file that is NetBSD and obj2yaml it. The test would run yaml2obj on it and then test that things are recognized correctly via the SB interfaces (check triple is correct)?

You would check in the YAML code for the NetBSD ELF file so that the test case can make it into an ELF file, run the test, verify things, and then cleanup the created ELF file.

davide added a comment.Feb 2 2018, 3:28 PM

Probably take a ELF file that is NetBSD and obj2yaml it. The test would run yaml2obj on it and then test that things are recognized correctly via the SB interfaces (check triple is correct)?

The SBApi in this case is a sledgehammer. I think lldb-test or an unitest would be a better/lightweight alternative.

Is there a working example of this? I would clone an existing code for Linux or other supported OS and adapt it for NetBSD.

Please note that I'm in the process of restoration LLDB (lldb-server) so I cannot execute regular tests, at least in close time.

davide added a subscriber: zturner.Feb 2 2018, 3:33 PM

Is there a working example of this? I would clone an existing code for Linux or other supported OS and adapt it for NetBSD.

Please note that I'm in the process of restoration LLDB (lldb-server) so I cannot execute regular tests, at least in close time.

cc: @zturner / @labath

jingham added a subscriber: jingham.Feb 2 2018, 4:14 PM

There is code in the GDBRemoteTestBase that makes targets from yaml2obj. See the createTarget method in packages/Python/lldbsuite/functionalities/gdb_remote_client/gdbclientutils.py. Actually, that's method should be pulled out of the gdb_remote_client and moved to TestBase in lldbtest.py, it doesn't appear to have any dependencies on being a gdb_remote_client test, and it seems like a generally useful feature. Note that gdb_remote_client directory also has an example of making a little ELF file (a.yaml).

It looks like the GDBRemoteTestBase class also has some mechanism for cleaning up temporary files, but I'm not sure that's necessary, since the generated files should all go into the build directory now Adrian is done with that work. I don't see why the test cases should have to do this by hand.

Anyway, if that were in lldbtest (maybe createTargetFromYaml), then you could make a dotest test by copying the packages/Python/lldbsuite/test/sample_test/TestSampleTest.py somewhere, remove the build stage, and in the test body just do something like:

target = self.createTargetFromYaml(path_to_yaml)
self.assertTrue(target.GetTriple() =="whateverItsSupposedToBe", "Got the right target")

You only need to use lldb-server to run the dotest.py based tests if you need to run the process, which you don't here. You should be able to run all the tests that don't run processes, though of course if you don't have an lldb-server you can't actually launch anything regardless of what test harness is doing the launching.

labath added a comment.Feb 5 2018, 4:32 AM

Extending lldb-test's dumpModules() to also dump out the module's triple sounds like a reasonable thing to do (I am assuming that the Module class will do something reasonable when given an object file with no sections, like a core file -- if not we could make a separate command for dumping this out).

However, the tricky part here is the obj2yaml idea. Right now obj2yaml support for program headers is virtually non-existent. obj2yaml just ignores them, and yaml2obj only has basic support for PT_LOAD segments (and even here it assumes that their contents is backed by actual sections, which is not the case for core files). So, I don't think you can use yaml2obj here without some serious work to make it support this use case (which would be an awesome feature, but not exactly a trivial job...).

source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
1367

Let's avoid c string functions where possible. This could be setOSName(llvm::formatv("netbsd{0}.{1}.{2}", major, minor, patch).str())

krytarowski planned changes to this revision.Feb 11 2018, 12:09 PM

I will be back to this once I will be done with debugging client-server connectivity issues (unrelated to this patch).