redhat debug info

On Tue, Mar 27, 2007 at 03:57:49PM -0400, Joseph S wrote:

Does anyone know how this works and how I can get those files
from the pg tarball?

My guess: strip -o

Peter

Joseph S wrote:

Fedora/Redhat has debuginfo packages that drop files with debug symbols
in /usr/src/debug/, and gdb can use them. Does anyone know how this
works and how I can get those files from the pg tarball?

Where have you found these packages? Is this an rpm you have located?

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

Joseph S <jks@selectacast.net> writes:

Fedora/Redhat has debuginfo packages that drop files with debug symbols
in /usr/src/debug/, and gdb can use them. Does anyone know how this
works and how I can get those files from the pg tarball?

You download and install the postgresql-debuginfo RPM that exactly
matches your other postgresql RPM(s). AFAIK the debuginfo RPMs are
available but not installed by default ...

regards, tom lane

Geoffrey wrote:

Joseph S wrote:

Fedora/Redhat has debuginfo packages that drop files with debug
symbols in /usr/src/debug/, and gdb can use them. Does anyone know
how this works and how I can get those files from the pg tarball?

Where have you found these packages? Is this an rpm you have located?

From my yum conf file:
http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/debug/

Also when you build src rpms you get a debuginfo package.

Tom Lane wrote:

Joseph S <jks@selectacast.net> writes:

Fedora/Redhat has debuginfo packages that drop files with debug symbols
in /usr/src/debug/, and gdb can use them. Does anyone know how this
works and how I can get those files from the pg tarball?

You download and install the postgresql-debuginfo RPM that exactly
matches your other postgresql RPM(s). AFAIK the debuginfo RPMs are
available but not installed by default ...

regards, tom lane

I don't use rpms, I build from the tarballs, hence my question.

Joseph S <jks@selectacast.net> writes:

Tom Lane wrote:

You download and install the postgresql-debuginfo RPM that exactly
matches your other postgresql RPM(s).

I don't use rpms, I build from the tarballs, hence my question.

You'd have to dig into the RPM code enough to figure out how it
separates the debug info out of the executables. I've never paid
any attention, it's just something that happens magically at the
end of the RPM build process...

regards, tom lane

Tom Lane wrote:

Joseph S <jks@selectacast.net> writes:

Fedora/Redhat has debuginfo packages that drop files with debug symbols
in /usr/src/debug/, and gdb can use them. Does anyone know how this
works and how I can get those files from the pg tarball?

You download and install the postgresql-debuginfo RPM that exactly
matches your other postgresql RPM(s). AFAIK the debuginfo RPMs are
available but not installed by default ...

I just downloaded 8.2.3 for RHWS 5 but did not see a debuginfo rpm.
Also looked for them same for 7.4.16 but didn't find a debuginfo rpm on
the postgresql download site either.

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin

Geoffrey <esoteric@3times25.net> writes:

Tom Lane wrote:

You download and install the postgresql-debuginfo RPM that exactly
matches your other postgresql RPM(s).

I just downloaded 8.2.3 for RHWS 5 but did not see a debuginfo rpm.
Also looked for them same for 7.4.16 but didn't find a debuginfo rpm on
the postgresql download site either.

Hmm. Red Hat makes their debuginfo RPMs available in the normal course
of things (they're usually in a debug/ subdirectory of wherever you
find the RPMs) but I'm not sure whether Devrim et al have a policy about
whether to upload their debuginfo RPMs to the PG servers. They may feel
it's mostly a waste of bandwidth.

Anyway, the short answer is to download the source RPM and build it for
yourself ... most likely you want the source available anyway, if you're
going to be doing any debugging ...

regards, tom lane

Try searching on

postgresql-debuginfo

for the linux distribution and version you want at

http://rpm.pbone.net

Regards,

Ian Johnson

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Tom Lane
Sent: March 27, 2007 8:05 PM
To: Geoffrey
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] redhat debug info

Geoffrey <esoteric@3times25.net> writes:

Tom Lane wrote:

You download and install the postgresql-debuginfo RPM that exactly
matches your other postgresql RPM(s).

I just downloaded 8.2.3 for RHWS 5 but did not see a debuginfo rpm.
Also looked for them same for 7.4.16 but didn't find a debuginfo rpm on
the postgresql download site either.

Hmm. Red Hat makes their debuginfo RPMs available in the normal course
of things (they're usually in a debug/ subdirectory of wherever you
find the RPMs) but I'm not sure whether Devrim et al have a policy about
whether to upload their debuginfo RPMs to the PG servers. They may feel
it's mostly a waste of bandwidth.

Anyway, the short answer is to download the source RPM and build it for
yourself ... most likely you want the source available anyway, if you're
going to be doing any debugging ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Hi,

On Tue, 2007-03-27 at 22:04 -0400, Tom Lane wrote:

Red Hat makes their debuginfo RPMs available in the normal course
of things (they're usually in a debug/ subdirectory of wherever you
find the RPMs)

Fedora and Red Hat 5 users can download debuginfo packages via yum.
Fedora users need to use debuginfo channel (yum --enablerepo
debuginfo ...), and I think it is the same for RHEL 5.

Red Hat provides debuginfo packages via their FTP site (ftp.redhat.com).
You don't need to be a RHN subscriber to get a debuginfo package.

but I'm not sure whether Devrim et al have a policy about whether to
upload their debuginfo RPMs to the PG servers. They may feel it's
mostly a waste of bandwidth.

Exactly. I don't want to upload a package which is really big.

Anyway, the short answer is to download the source RPM and build it
for yourself ...

Yes, agreed.

Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/

Am Mittwoch, 28. M�rz 2007 03:00 schrieb Joseph S:

I don't use rpms, I build from the tarballs, hence my question.

Then use --enable-debug. You won't get the debug info in separate files, but
you don't need to.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Well 1) I'd like to avoid the performance penalty for including debug
symbols and 2) I already built the binary and it is running on a live
system, and I'd like to get debug symbols w/o restarting.

Peter Eisentraut wrote:

Am Mittwoch, 28. M�rz 2007 17:42 schrieb Joseph Shraibman:

Well 1) I'd like to avoid the performance penalty for including debug
symbols

There is no performance penalty for that.

and 2) I already built the binary and it is running on a live
system, and I'd like to get debug symbols w/o restarting.

You can't take somebody else's debugging symbols and add them to your
binaries.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Joseph Shraibman <jks@selectacast.net> writes:

Well 1) I'd like to avoid the performance penalty for including debug
symbols

There is none. If there were, it would certainly apply to debuginfo
as well --- debuginfo is merely moving the symbols over to a different
file after the compiler finishes.

and 2) I already built the binary and it is running on a live
system, and I'd like to get debug symbols w/o restarting.

You're contradicting yourself. You are worried in (1) that the
generated code isn't the same with -g, but in (2) you fantasize
that you could use the symbols to debug code built without it?

If you're willing to assume that that works, you can build ordinary
executables with -g and point gdb to them while attaching to the
existing processes. Personally I wouldn't trust that procedure,
as there are just too many ways to screw it up, and you can waste
a *whole* lot of time trying to gdb with a symbol table that doesn't
match the process's reality...

regards, tom lane

Tom Lane wrote:

Joseph Shraibman <jks@selectacast.net> writes:

Well 1) I'd like to avoid the performance penalty for including debug
symbols

There is none. If there were, it would certainly apply to debuginfo
as well --- debuginfo is merely moving the symbols over to a different
file after the compiler finishes.

I thought the performance penalty came from making the executable
bigger, which means the executor has to skip over the debug symbols
somehow, which eats up cpu. If the symbols are in a different file this
wouldn't apply.

and 2) I already built the binary and it is running on a live
system, and I'd like to get debug symbols w/o restarting.

You're contradicting yourself. You are worried in (1) that the
generated code isn't the same with -g, but in (2) you fantasize
that you could use the symbols to debug code built without it?

Well I don't really know how debug symbols work. It seems that maybe
all the debug info is is the source files with some mappling info then
maybe it might.

If you're willing to assume that that works, you can build ordinary
executables with -g and point gdb to them while attaching to the
existing processes.

Well I know that wouldn't work.

On Wed, Mar 28, 2007 at 02:16:55PM -0400, Joseph S wrote:

I thought the performance penalty came from making the executable
bigger, which means the executor has to skip over the debug symbols
somehow, which eats up cpu. If the symbols are in a different file this
wouldn't apply.

When running the executable is mmaped into memory. So any extra data in
the executable has absolutly zero effect.

Well I don't really know how debug symbols work. It seems that maybe
all the debug info is is the source files with some mappling info then
maybe it might.

No, the info is in the debug info (gdb can't be expected to understand
the source of every language you might want to debug).

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:

On Wed, Mar 28, 2007 at 02:16:55PM -0400, Joseph S wrote:

I thought the performance penalty came from making the executable
bigger, which means the executor has to skip over the debug symbols
somehow, which eats up cpu. If the symbols are in a different file this
wouldn't apply.

When running the executable is mmaped into memory. So any extra data in
the executable has absolutly zero effect.

Good to know. I'll always compile with debug info from now on.

Well I don't really know how debug symbols work. It seems that maybe
all the debug info is is the source files with some mappling info then
maybe it might.

No, the info is in the debug info (gdb can't be expected to understand
the source of every language you might want to debug).

I slipped up a little when typing that. What I meant to say is that the
files that are dumped into /usr/src/debug seem to be .c and .h files,
with one binary file. If that binary file is a map that matches
statements in the executable to text in the .c and .h then it could be
possible for those files to be generated w/o having to recompile the
executable, but no one here seems to know how to do that, so I'll just
have to recompile and restart.