Re: dwarf_output overview

[Roland McGrath <roland at redhat dot com>]

> The actual exception came from the dwarf_data::directory_table
> constructor that takes a dwarf::directory_table. Because it tries to
> convert the const char* directory strings from dwarf_getsrcdirs to
> std::strings. But the first entry is the CU directory path which can be
> NULL. If so the copy constructor throws because it cannot convert from
> NULL to std::string.

Hmm.  I didn't realize it could ever be null in practice.
What test data did this come up in?  It's probably invalid data
for a CU not to have a DW_AT_comp_dir.

> But then I get in similar trouble inside the subr::equal_to template
> code. Specifically the elfutils::subr::equal_to<std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >, char const*>::operator()
> instance, which will crash and burn trying to compare the empty string
> and the NULL. Still looking into that. 

I think those comparisons should work like dwarf::directory_table::table_equal 
and ignore the first element anyway.  I did a tweak to dwarf_data to do that.

> Hints and tips for how to
> generically deal with char*/std::string in C++ code appreciated.

This is the first case and perhaps only situation where a null pointer is a
possibility.  We've skipped it, so it shouldn't come up now.  I think any
other case that could produce a null string pointer should in fact throw an
error.  I'm not sure what other hints you are looking for.

Another general word on side tracks with the line info.  For the moment, we
could do fine to just ignore the line info as such.  We'll worry about all
that stuff once the tree handling is in good shape.  All that really
matters for the moment is the .source_file () stuff so that DW_AT_decl_file
et al can be compared.  

It may well be that we punt comparing the directory table at all.
That is a pending item for further consideration, but I won't get
into it right now.


Thanks,
Roland