On Thu, 3 Jan 2008 09:23:25 +0700 "Mulyadi Santosa"
<mulyadi.santosa@xxxxxxxxx> wrote:
:>> objdump --source foobar.o >foobar.debug
:>If gcc -g is not convincing, try to replace it with -ggdb
:>And for objdump, try this instead:
:>objdump -d -S foobar.o
That didn't help.
The best output I am getting is with
objdump --source -C -G -l -s foobar.o >foobar.debug
where, for many of the source statements, I get the line number but not the
actual source code (which is adequate). I am getting the source statements for
#included stuff.
And I discovered why I could not figure out the source code location based on
the object code. The source was calling an internal function which only had a
return statement (which called yet another function). The compiler, besides
generating the function where it was defined and exporting the label, also
directly invoked the subfunction rather than generating linkage to the defined
function. I.e., for
int foo1(int bar)
{
return foo2(bar);
}
.
.
x = foo1(bar);
The compiler generated
x = foo2(bar);
directly. I could not figure out how foo2 was called directly.
Most impressive of the compiler.
--
Binyamin Dissen <bdissen@xxxxxxxxxxxxxxxxxx>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
