How to you disassemble a program using gcc?
How to you disassemble a program using gcc?
You don't. That's not what gcc is for.Originally Posted by herWter
You might try "objdump -d" or "ndisasm"
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Or gdb's disassemble command.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Is there anyway to get objdump -d to show only assembly and output directly to a file?
I don't know about the first part, but the second part is easy, just pipe it to a file using '>', eg.
objdump -d > myfile.txt
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
Thanks. That worked. I suppose I could make a program to sort out the assembly. Alright last thing. Having the assembly to a program is almost as valuable as the source code. This just seems to good to be true. Am I blindly missing something?
Yeah. It's just about impossible to sift through thousands of lines of code.... which were most likely generated from much fewer lines of source code. Plus you ain't got no comments on any of it. You'd need to execute it with breakpoints and run-time traps on everything that appears to be variables in order to trace its execution path.
In short. It's not maintenance friendly. And not particularly enlightening if you wanted to figure out some algorithm that was used. Just too much noise to find any good programming logic goodies buried within.
In other words, assembly is not nearly as valuable as source code. Your assumption is simply wrong.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Unless you study Assembly for that particular processor until you are blue in the face, pouring through the instruction set and various indirection rules. If you are competent enough at Assembly, you can pretty much just read what's going on as you peruse the file. However, you will still need to spend time going in to fill out labels and comments which could take up a year or so of your time. Having done that, yes, it will actually be better than C due to the fact that you can eliminate all of the wasted operations and get down to only what the processor needs in order to perform the functions. Even when highly optimized, compiled C applications run at least about 40% larger than the same applications written purely in Assembly. The price you pay for this almost double in performance would be about another year, plus the fact that your code is now stuck on an exact processor. What you would get back, however, is that you could squeeze a lot more instant-feeling productivity onto a much smaller system (say, a 32-bit processor having 512KB of application space and 64KB of RAM). Too bad there is no machine-independent Assembly language yet beyond .NET IL, though. It would be so nice to instantly compile the same application natively to hardware whether the target was ARM, PowerPC, eZ80, or x86 - with or without an OS running under, no questions asked, for a change! :-)
Agree. You can not easily write really fast code. That's only true if you are a really great assembly programmer. And most people aren't. Compiler writers put really much effort in optimization, trying to be better than the others. So, optimization + C code is often "better" than pure hand-coded assembly, maybe not as fast, but really easy to write compared to it, and you can run it on any machine (theoretically).
You are
The fact that you can get gdb to show you the assembly for each line of code instead of dumping the whole program/source file.
Debugging with GDB: Source, for starters.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
wait, isn't this exactly what 'crackers' do to make 'fixed' executables that don't check security 'cause the code has been erased or something?
Currently research OpenGL
You can understand the asm code to a degree that allows you to "patch out" checks, but to figure out the logics of the whole program takes A LOT more time.
Whoa, major thread necromancy here.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
