Separate debug info in gold, ld and objcopy

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Separate debug info in gold, ld and objcopy

Vladimir Simonov-2
Hello Ian and others,

The main goal of gold is linking speedup. In real life
it is necessary(and suitable) to keep debug info separated
from executable. As I see, neither gold nor ld
do not provide possibility to write debug info into
separate file (and attach appropriate gnu_debulink
section to executable) during linking. Of course, this
may be implemented via objcopy but it slow downs linking.
Especially debug version of large C++ applications.

I see several solutions:
1. Implement possibility to write debug info into separate
file both in gold and in ld.
2. Implement possibility to write debug info into separate
file as some extension in gold.
3. Implement objcopy in gold sources tree (hope its
performance will also be much better with respect to
"classical" objcopy).

Do you have any plans in this direction?


Best regards
Vladimir Simonov

Reply | Threaded
Open this post in threaded view
|

Re: Separate debug info in gold, ld and objcopy

Ian Lance Taylor-3
Vladimir Simonov <[hidden email]> writes:

> The main goal of gold is linking speedup. In real life
> it is necessary(and suitable) to keep debug info separated
> from executable. As I see, neither gold nor ld
> do not provide possibility to write debug info into
> separate file (and attach appropriate gnu_debulink
> section to executable) during linking. Of course, this
> may be implemented via objcopy but it slow downs linking.
> Especially debug version of large C++ applications.
>
> I see several solutions:
> 1. Implement possibility to write debug info into separate
> file both in gold and in ld.
> 2. Implement possibility to write debug info into separate
> file as some extension in gold.
> 3. Implement objcopy in gold sources tree (hope its
> performance will also be much better with respect to
> "classical" objcopy).
>
> Do you have any plans in this direction?

I don't personally have any plans in this direction at present, but I
completely agree that these would be useful features to have.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: Separate debug info in gold, ld and objcopy

Dave Korn-6
Ian Lance Taylor wrote:
> Vladimir Simonov <[hidden email]> writes:

>> Do you have any plans in this direction?
>
> I don't personally have any plans in this direction at present, but I
> completely agree that these would be useful features to have.
>
> Ian

  I haven't even looked at gold yet.  I know it's ELF-centric, but is that
assumption actually embedded in the code, or would adding coff/pe just be a
simple matter of defining a new derived class for the output format?

    cheers,
      DaveK
Reply | Threaded
Open this post in threaded view
|

Re: Separate debug info in gold, ld and objcopy

David Miller-13
From: Dave Korn <[hidden email]>
Date: Tue, 14 Apr 2009 00:13:50 +0100

> Ian Lance Taylor wrote:
>> Vladimir Simonov <[hidden email]> writes:
>
>>> Do you have any plans in this direction?
>>
>> I don't personally have any plans in this direction at present, but I
>> completely agree that these would be useful features to have.
>>
>> Ian
>
>   I haven't even looked at gold yet.  I know it's ELF-centric, but is that
> assumption actually embedded in the code, or would adding coff/pe just be a
> simple matter of defining a new derived class for the output format?

"There is no expectation that gold will support anything other
 than ELF targets."

This is what Ian stated when he added gold to the binutils repo.
Reply | Threaded
Open this post in threaded view
|

Re: Separate debug info in gold, ld and objcopy

Ian Lance Taylor-3
David Miller <[hidden email]> writes:

> From: Dave Korn <[hidden email]>
> Date: Tue, 14 Apr 2009 00:13:50 +0100
>
>>   I haven't even looked at gold yet.  I know it's ELF-centric, but is that
>> assumption actually embedded in the code, or would adding coff/pe just be a
>> simple matter of defining a new derived class for the output format?
>
> "There is no expectation that gold will support anything other
>  than ELF targets."
>
> This is what Ian stated when he added gold to the binutils repo.

Right.  It's deeply embedded in the code.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: Separate debug info in gold, ld and objcopy

Dave Korn-6
In reply to this post by David Miller-13
David Miller wrote:

> From: Dave Korn <[hidden email]>
> Date: Tue, 14 Apr 2009 00:13:50 +0100
>
>> Ian Lance Taylor wrote:
>>> Vladimir Simonov <[hidden email]> writes:
>>>> Do you have any plans in this direction?
>>> I don't personally have any plans in this direction at present, but I
>>> completely agree that these would be useful features to have.
>>>
>>> Ian
>>   I haven't even looked at gold yet.  I know it's ELF-centric, but is that
>> assumption actually embedded in the code, or would adding coff/pe just be a
>> simple matter of defining a new derived class for the output format?
>
> "There is no expectation that gold will support anything other
>  than ELF targets."
>
> This is what Ian stated when he added gold to the binutils repo.

  Ohh, yeah, now you quote it at me I do remember that.  Doh.

    cheers,
      DaveK

Reply | Threaded
Open this post in threaded view
|

Re: Separate debug info in gold, ld and objcopy

Paul Brook
In reply to this post by Dave Korn-6
On Tuesday 14 April 2009, Dave Korn wrote:

> Ian Lance Taylor wrote:
> > Vladimir Simonov <[hidden email]> writes:
> >> Do you have any plans in this direction?
> >
> > I don't personally have any plans in this direction at present, but I
> > completely agree that these would be useful features to have.
> >
> > Ian
>
>   I haven't even looked at gold yet.  I know it's ELF-centric, but is that
> assumption actually embedded in the code, or would adding coff/pe just be a
> simple matter of defining a new derived class for the output format?

If you really want to support non-elf targets you might consider using a
postlinker approach, like the ARM EABI does for SymbianOS. i.e. your
toolchain is ELF based, then you run the final image through a postprocessor
to generate your actual target binaries (PE/bFLT/whatever).

http://www.arm.com/products/DevTools/ABI.html
The "Base Platform ABI" document contains some hints on how windows-like DLL
based systems can be encapsulated in an ELF toolchain.

Paul