Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
tags 886736 + pending thanks Cool. Should be fixed in Git... https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=59dc18184ea11f3efc0236acb914e6355e8493ad Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
On Wed, Jan 10, 2018 at 10:36:02AM +0530, Chris Lamb wrote: > Mike Hommey wrote: > > > The two builds I was comparing: > > […] > > Thanks for sending this over. For some reason, I completely failed to > realise that I would need access to otool to make use of these, and > this is not in Debian ;) > > Can you run some commands for me? In particular, is it sufficient to > fallback to, say, -tdvVQ if -tdvV does not work? It's enough for me. Although some versions of otool don't support -Q, and I don't know what they do. Note you can get otool and other mac tools for linux from https://github.com/tpoechtrager/cctools-port/ Mike
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
Mike Hommey wrote: > The two builds I was comparing: […] Thanks for sending this over. For some reason, I completely failed to realise that I would need access to otool to make use of these, and this is not in Debian ;) Can you run some commands for me? In particular, is it sufficient to fallback to, say, -tdvVQ if -tdvV does not work? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
On Wed, Jan 10, 2018 at 10:42:33AM +0900, Mike Hommey wrote: > On Wed, Jan 10, 2018 at 10:23:59AM +0900, Mike Hommey wrote: > > On Tue, Jan 09, 2018 at 01:07:58PM +, Chris Lamb wrote: > > > Hi Mike, > > > > > > > I only have a very large XUL library... you probably don't want that. > > > > > > Probably not for the testsuite (!) but if you could make it available it > > > would help with a fix anyway... > > > > The two builds I was comparing: > > https://queue.taskcluster.net/v1/task/AKmfRsZPQjqkc7ZoBmS2zw/runs/0/artifacts/public/build/target.dmg > > https://queue.taskcluster.net/v1/task/Hs2lbc9dTFi4eXjwwM26NA/runs/0/artifacts/public/build/target.dmg > > > > The corresponding diff: > > https://queue.taskcluster.net/v1/task/QRazQl4PQZeuiU81C9PtlA/runs/0/artifacts/public/diff.html > > > > Note that the actual diff you get is: > > https://queue.taskcluster.net/v1/task/Uhv3G5XUQA6DDFrOhErA9Q/runs/0/artifacts/public/diff.html > > > > which has more differences. Stripping the binaries first gets the first > > diff. I should probably file another bug about that, those differences > > show up when comparing nm -a output. > > BTW, since I'm also looking at where those differences are coming from, > the first one in the first diff is a UUID difference that appears in the > otool -l output. And some (all?) differences that are not in the disassembly differences are visible in `dyldinfo -bind -weak_bind -lazy_bind` output. Mike
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
On Wed, Jan 10, 2018 at 10:23:59AM +0900, Mike Hommey wrote: > On Tue, Jan 09, 2018 at 01:07:58PM +, Chris Lamb wrote: > > Hi Mike, > > > > > I only have a very large XUL library... you probably don't want that. > > > > Probably not for the testsuite (!) but if you could make it available it > > would help with a fix anyway... > > The two builds I was comparing: > https://queue.taskcluster.net/v1/task/AKmfRsZPQjqkc7ZoBmS2zw/runs/0/artifacts/public/build/target.dmg > https://queue.taskcluster.net/v1/task/Hs2lbc9dTFi4eXjwwM26NA/runs/0/artifacts/public/build/target.dmg > > The corresponding diff: > https://queue.taskcluster.net/v1/task/QRazQl4PQZeuiU81C9PtlA/runs/0/artifacts/public/diff.html > > Note that the actual diff you get is: > https://queue.taskcluster.net/v1/task/Uhv3G5XUQA6DDFrOhErA9Q/runs/0/artifacts/public/diff.html > > which has more differences. Stripping the binaries first gets the first > diff. I should probably file another bug about that, those differences > show up when comparing nm -a output. BTW, since I'm also looking at where those differences are coming from, the first one in the first diff is a UUID difference that appears in the otool -l output. Mike
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
On Tue, Jan 09, 2018 at 01:07:58PM +, Chris Lamb wrote: > Hi Mike, > > > I only have a very large XUL library... you probably don't want that. > > Probably not for the testsuite (!) but if you could make it available it > would help with a fix anyway... The two builds I was comparing: https://queue.taskcluster.net/v1/task/AKmfRsZPQjqkc7ZoBmS2zw/runs/0/artifacts/public/build/target.dmg https://queue.taskcluster.net/v1/task/Hs2lbc9dTFi4eXjwwM26NA/runs/0/artifacts/public/build/target.dmg The corresponding diff: https://queue.taskcluster.net/v1/task/QRazQl4PQZeuiU81C9PtlA/runs/0/artifacts/public/diff.html Note that the actual diff you get is: https://queue.taskcluster.net/v1/task/Uhv3G5XUQA6DDFrOhErA9Q/runs/0/artifacts/public/diff.html which has more differences. Stripping the binaries first gets the first diff. I should probably file another bug about that, those differences show up when comparing nm -a output. Mike
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
On Tue, Jan 09, 2018 at 12:50:05PM +, Chris Lamb wrote: > Hi Mike, > > > > In some cases, otool can fail with: > > > > can't create x86_64 llvm disassembler > > Do you happen to have example files you could point to or upload? Not > essential of course, but would be much easier and reliable to write a > fix with an addition to the testsuite armed with them... I only have a very large XUL library... you probably don't want that. Mike
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
Hi Mike, > I only have a very large XUL library... you probably don't want that. Probably not for the testsuite (!) but if you could make it available it would help with a fix anyway... Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
Hi Mike, > In some cases, otool can fail with: > > can't create x86_64 llvm disassembler Do you happen to have example files you could point to or upload? Not essential of course, but would be much easier and reliable to write a fix with an addition to the testsuite armed with them... > "Sensibly", it does print that on stdout, and quits with exit code 0. ♥ Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#886736: diffoscope: mach-o disassembly with otool can fail in a way that fools diffoscope into dumping raw data instead
Package: diffoscope Version: 90 Severity: normal Dear Maintainer, In some cases, otool can fail with: can't create x86_64 llvm disassembler (where x86_64 may be another platform, and where the message is usually preceded by the file path name and "(__TEXT,__text) section", well, in fact, anything that would normally come before the disassembly for the given command line) "Sensibly", it does print that on stdout, and quits with exit code 0. Which means when you're comparing two binaries that have assembly differences, the otool output is identical and non-failing, from diffoscope's perspective, meaning it goes on to the fallback "No file format specific differences found inside, yet data differs", which then goes on to do a diff on a hexdump. When the llvm disassembler fails for some reason, one can use the -Q option to otool to make it use its internal disassembler, which is better than nothing. Mike
