Muhammad Umar Janjua via llvm-dev
2016-Feb-16 00:57 UTC
[llvm-dev] invalid signature error (old bitcode, new tools)
At some point in 2005/6, I was using an older version of llvm-gcc.I generated files with bytecode using llvm tools at that time. It was GNU C version 3.4-llvm 20030924 (experimental) (i686-pc-linux-gnu) ; compiled by GNU C version 3.4.0. I somehow lost these old tools. But after a decade, I still want to disassemble these old result files to see the code. So I downloaded some windows llvm tools to disassemble a bytecode file into .ll file to view the disassembly code. However, I am seeing an invalid bitcode signature error. Now there could be some changes in the format that the newer version insists on. Could some one help me with llvm-dis for windows that can disassemble the attached c6.bc file? C:\work\llvm-3.4-tools-windows>llvm-dis c:\ImportantDocs\experiments\c6.bc llvm-dis: Invalid bitcode signature C:\work\llvm-3.4-tools-windows>llvm-dis -help OVERVIEW: llvm .bc -> .ll disassemblerUSAGE: llvm-dis [options] <input bitcode>OPTIONS: -f - Enable binary output on terminals -help - Display available options (-help-hidden for more) -o=<filename> - Override output filename -print-after-all - Print IR after each pass -print-before-all - Print IR before each pass -show-annotations - Add informational comments to the .ll file -time-passes - Time each pass, printing elapsed time for each on exit -version - Display the version of this programC:\work\llvm-3.4-tools-windows>llvm-dis -version LLVM (http://llvm.org/): LLVM version 3.4svn DEBUG build. Built Feb 24 2014 (21:50:43). Default target: i686-pc-win32 Host CPU: corei7-avx -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160216/c1968df5/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: c6.bc Type: application/octet-stream Size: 6899 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160216/c1968df5/attachment.obj>
Mehdi Amini via llvm-dev
2016-Feb-16 01:13 UTC
[llvm-dev] invalid signature error (old bitcode, new tools)
> On Feb 15, 2016, at 4:57 PM, Muhammad Umar Janjua via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > At some point in 2005/6, I was using an older version of llvm-gcc. > I generated files with bytecode using llvm tools at that time. > > It was GNU C version 3.4-llvm 20030924 (experimental) (i686-pc-linux-gnu) > ; compiled by GNU C version 3.4.0.As you can see from http://llvm.org/releases/ ; the version 3.4 was released in 2014. Back in 2005/2006 it seems that the version was 1.X. The message you see with 3.4 means probably that this version of llvm-gcc was compiled with (against?) gcc-3.4.> > I somehow lost these old tools. But after a decade, I still want to disassemble these old result files to see the code.You'll have to use an older version of LLVM to read these files. Start with version 3.0, and if it does not work you can try 2.0, and then try to pinpoint the exact 1.x release if needed. (I don't know if there was a record with the version in the bitcode at that time?) -- Mehdi> > > So I downloaded some windows llvm tools to disassemble a bytecode file into .ll file to view the disassembly code. > > However, I am seeing an invalid bitcode signature error. > > Now there could be some changes in the format that the newer version insists on. > > Could some one help me with llvm-dis for windows that can disassemble the attached c6.bc file? > > > > > C:\work\llvm-3.4-tools-windows>llvm-dis c:\ImportantDocs\experiments\c6.bc > llvm-dis: Invalid bitcode signature > > C:\work\llvm-3.4-tools-windows>llvm-dis -help > OVERVIEW: llvm .bc -> .ll disassembler > USAGE: llvm-dis [options] <input bitcode> > OPTIONS: > -f - Enable binary output on terminals > -help - Display available options (-help-hidden for more) > -o=<filename> - Override output filename > -print-after-all - Print IR after each pass > -print-before-all - Print IR before each pass > -show-annotations - Add informational comments to the .ll file > -time-passes - Time each pass, printing elapsed time for each on exit > -version - Display the version of this program > C:\work\llvm-3.4-tools-windows>llvm-dis -version > LLVM (http://llvm.org/): > LLVM version 3.4svn > DEBUG build. > Built Feb 24 2014 (21:50:43). > Default target: i686-pc-win32 > Host CPU: corei7-avx > > <c6.bc>_______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160215/4806fea4/attachment-0001.html>
Tim Northover via llvm-dev
2016-Feb-16 01:33 UTC
[llvm-dev] invalid signature error (old bitcode, new tools)
Hi Muhammad, On 15 February 2016 at 16:57, Muhammad Umar Janjua via llvm-dev <llvm-dev at lists.llvm.org> wrote:> It was GNU C version 3.4-llvm 20030924 (experimental) (i686-pc-linux-gnu) > ; compiled by GNU C version 3.4.0.I think this means it was an unspecified version of LLVM linked to something close to GCC 3.4. So starting with LLVM 3.4 (much much newer) is problematic.> However, I am seeing an invalid bitcode signature error.In summer 2007 we changed LLVM IR's binary representation. Before that it was called "bytecode", after that "bitcode". Soon afterwards, support for reading bytecode was removed. So the chances are your files are in this older format which nothing newer than 2007 can read. Unfortunately, I think (it was before my time, so rumour only) that bytecode was less backwards-compatible than bitcode too. So what you probably actually want the closest version match possible to what produced that file. All the releases from 1.0-1.9 seem like candidates, based on the date above. And even 1.0 may be too new. Again unfortunately, we have the perfect trifecta: official Windows releases don't go back that far; the Linux binaries don't seem to contain a disassembler anyway; and the source doesn't build with modern compilers. Unless anyone has better ideas, your best option is probably to create an ancient Linux VM and try to rebuild the source versions. Tedious work, but those files are near prehistoric. Cheers. Tim.