headers
Philippe Elie | 2 Jul 2003 12:19
Picon

Re: separated debuginfo patch

graydon hoare wrote:
> hi,
> 
> the following is a patch which adds support for looking up debugging
> symbols in "separated debuginfo files", which appear in newer versions
> of RHL (possibly elsewhere?). they're ELF files which have the

is this already in production distro or only as alpha code ?

> debugging sections (but none of the .text sections) of some other ELF
> file. they can be installed separately, from a -debuginfo RPM, so when
> you realize you *want* to profile or debug a file, you just install
> its -debuginfo RPM and run the debugger or profiler again.
> 
> the connection between the "main" binary and its debuginfo file is
> made via some well defined name mangling and a crc32 of the debuginfo
> file which is embedded in the main file. 

"well defined" ? reading the code I'm unusure of that. Elaborate please

I'm also confused by the name debuginfo, is opannotate --source
working with this patch or is it working only for symbol name
information ?

> 
> comments / corrections? ok to apply?

I think it's a good idea to support separate debug info but I prefer
John comment this idea.
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Levon | 2 Jul 2003 14:13
Favicon

Re: separated debuginfo patch

On Wed, Jul 02, 2003 at 10:19:17AM +0000, Philippe Elie wrote:

> Also is this features added to binutils or need a separate

Strongly agree, I have no idea why RH are making every tool duplicate
this code instead of having libbfd find the debug images itself. Can you
explain please Graydon ?

regards
john

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 3 comments |
headers
Al Stone | 2 Jul 2003 19:09
Picon

Re: OProfile changes for Debian packaging

On Wed, 2003-07-02 at 06:10, John Levon wrote:
> On Tue, Jul 01, 2003 at 04:49:01PM -0600, Al Stone wrote:
> 
> > Oops.  Sorry about that; I wasn't thinking about this
> > very clearly, I guess.
> > 
> > Please find attached a diff that makes more sense.
> 
> +Upstream Author(s):
> +   John Levon    <moz <at> compsoc.man.ac.uk>
> 
> I guess you can remove the brackets :) And please use
> <levon <at> movementarian.org>

Done.

> +++ oprofile-debian/ReleaseNotes        2003-06-25 11:23:26.000000000
> -0600
> 
> Does debian demand this file to exist ? It's slightly more awkward for
> us to include it...

No.  It's for convenience, more than anything else.

None of the debian changes have to be in the oprofile
CVS tree.  You could choose to include none of these;
it's normally considered the responsibility of the debian
package maintainer to synchronize the CVS tree with any
changes made for packaging.  It's a very minor step for
me to include this with new releases and I don't mind
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Levon | 2 Jul 2003 19:34
Favicon

Re: OProfile changes for Debian packaging

On Wed, Jul 02, 2003 at 11:09:19AM -0600, Al Stone wrote:

> > +++ oprofile-debian/ReleaseNotes        2003-06-25 11:23:26.000000000
> 
> None of the debian changes have to be in the oprofile
> CVS tree.  You could choose to include none of these;
> it's normally considered the responsibility of the debian
> package maintainer to synchronize the CVS tree with any

OK. I'd prefer to keep this part separate then.

> > +dnl AC_TRY_COMPILE([#include <bfd.h>], [],
> > +AC_COMPILE_IFELSE([#include <bfd.h>],
> > 
> > Why  ? What  does this macro do ? It seems undocumented. Does it work
> > with autoconf 2.13 ?
> 
> Using the debian unstable release, AC_TRY_COMPILE was
> reported as being deprecated and that AC_COMPILE_IFELSE
> was to be used instead (autoconf 2.57 and automake 1.7.5).
> That's was why I replaced it.  I don't believe it works
> in 2.13; I can go either way on whether it's a necessary
> change or not -- it does keep some warnings out of the
> build of the package.

The warnings should just be ignored until autoconf 2.13 is no longer
supported IMO.

> Not that I've been able to come up with yet :(.  This
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe Elie | 2 Jul 2003 23:56
Picon

Re: separated debuginfo patch

John Levon wrote:
> On Wed, Jul 02, 2003 at 10:19:17AM +0000, Philippe Elie wrote:
> 
> 
>>Also is this features added to binutils or need a separate
> 
> 
> Strongly agree, I have no idea why RH are making every tool duplicate
> this code instead of having libbfd find the debug images itself. Can you
> explain please Graydon ?

an attempt has been made

http://sources.redhat.com/ml/binutils/2003-01/msg00541.html

regards,
Phil

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 2 comments |
headers
John Levon | 3 Jul 2003 00:32
Favicon

Re: separated debuginfo patch

On Wed, Jul 02, 2003 at 09:56:07PM +0000, Philippe Elie wrote:

> http://sources.redhat.com/ml/binutils/2003-01/msg00541.html

But Daniel's question here :

http://sources.redhat.com/ml/binutils/2003-01/msg00547.html

was never answered. If merging can be avoided, then perhaps libbfd could
still do it.

GDB seems to have a tradition of duplicating stuff anyway. I'd rather
rely on libbfd if we possibly can.

regards,
john

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 0 comments |
headers
graydon hoare | 3 Jul 2003 00:47
Picon
Favicon

Re: separated debuginfo patch

Philippe Elie <phil.el <at> wanadoo.fr> writes:

> John Levon wrote:
> > On Wed, Jul 02, 2003 at 10:19:17AM +0000, Philippe Elie wrote:
> >
> >>Also is this features added to binutils or need a separate
> > Strongly agree, I have no idea why RH are making every tool duplicate
> > this code instead of having libbfd find the debug images itself. Can you
> > explain please Graydon ?
> 
> an attempt has been made
> 
> http://sources.redhat.com/ml/binutils/2003-01/msg00541.html

not only that, but they accepted and applied it upstream...

http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/opncls.c?rev=1.18&content-type=text/x-cvsweb-markup&cvsroot=src

three cheers for mandatory code review, I'd forgotten that. we were
just cleaning up leftover oprofile patches which haven't made it
upstream yet, and I ran across that one. 

I'm just now working out exactly how far the skew on our end is; it
looks like some of our recent binutils packages are a bit out of date
relative to the upstream. anyways, you definitely shouldn't use that
patch, you're right. I'll post a better one shortly.

-graydon

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
graydon hoare | 3 Jul 2003 01:38
Picon
Favicon

Re: separated debuginfo patch

oh, also, to answer your questions:

Philippe Elie <phil.el <at> wanadoo.fr> writes:

> is this already in production distro or only as alpha code ?

it's been in our production distro for a couple releases now, I
think. was introduced in either 8.0 or somewhere in the 8.0.1 / 8.1
beta releases before 9. I don't recall precisely. 9 has it for sure.

> > the connection between the "main" binary and its debuginfo file is
> > made via some well defined name mangling and a crc32 of the debuginfo
> > file which is embedded in the main file.
> 
> "well defined" ? reading the code I'm unusure of that. Elaborate please

for ELF image 'foo', the algorithm looks for a section in foo called
'.gnu_debuglink'. that section contains a filename and a crc32
checksum. the filename is typically 'foo.debug'. the algorithm then
looks for the filename in the following locations, in order:

  - in the same directory as the open BFD for foo
  - a subdirectory called .debug
  - a global directory (/usr/lib/debug or such) followed by the
    dirname of the open BFD for foo.

if it finds such a file, it checksums the file and compares against
the embedded crc32 value. if the checksums match, the debuginfo file
is loaded.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe Elie | 3 Jul 2003 10:36
Picon

Re: separated debuginfo patch

cc'ing binutils list

hi, we was discussing about the separate debug info files.
I've some doubt than crc is the right way to check for debug
file match.

graydon hoare wrote:
> oh, also, to answer your questions:
> 
> Philippe Elie <phil.el <at> wanadoo.fr> writes:

>>calc_crc32 in a separate file but I don't like the fact we
>>need to crc32 the whole debug info file, these files can
>>be numberous and voluminous, if this feature is not already
>>in RH production distro can I ask the debuginfo file is
>>augmented with a section containing the check sum, then we
>>don't need to recalcultate the check sum but just compare
>>the checksum in .gnu_debuglink and the checksum in the debug
>>file. It'll speed up a lot operation like opreport -l.

Changed my mind, now I think a timestamp is better.
This sort of problem is generally solved by a timestamp
(64 bits) not a crc, both file contain the same timestamp and
the timestamp must be equal, imho crc is usefull to check file
corruption not file matching

> hm, but then the checksum may be incorrect. in fact it is kind of
> pointless to use a checksum at all if it is not checked; we might as
> well just use a large random binary string.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Levon | 3 Jul 2003 12:50
Favicon

Re: separated debuginfo patch

On Wed, Jul 02, 2003 at 07:38:48PM -0400, graydon hoare wrote:

> > > +void op_bfd::add_to_section_map(bfd * abfd, asection * sect, PTR obj)
> > 
> > (obj == this) remove this paramater please
> 
> I'm afraid I cannot. this is a static function in the op_bfd
> namespace, not a method of an op_bfd object. the 'this' pointer
> doesn't exist. the function is a callback that libbfd is calling, as

My preferred idiom for this is a file-scope C callback that does the
pointer manipulation :

extern "C" {

static void add_to_map(bfd * abfd, asection * sect, void * obj)
{
	op_bfd * opbfd = static_cast<op_bfd *>(obj);
	assert(obbfd);
	opbfd->add_to_section_map(abfd, sect);
}

};

I vaguely remember discussing whether static C++ methods can be safely
called from C code or not ... I forget the conclusion. But I prefer the
above anyway.

regards
john
(Continue reading)

Permalink | Reply | 0 comments |

Gmane