This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: .debug_frame section - incorrect relocations?
- From: Alexey Neyman <stilor at att dot net>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Sat, 07 Dec 2013 11:18:44 -0800
- Subject: Re: .debug_frame section - incorrect relocations?
- Authentication-results: sourceware.org; auth=none
- References: <1466157 dot ehQ2qqM5T4 at mistral> <2675223 dot X6ZPJXMSfQ at mistral> <8017824 dot vhWvbRmRjN at mistral>
On Friday, December 06, 2013 11:52:38 PM Alexey Neyman wrote:
> On Friday, December 06, 2013 10:40:00 PM Alexey Neyman wrote:
> > On Friday, December 06, 2013 07:44:32 AM Ian Lance Taylor wrote:
> > > On Thu, Dec 5, 2013 at 11:38 PM, Alexey Neyman <stilor@att.net> wrote:
> > > > So, the question is, is it possible to express the behavior described
> > > > by
> > > > DWARF spec ("insert an address that is offset of the specified symbol
> > > > from the start of the specified output section") in x86-64 and i386
> > > > relocations? If it is, shouldn't gas generate such relocations?
> > >
> > > There is no straightforward way to express that in an object file.
> > >
> > > > If not - are there any solutions to have .debug_frame at non-zero
> > > > address,
> > > > yet with DWARF-conformat CIE links?
> > >
> > > I'm not aware of any. DWARF sections are normally at address zero.
> >
> > Thanks. Actually, this gave me an idea how to handle this using the
> > AT(...)
> >
> > attribute in the linker script:
> > __debug_frame_start = ALIGN(8);
> > .debug_frame 0 : AT(__debug_frame_start) { *(.debug_frame) }
> > . = __debug_frame_start + SIZEOF(.debug_frame);
> > __debug_frame_end = .;
>
> Somehow this only works for a single sections, and it seems to be triggering
> an ld bug. Here is a linker script fragment:
Please disregard; it was an error in the linker script (I didn't remove a
duplicate definition for .debug_info - and it was conflicting with THAT
definition).
Regards,
Alexey.
> [[[
> __debug_frame_start = ALIGN(8);
> .debug_frame 0 : AT(__debug_frame_start)
> {
> *(.debug_frame)
> }
> . = __debug_frame_start + SIZEOF(.debug_frame);
> __debug_frame_end = .;
>
> __debug_info_start = ALIGN(8);
> .debug_info 0 : AT(__debug_info_start)
> {
> *(.debug_info)
> }
> . = __debug_info_start + SIZEOF(.debug_info);
> __debug_info_end = .;
> ]]]
>
> The linker complains:
> ld: section .debug_info [00000000004440b8 -> 000000000050c361] overlaps
> section .debug_frame [00000000004440b8 -> 000000000044a907]
> ld: lsk_d.elf: section .debug_info lma 0x4440b8 overlaps previous sections
>
> In the map file, I have:
> 0x00000000004440b8 __debug_frame_start = ALIGN (0x8)
> .debug_frame 0x0000000000000000 0x6850 load address 0x00000000004440b8
> 0x000000000044a908 . = (__debug_frame_start +
> SIZEOF(.debug_frame)
> 0x000000000044a908 __debug_frame_end = .
> 0x000000000044a908 __debug_info_start = ALIGN (0x8)
> .debug_info 0x0000000000000000 0xc82aa load address 0x000000000044a908
> 0x0000000000512bb2 . = (__debug_info_start +
> SIZEOF(.debug_info))
> 0x0000000000512bb2 __debug_info_end = .
>
> So the map shows that .debug_info is loaded at 0x44a908, but the error
> message says that LMA for .debug_info is 0x4440b8 - which is actually the
> LMA for .debug_frame, not .debug_info. As far as I can tell, the linker
> script does create separate LMAs for these two sections. Am I missing
> anything?
>
> I've tried with GIT master branch and it is reporting this error.
>
> Regards,
> Alexey.
>
> > > If you are really only concerned about the .debug_frame section, you
> > > should be looking instead at the .eh_frame section, which is loaded
> > > into memory, and uses a slightly different format. I don't know if it
> > > will provide everything you need, though.
> > >
> > > If you do need full debug info, then you'll have to tweak your DWARF
> > > reader to adjust by the base of the debug sections as appropriate.
> >
> > No, I've just started with .debug_frame, but I'll need other .debug_*
> > sections as well. They have the same issue, as far as I understand, so the
> > linker script above seems to be more general solution (than tweak all
> > specifications of "offset from the start of the section").
> >
> > Regards,
> > Alexey.
> >
> > > Ian