Finding out Function addresses from gcc

[gommo]

I'm compiling my kernel as a flat binary file using gcc and would like to know if there is a setting to output a debug file or something where I can find out the function addresses for all my functions??

I'd like to add breakpoints in bfe2(bochs) but I need to know the function addresses etc..

Thanks

[HOS]

I use the -Map mapfile option for ld which does what you want. I am not sure if this option will work as a gcc parameter or not. If not, you can easily seperate your build steps into a gcc -c command and a ld command.

[Solar]

objdump -d a.out | grep "^[^ ]"

[Candy]

I use the -Map mapfile option for ld which does what you want. I am not sure if this option will work as a gcc parameter or not. If not, you can easily seperate your build steps into a gcc -c command and a ld command.

I use that too, but I parse the map file to only give me things I'm interested in:

cat kernel.*.Map | grep " 0x00000000" | sort | less

Not that sure about the grep, but it's something like this.

[srthb]

gcc -g !

[Pype.Clicker]

gcc -g !

The CodePoet strikes again with Yet Another Useful Comment ...
the '-g' flag in GCC turns on internal debugging information. It is certainly necessary if you wish 'objdump -d' to work, for instance (afaik), but it will not provide *you* the information until you have a GDB-compliant debugger ... and i doubt bochs or any other virtual PC can go that far ...

[Solar]

The '-g' flag in GCC turns on internal debugging information. It is certainly necessary if you wish 'objdump -d' to work, for instance (afaik)...

objdump always works, even with stripped executables. -g just adds additional information (like, variable names), but all functions with external linkage are required to keep their symbol names anyway (or you couldn't link to them).

...but it will not provide *you* the information until you have a GDB-compliant debugger...

Little to do with GDB. External linkage symbols are defined by ELF (or whatever format you use), and the rest by the debugging format you chose (e.g. DWARF). Either are well defined, and understood by several other debuggers.

Just to be correct. (Hi Candy! )