Hey folks, This is great to see more interest on the supporting tools like objdump and such. I very much agree that bringing llvm-objdump up to feature parity (to start with) compared to both otool(1) and objdump(1) is a great goal. The default output formatting is easy enough to get right by having it be controlled by the container format (otool style for macho, objdump style for ELF). Kevin’s right that where this gets a bit interesting is command line option handling. The prevailing wisdom from clang and lld so far seems to the alternatives Kevin mentions of sniffing argv[0] and/or having a —flavor or —format option. IMO, for now we can just do the latter, which is the simpler thing, while we get the real functionality in place. Then when we’re ready to, optionally as packagers decide to opt-in, use llvm-objdump to replace the system version, we can figure out the right way to make that transition nice and clean. -jim> On Dec 1, 2014, at 4:40 PM, Kevin Enderby <enderby at apple.com> wrote: > > Hi Steve, > > I’ve been trying to get the functionality of llvm-objdump to match that of darwin’s otool(1). In adding the support for symbolic disassembly and to allow testing of it on very large files that would allow the disassembly to diff cleanly, I added a few options to llvm-objdump and to tool(1). For example these would be the two command lines I would use for testing: > > llvm-objdump -d -m -no-show-raw-insn -full-leading-addr -print-imm-hex … > otool -tV -U -no-show-raw-insn … > > Longest term I hope to see llvm-objdump take over all of darwin’s otool(1) functionality. Not sure the best way of going this for command line options as the trick of passing them differently based on argv[0] may not work. There may need to be some wrapper to do that. And also their may need to be some option like llvm-nm’s "-format XXX” to get the output to match so scrips can use the output. > > I’ve Cc’ed Jim Grosbach as he may have some guidance on this. > > My thoughts, > Kev > > On Dec 1, 2014, at 4:20 PM, Steve King <steve at metrokings.com> wrote: > >> Hello LLVM, >> >> Previously, some folks wanted llvm-objdump to behave more like GNU >> objdump. This could encompass both command line options and output >> format. Such a change helps developers already familiar with GNU >> tools and allows re-use of Perl scripts or other automation expecting >> to see GNU style dumps. >> >> Is moving llvm-objdump toward GNU objdump the general preference? And >> what about otools style output? >> >> Regards, >> -steve >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Hi guys, thanks for responding. Will mimicking both otool and objdump in one binary become unwieldy? Maybe a disassembler library would be a better way to factor out common code? For example, will Kevin's symbolizing work be relevant for ELF files? Regards, -steve On Mon, Dec 1, 2014 at 4:50 PM, Jim Grosbach <grosbach at apple.com> wrote:> Hey folks, > > This is great to see more interest on the supporting tools like objdump and such. I very much agree that bringing llvm-objdump up to feature parity (to start with) compared to both otool(1) and objdump(1) is a great goal. The default output formatting is easy enough to get right by having it be controlled by the container format (otool style for macho, objdump style for ELF). Kevin’s right that where this gets a bit interesting is command line option handling. The prevailing wisdom from clang and lld so far seems to the alternatives Kevin mentions of sniffing argv[0] and/or having a —flavor or —format option. IMO, for now we can just do the latter, which is the simpler thing, while we get the real functionality in place. Then when we’re ready to, optionally as packagers decide to opt-in, use llvm-objdump to replace the system version, we can figure out the right way to make that transition nice and clean. > > -jim > > >> On Dec 1, 2014, at 4:40 PM, Kevin Enderby <enderby at apple.com> wrote: >> >> Hi Steve, >> >> I’ve been trying to get the functionality of llvm-objdump to match that of darwin’s otool(1). In adding the support for symbolic disassembly and to allow testing of it on very large files that would allow the disassembly to diff cleanly, I added a few options to llvm-objdump and to tool(1). For example these would be the two command lines I would use for testing: >> >> llvm-objdump -d -m -no-show-raw-insn -full-leading-addr -print-imm-hex … >> otool -tV -U -no-show-raw-insn … >> >> Longest term I hope to see llvm-objdump take over all of darwin’s otool(1) functionality. Not sure the best way of going this for command line options as the trick of passing them differently based on argv[0] may not work. There may need to be some wrapper to do that. And also their may need to be some option like llvm-nm’s "-format XXX” to get the output to match so scrips can use the output. >> >> I’ve Cc’ed Jim Grosbach as he may have some guidance on this. >> >> My thoughts, >> Kev >> >> On Dec 1, 2014, at 4:20 PM, Steve King <steve at metrokings.com> wrote: >> >>> Hello LLVM, >>> >>> Previously, some folks wanted llvm-objdump to behave more like GNU >>> objdump. This could encompass both command line options and output >>> format. Such a change helps developers already familiar with GNU >>> tools and allows re-use of Perl scripts or other automation expecting >>> to see GNU style dumps. >>> >>> Is moving llvm-objdump toward GNU objdump the general preference? And >>> what about otools style output? >>> >>> Regards, >>> -steve >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >
At least for now, I don’t expect it to become all that unwieldy. Any behavioral differences should be easily separable into different classes and source files. If as things progress it becomes obvious that there’s really not much of anything in common other than the general nature of the tools, it’s easy to split them apart. -Jim> On Dec 1, 2014, at 5:20 PM, Steve King <steve at metrokings.com> wrote: > > Hi guys, thanks for responding. Will mimicking both otool and objdump > in one binary become unwieldy? Maybe a disassembler library would be > a better way to factor out common code? For example, will Kevin's > symbolizing work be relevant for ELF files? > Regards, > -steve > > > On Mon, Dec 1, 2014 at 4:50 PM, Jim Grosbach <grosbach at apple.com> wrote: >> Hey folks, >> >> This is great to see more interest on the supporting tools like objdump and such. I very much agree that bringing llvm-objdump up to feature parity (to start with) compared to both otool(1) and objdump(1) is a great goal. The default output formatting is easy enough to get right by having it be controlled by the container format (otool style for macho, objdump style for ELF). Kevin’s right that where this gets a bit interesting is command line option handling. The prevailing wisdom from clang and lld so far seems to the alternatives Kevin mentions of sniffing argv[0] and/or having a —flavor or —format option. IMO, for now we can just do the latter, which is the simpler thing, while we get the real functionality in place. Then when we’re ready to, optionally as packagers decide to opt-in, use llvm-objdump to replace the system version, we can figure out the right way to make that transition nice and clean. >> >> -jim >> >> >>> On Dec 1, 2014, at 4:40 PM, Kevin Enderby <enderby at apple.com> wrote: >>> >>> Hi Steve, >>> >>> I’ve been trying to get the functionality of llvm-objdump to match that of darwin’s otool(1). In adding the support for symbolic disassembly and to allow testing of it on very large files that would allow the disassembly to diff cleanly, I added a few options to llvm-objdump and to tool(1). For example these would be the two command lines I would use for testing: >>> >>> llvm-objdump -d -m -no-show-raw-insn -full-leading-addr -print-imm-hex … >>> otool -tV -U -no-show-raw-insn … >>> >>> Longest term I hope to see llvm-objdump take over all of darwin’s otool(1) functionality. Not sure the best way of going this for command line options as the trick of passing them differently based on argv[0] may not work. There may need to be some wrapper to do that. And also their may need to be some option like llvm-nm’s "-format XXX” to get the output to match so scrips can use the output. >>> >>> I’ve Cc’ed Jim Grosbach as he may have some guidance on this. >>> >>> My thoughts, >>> Kev >>> >>> On Dec 1, 2014, at 4:20 PM, Steve King <steve at metrokings.com> wrote: >>> >>>> Hello LLVM, >>>> >>>> Previously, some folks wanted llvm-objdump to behave more like GNU >>>> objdump. This could encompass both command line options and output >>>> format. Such a change helps developers already familiar with GNU >>>> tools and allows re-use of Perl scripts or other automation expecting >>>> to see GNU style dumps. >>>> >>>> Is moving llvm-objdump toward GNU objdump the general preference? And >>>> what about otools style output? >>>> >>>> Regards, >>>> -steve >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >>
On 2 December 2014 at 00:50, Jim Grosbach <grosbach at apple.com> wrote:> Then when we’re ready to, optionally as packagers decide to opt-in, use llvm-objdump to replace the system version, we can figure out the right way to make that transition nice and clean.What about llvm-otool being a symlink to llvm-objdump and get the bin name as a --flavour default? This way we could have both on all arches... cheers, --renato
On Thu, Dec 4, 2014 at 9:16 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 2 December 2014 at 00:50, Jim Grosbach <grosbach at apple.com> wrote: >> Then when we’re ready to, optionally as packagers decide to opt-in, use llvm-objdump to replace the system version, we can figure out the right way to make that transition nice and clean. > > What about llvm-otool being a symlink to llvm-objdump and get the bin > name as a --flavour default? This way we could have both on all > arches...I agree, using lld-style command-line option flavors (and getting a real option parser into llvm-objdump) looks like the right way to me. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
Sure, that sounds good. I just personally don’t see it as very high priority right now since there’s significant functionality still missing. Others, of course, may have different priorities, and I’d be happy to see patches along those lines if anyone is so inclined. -Jim> On Dec 4, 2014, at 9:16 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 2 December 2014 at 00:50, Jim Grosbach <grosbach at apple.com> wrote: >> Then when we’re ready to, optionally as packagers decide to opt-in, use llvm-objdump to replace the system version, we can figure out the right way to make that transition nice and clean. > > What about llvm-otool being a symlink to llvm-objdump and get the bin > name as a --flavour default? This way we could have both on all > arches... > > cheers, > --renato