OT: Why -g when compiling

[Miki Tebeka]

Hello All,

Can anyone tell me why when builiding Python gcc gets "-g" option as well as "-O3"?
Apart from bigger objects what does "-g" gives a non-developer of Python?

Thanks.
Miki

 

[Nicolas =?ISO-8859-15?Q?Favre=2DF=E9lix?=]

Hello All,

Can anyone tell me why when builiding Python gcc gets "-g" option as well
as "-O3"? Apart from bigger objects what does "-g" gives a non-developer
of Python?

Debug mode.

 

[Michael Hudson]

Hello All,

Can anyone tell me why when builiding Python gcc gets "-g" option as well as "-O3"?
Apart from bigger objects what does "-g" gives a non-developer of Python?

It means if you manage to core python, we can hold your hands to find
out with gdb where it's crashed. Why do you ask? Disk space is cheap.

Cheers,
mwh

 

[Miki Tebeka]

Hello Michael,

It means if you manage to core python, we can hold your hands to find
out with gdb where it's crashed. Why do you ask?

Just out of curiosity. Seen it in many apps when building and always
wondered.

Disk space is cheap.

Yes but memory sometimes isn't. On my cygwin installation the
libpython2.3.dll goes from 2.9MB to 1.1MB. On machines with little RAM
(embdded ...) this matters a lot.

Thanks.
Miki

 

[Irmen de Jong]

Yes but memory sometimes isn't. On my cygwin installation the
libpython2.3.dll goes from 2.9MB to 1.1MB. On machines with little RAM
(embdded ...) this matters a lot.

Use strip after a compile?

--Irmen

 

[Michael Hudson]

Hello Michael,

Just out of curiosity. Seen it in many apps when building and always
wondered.

Yes but memory sometimes isn't.

True. I don't know if the various linkers around are smart enough to
not load debugging information until it's asked for...

On my cygwin installation the libpython2.3.dll goes from 2.9MB to
1.1MB. On machines with little RAM (embdded ...) this matters a lot.

Oh sure, but if you're in an embedded situation, I would *hope* that
you don't just blindly use the default compile options!

Cheers,
mwh

 

[Miki Tebeka]

Hello Michael,

Oh sure, but if you're in an embedded situation, I would *hope* that
you don't just blindly use the default compile options!

Just toying with the idea...

Miki

 

[Erno Kuusela]

I don't know if the various linkers around are smart enough to
not load debugging information until it's asked for...

afaik the dynamic linker (or kernel) never loads the debugging info,
that' be the job of the debugger. the debugging info gets put in a
separate section in the binary.

-- erno

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

True. I don't know if the various linkers around are smart enough to
not load debugging information until it's asked for...

Atleast on Unix, not mapping debug information at run time has a long
tradition. In ELF, each section has a LOAD flag indicating whether
a section needs to be mapped or not. So the ELF dynamic loader does
not specifically know to omit debug information, but only loads
sections that the static linker told it to.

Regards,
Martin

 

[Michael Hudson]

Atleast on Unix, not mapping debug information at run time has a long
tradition. In ELF, each section has a LOAD flag indicating whether
a section needs to be mapped or not. So the ELF dynamic loader does
not specifically know to omit debug information, but only loads
sections that the static linker told it to.

That makes sense. I also guess that as shared libraries are mmaped
into the applications address space they won't use physical memory
until referenced anyway. But relocations probably mess with that.

Cheers,
mwh

 

[Martin v. =?iso-8859-15?q?L=F6wis?=]

That makes sense. I also guess that as shared libraries are mmaped
into the applications address space they won't use physical memory
until referenced anyway. But relocations probably mess with that.

That's what PIC (position-independent code) is for: The code itself
has no relocations, only centralized tables at the beginning of the
shared library (PLT: procedure linkage table, GOT: global offset
table) have relocations; they are tiny compared to the entire image.

On Windows, each DLL has a "preferred load address"; if the library is
loaded to this address, no relocations are needed (except in the
import stubs).

On OSX, the infamous "optimizing system" process invoked during
software installation precomputes the addresses of all symbols, and
puts updated code segments on disk which then can be mapped without
relocation.

Regards,
Martin