Add gcc-ar, gcc-nm, gcc-ranlib

[Dave Korn]

On 03/12/2010 00:00, H.J. Lu wrote:
> On Thu, Dec 2, 2010 at 4:10 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 02/12/2010 23:31, H.J. Lu wrote:
>>> On Thu, Dec 2, 2010 at 3:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>>> On 02/12/2010 23:09, H.J. Lu wrote:
>>>>> On Thu, Dec 2, 2010 at 3:26 PM, Dave Korn wrote:
>>>>>> On 02/12/2010 22:35, H.J. Lu wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is the new implementation of gcc-ar, gcc-nm, gcc-ranlib.
>>>>>>> It doesn't require any new gcc option.  OK for trunk?
>>>>>>  The documentation isn't very detailed:
>>>>>>
>>>>>>> +In some cases, you may need to use the @command{gcc-ar},
>>>>>>> +@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
>>>>>>> +object files.
>>>>>>  Can it not say at least a little something about in what cases you may need
>>>>>> to use them, and what the difference is between them and the regular binutils?
>>>>>>
>>>>> Any improvements are more than welcome.
>>>>  I'd happily do so, but I don't know what they're for!
>>>>
>>> They are used to handle object files with IR:
>>  Ah, so the difference is just that they process the LTO symtab, rather than
>> the native object format symbols?
>>
> 
> Yes.  But I think gcc-ar and gcc-ranlib only work on IR-only object files,.

  'k.  So, how about something like:

In some cases, you may need to use the @command{gcc-ar},
@command{gcc-nm} and @command{gcc-ranlib} commands to manage LTO
object files.  These are POSIX-compliant shell scripts that operate
on the symbol tables contained in the GIMPLE bytecode, rather than
on the native format symbols that may be present in an object file.
@command{gcc-ar} and @command{gcc-ranlib} can only operate on object
files that contain solely GIMPLE bytecode and no native object code;
@command{gcc-nm} will simply ignore native object symbols.

    cheers,
      DaveK