Why is a hacked unwind-ia64.h/c part of binutils?

Why is a hacked unwind-ia64.h/c part of binutils?

[Paul Schlie]

Although I understand these files historically contain some generic unwind
definitions, would there be opposition to accepting a patch to arguably
more properly peel the generic portions out, and correspondingly enable
the specification of target specific unwind type sizes which may be more
appropriate for smaller targets, as opposed to presuming they need be
defined by the ia64's native word type sizes?

(and correspondingly enabled for GCC target ports as well)

Re: Why is a hacked unwind-ia64.h/c part of binutils?

[James E Wilson]

On Thu, 2005-03-17 at 11:59, Paul Schlie wrote:
> Although I understand these files historically contain some generic unwind
> definitions, would there be opposition to accepting a patch to arguably
> more properly peel the generic portions out, and correspondingly enable
> the specification of target specific unwind type sizes which may be more
> appropriate for smaller targets, as opposed to presuming they need be
> defined by the ia64's native word type sizes?

This seems rather confused to me.

You didn't explain what you meant by "hacked unwind-ia64.c/h".  Hacked
how?  Hacked from what?  The files incidentally are in no way hacked. 
They are copies of files that also appear in the linux kernel.

It is easy to explain why the files are there.  They are needed for the
readelf support for dumping IA-64 unwind info.  It even says so in the
first line of the file.  Did you try looking at the files?

These files are very IA-64 specific.  Asking for changes for other
targets makes no sense.  There are no other targets that use IA-64
unwind info, nor will there ever probably be any.

I think you confusing the general GCC unwind support with the GCC IA-64
specific unwind support.  Most gcc targets use the dwarf2 unwind
support.  Only IA-64 uses the IA-64 unwind support.  These are rather
different things, though the dwarf2 unwind support is based on many of
the concepts developed for the IA-64 unwind support, the object file
encodings are completely different.

As for the type sizes, these are defined by the C++ ABI, which in turn
is based on the Itanium unwind ABI, which specifies use of 64-bit
types.  It would certainly be wrong to change this for IA-64, and it is
arguably wrong for any other target without justification.

I know that you have a modified AVR port which sets long long to a
32-bit type, but you failed to mention that as your justification. 
While changes to the generic unwind support might be reasonable because
of this, changes to the IA-64 port are not.

Looking at the unwind-ia64.[ch] files, the only thing target independent
I see in there is the unw_decode_leb128 function, and there is already
an equivalent generic function read_leb128 in readelf.c.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Why is a hacked unwind-ia64.h/c part of binutils?

[Paul Schlie]

> From: James E Wilson <wilson@specifixinc.com>
>> On Thu, 2005-03-17 at 11:59, Paul Schlie wrote:
>> Although I understand these files historically contain some generic unwind
>> definitions, would there be opposition to accepting a patch to arguably
>> more properly peel the generic portions out, and correspondingly enable
>> the specification of target specific unwind type sizes which may be more
>> appropriate for smaller targets, as opposed to presuming they need be
>> defined by the ia64's native word type sizes?
> 
> This seems rather confused to me. ...

- it was, I jumped to the wrong conclusion.

> I think you confusing the general GCC unwind support with the GCC IA-64
> specific unwind support.  Most gcc targets use the dwarf2 unwind
> support.  Only IA-64 uses the IA-64 unwind support.  These are rather
> different things, though the dwarf2 unwind support is based on many of
> the concepts developed for the IA-64 unwind support, the object file
> encodings are completely different.

- yes, thank for straightening me out.

> As for the type sizes, these are defined by the C++ ABI, which in turn
> is based on the Itanium unwind ABI, which specifies use of 64-bit
> types.  It would certainly be wrong to change this for IA-64, and it is
> arguably wrong for any other target without justification.
>
> I know that you have a modified AVR port which sets long long to a
> 32-bit type, but you failed to mention that as your justification.
> While changes to the generic unwind support might be reasonable because
> of this, changes to the IA-64 port are not.

- understood, and apologize for my half baked earlier misguided question.

> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com