I know of otool -tv, but I would much rather use the Intel syntax rather than AT&Ts, mainly to easily follow along in a book and not have to look over thousands of %'s and $'s.
I'd also appreciate any tips to where I might find gdb's config file.
EDIT: I forgot: I'm running a 64bit processor, but was wondering if it would be possible to also disassemble into 32 bit assembly? Not only that, but does OSX's gdb's list command work differently than the standard GNU version?
Thanks so much!
(Also, if you have any idea where I might find a little disassembler from C -> MIPS, that'd be very fun to play with. But not necessary!)
(I know this is an old question, but I want to provide an updated answer for people who come here through search engines).
On recent versions of macOS (I'm running 10.14.5), an objdump command is available, which is based on LLVM and is not the one from the GNU project. It offers a (hidden) option to disassemble using Intel syntax. For example, /bin/echo can be disassembled as follows:
objdump -disassemble -x86-asm-syntax=intel /bin/echo
To answer your second question, if the code has been compiled into a fat binary with both 64-bit and 32-bit, you can use otool -arch i386 -tv to disassemble the 32-bit slice of the binary; otool -arch x86_64 -tv will give you the 64-bit portion (on SnowLeopard, this is also the default behavior if no -arch flag is passed).
Also note that while otool doesn't support the Intel syntax, gdb (set disassembly-flavor intel) and XCode (Preferences -> Debugging -> Disassembly Style) do.
With Objdump you can disassemble with -d -M intel, and apparently -m can be used to specify the architecture.
For GDB, in your .gdbinit file, add:
set disassembly-flavor intel
then it will be the default syntax for gdb.
You can use A2I to translate from AT&T to Intel syntax: http://membres.lycos.fr/placr/a2i.html
Related
In .vimrc I set errorformat to intel cpp format(suppose it's %f %l--%m), but sometimes, I need gcc error format, Is there a way to switch between this without editing .vimrc or type long commands?
Thanks.
You're not expected/supposed to change the error format manually in these two cases. Indeed, Vim provides the :compiler command that loads a script (in {rtp}/compiler/) that sets 'efm' (and sometimes &makeprg as well).
In IOW:
Execute compiler icc to interpret Intel C++ compiler outputs
and execute compiler gcc to switch back to g++/clang++.
Context:
go 1.2, ubuntu 12.10
Goal:
Reduce size of compiled binaries
Currently in my build process, I run "go install" to generate the binary.
The I read from somewhere that if I pass in -w it will shrink the binary.
I tried it by passing it into the -ldflags option & my binary lost 1MB in size.
Is this -w flag documented anywhere? What does it actually do?
I then discovered the strip -s <binary> command and ran that on top of -w and got
another weight loss of 750KB ! The resulting binary runs fine. Does stripping
cause problems in any situations ?
You will get the smallest binaries if you compile with -ldflags '-w -s'.
The -w turns off DWARF debugging information: you will not be able to use gdb on the binary to look at specific functions or set breakpoints or get stack traces, because all the metadata gdb needs will not be included. You will also not be able to use other tools that depend on the information, like pprof profiling.
The -s turns off generation of the Go symbol table: you will not be able to use go tool nm to list the symbols in the binary. strip -s is like passing -s to -ldflags but it doesn't strip quite as much. go tool nm might still work after strip -s. I am not completely sure.
None of these — not -ldflags -w, not -ldflags -s, not strip -s — should affect the execution of the actual program. They only affect whether you can debug or analyze the program with other tools.
You can get help from go tool link
$ go tool link
...
-s disable symbol table
-w disable DWARF generation
The go help build says that
-ldflags 'flag list'
arguments to pass on each 5l, 6l, or 8l linker invocation.
So, we can invoke go tool 6l to see all it's options. One of them is
-w disable DWARF generation
By the way, 5l stands for ARM ($GOARCH = arm), 6l stands for x86-64 ($GOARCH = amd64), and 8l is for x86 ($GOARCH = 386).
If you really want to view raw DWARF info you should use dwarfdump -a on OS X and objdump -wg on Linux. Warning! Output will be long, very long.
I'm afraid it might cause problems in programs compiled with Go 1.2's gc suite of tools—refer to this discussion.
The general idea is that while Go compiles down to machine code just like C, it's more higher-level than C. For instance, it has built-in detailed panic() stack traces which depend on debug info. The sizes of the gc-generated binaries could indeed have been smaller, and it might be addresseed while cooking Go 1.3, but really the size of a compiled program in most today's environments is not a big deal to be too concerned about.
I've heard of colorgcc for coloring gcc outputs on the command line, but I can't find documentation on how to get this working on a mac (if it even does?). I'm not really willing to switch to an IDE, so If there are any alternatives for gcc coloring output that would be awesome.
Thanks
I wrote a x86 assembly program for MBR section.
I compile it as follows:
nasm hellombr.asm -f bin -o hellombr.img
Then I run it in qemu:
qemu -fda hellombr.img -boot a
The question is how can I debug my program at source level?
You should let nasm create the debugging symbols in an ELF file and then dump this to a flat binary to be used in the MBR. You can then instruct GDB to read the necessary symbols from the ELF file.
The complete procedure would then become something like this:
$ nasm hellombr.asm -f elf -g -o hellombr.elf
$ objcopy -O binary hellombr.elf hellombr.img
$ qemu -s -S -fda hellombr.img -boot a
$ gdb
(gdb) symbol-file hellombr.elf
(gdb) target remote localhost:1234
For an explanation of the flags I pass to qemu see this answer.
Instead of using qemu, use bochs. It is completely compatible, albeit slower. It is also an emulator but if you make it from sources, using these flags and build it like this:
./configure --enable-debugger --enable-disasm --disable-docbook
make
make install
you can place breakpoints in your code, step through it, view GDT, IDT and everything you needed to know.
A really good (and simple) way is to use IDA with bochs, you find an excellent blog post on it here, along with some other hints/suggestions for bootloader development.
I'm trying to make the --dynamic-linker option work with CodeSourcery's ARM cross toolchain. However gcc seems to ignore it, and never adds an interpreter segment in the shared library's ELF. What am I missing to make this work?
I doubt gcc ignores the option. Add -v to the compiler command line to verify that the option is indeed passed to the linker.
More likely, you are using the option incorrectly. --dynamic-linker is taking a =file argument, and you didn't mention that you are passing one.
Edit: as you found out, you have no .interp section in your linker script. However, you should - see this example.