gcc disassembly

This is a discussion on gcc disassembly within the Tech Board forums, part of the Community Boards category; How to you disassemble a program using gcc?...

  1. #1
    Registered User
    Join Date
    Jun 2008
    Posts
    127

    gcc disassembly

    How to you disassemble a program using gcc?

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by herWter View Post
    How to you disassemble a program using gcc?
    You don't. That's not what gcc is for.

    You might try "objdump -d" or "ndisasm"
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  4. #4
    Registered User
    Join Date
    Jun 2008
    Posts
    127
    Is there anyway to get objdump -d to show only assembly and output directly to a file?

  5. #5
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by herWter View Post
    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.

  6. #6
    Registered User
    Join Date
    Jun 2008
    Posts
    127
    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?

  7. #7
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,831
    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.

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    In other words, assembly is not nearly as valuable as source code. Your assumption is simply wrong.
    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

  9. #9
    Registered User
    Join Date
    Jun 2009
    Posts
    1

    Unless, that is...

    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! :-)

  10. #10
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    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).

  11. #11
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    Quote Originally Posted by herWter View Post
    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?
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  12. #12
    Hail to the king, baby. Akkernight's Avatar
    Join Date
    Oct 2008
    Location
    Faroe Islands
    Posts
    717
    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

  13. #13
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,167
    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.

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Whoa, major thread necromancy here.
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Profiler Valgrind
    By afflictedd2 in forum C++ Programming
    Replies: 4
    Last Post: 07-18-2008, 09:38 AM
  2. Replies: 4
    Last Post: 09-02-2007, 08:47 PM
  3. Compiles on gcc 3.3 but not on gcc 4.0.3
    By cunnus88 in forum C++ Programming
    Replies: 5
    Last Post: 03-29-2007, 12:24 PM
  4. gcc configuration under linux advice needed
    By vart in forum Tech Board
    Replies: 9
    Last Post: 01-10-2007, 01:46 PM
  5. gcc
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 10-22-2003, 03:46 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21