Re: [Gold linker] Incremental linking in C++

[Cary Coutant <ccoutant at gmail dot com>]

> I would like to use incremental linking in my C++ project.
>
> However, I understand from this report:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=13442
>
> ...that incremental linking disables eh_frame_hdr generation.
> Naturally, the inability to catch any thrown exception makes using
> this functionality for C++ development virtually impossible.
>
> I was wondering if there is any planned effort to make this
> functionality work?  Someone in the report was asking for help in
> implementing it on his own, would it be possible to review what the
> necessary steps are?

The .eh_frame_hdr section is (supposed to be) an optional section that
helps the EH mechanism search more efficiently. Without it, EH should
still work, but the lookup in the EH table is slower.

Implementing support for generating the .eh_frame_hdr section would
slow down an incremental link and most likely would force more
frequent full links.

The point of incremental linking is to speed up the edit/compile/debug
cycle, so it doesn't really make sense to me to spend extra time
linking in order to improve run-time performance.


> P.S.  I also hit a crash in this code in incremental.cc.
>
> 2267 // Get the name of a section.  This returns the name of the output
> 2268 // section, because we don't usually track the names of the input
> 2269 // sections.
> 2270
> 2271 template<int size, bool big_endian>
> 2272 std::string
> 2273 Sized_relobj_incr<size, big_endian>::do_section_name(unsigned int
> shndx) const
> 2274 {
> 2275   const Output_sections& out_sections(this->output_sections());
> 2276   const Output_section* os = out_sections[shndx];
> 2277   if (os == NULL)
> 2278     return NULL;
> 2279   return os->name();
> 2280 }
>
> Returning NULL on line 2278 quickly crashes because std::string makes
> an implicit construction from the null pointer.

Sorry! I'll fix that.

-cary