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.
> Index: libutil++/op_bfd.cpp
> -op_bfd_symbol::op_bfd_symbol(asymbol const * a)
> +unsigned long
> +calc_crc32 (unsigned long crc, unsigned char *buf, size_t len)
> +{
> + static const unsigned long crc32_table[256] =
> + {
> + 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419,
...
> + 0x2d02ef8d
> + };
> + unsigned char *end;
> +
> + crc = ~crc & 0xffffffff;
> + for (end = buf + len; buf < end; ++buf)
> + crc = crc32_table[(crc ^ *buf) & 0xff] ^ (crc >> 8);
> + return ~crc & 0xffffffff;;
spurious ;
> +}
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.
Also is this features added to binutils or need a separate
RH only tools ? It'll be usefull to add it to ld or via a
new utility in binutils.
> +
> +static bool
> +find_separate_debug_file (bfd * ibfd,
> + string const & dir_in,
> + string const & global_in,
> + string & filename_out)
> +{
> + string dir(dir_in);
> + string global(global_in);
> + string basename;
> + unsigned long crc32;
> +
> + if (! get_debug_link_info(ibfd, basename, crc32))
> + return false;
> +
> + if (dir.size() > 0 && dir.at(dir.size() - 1) != '/')
> + dir += '/';
> +
> + if (global.size() > 0 && global.at(global.size() - 1) != '/')
> + global += '/';
> +
> + cverb << "looking for debugging file " << basename
> + << " with crc32 = " << hex << crc32 << endl;
> +
> + string first_try(dir + basename);
first_try look like the same as the original binary name, or perhaps
I'm mis-reading the code ?
> + string second_try(dir + ".debug/" + basename);
> +
> + if (dir.size() > 0 && dir[0] == '/')
> + dir = dir.substr(1);
> +
> + string third_try(global + dir + basename);
third_try seem evil except if .gnu_debuglink contain the full
pathname minus leading '/'
> +
> + if (separate_debug_file_exists(first_try, crc32))
> + filename_out = first_try;
> + else if (separate_debug_file_exists(second_try, crc32))
> + filename_out = second_try;
> + else if (separate_debug_file_exists(third_try, crc32))
> + filename_out = third_try;
> + else
> + return false;
Ok, repeating myself a bit: it seems evil than to support
*one* distro we need to handle three different name
encoding.
> +
> +
> +void op_bfd::add_to_section_map(bfd * abfd, asection * sect, PTR obj)
(obj == this) remove this paramater please
> +{
> + op_bfd * the_bfd = reinterpret_cast<op_bfd *>(obj);
the_bfd == this
> + assert(abfd);
> + assert(the_bfd);
remove it
> + assert(sect);
> + assert(sect->name);
> + the_bfd->section_offsets[sect->name] = sect->filepos;
section_offset[sect->name] = sect->filepos;
> +}
> +
|