This is the mail archive of the
mailing list for the binutils project.
Re: RFC: Generating per-function DWARF line number sections
- From: Alan Modra <amodra at gmail dot com>
- To: nick clifton <nickc at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Fri, 26 Apr 2013 21:48:11 +0930
- Subject: Re: RFC: Generating per-function DWARF line number sections
- References: <87haiyppev dot fsf at redhat dot com> <20130426021535 dot GB31074 at bubble dot grove dot modra dot org> <517A34F3 dot 2040002 at redhat dot com>
On Fri, Apr 26, 2013 at 09:04:03AM +0100, nick clifton wrote:
> Hi Alan,
> >Is it worth supporting the old style of grouping by name?
> Umm, I am not quite sure what you mean here. Can you provide an example ?
.text.foo, .rodata.foo, .data.foo etc.
> > Why not just support ELF section groups?
> This is the long term solution. It is a more invasive change
> however - requiring the cooperation of gcc as well as gas and ld.
> But, free time willing, this is the way that I intend to go.
> > Using names leads to eg. your
> >_bfd_elf_gc_mark_extra_sections change which is quadratic in number of
> Right - the current patch is not ideal, and I did consider
> constructing lists instead of the quadratic scan. But that is more
> complex, and I wanted to keep things simple for this first iteration
> of the patch, If it turns out that this scan is significant slow
> down for the linker then I can always come back and recode the loop
> >Also, why do this in gas? It seems to me that this sort of change
> >belongs in gcc.
> Because the .debug_line section for most ELF-based targets is now
> constructed by gas not gcc. Gcc emits .loc directives and gas
> converts them into .debug_line entries.
Ah, yes, fair enough. When you start looking at other debug sections
and .eh_frame I think you'll run into reloc problems, subtraction of
two symbols in different sections and suchlike. At least that's what
I recall from looking at this idea a number of years ago.
Australia Development Lab, IBM