Thread: redhat debug info
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?
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
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
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/
Attachment
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.
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 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. >
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/ > From each according to his ability. To each according to his ability to litigate.
Attachment
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.
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