This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Aix ld question.


Tom Rix <trix@redhat.com> writes:

[ CC'ed to binutils ]

> I am working on putting 64 bit support into ld for aix 4.3.3
> 
> Mostly I am curious about the note in the current binutils configure
> that says ld was broken for 4.2 and 4.3 because of import files.  I am
> about to re-animate ld so I was curious as to what was actually broken.  

I don't know about any problems with import files.  I know that AIX
4.2 added some new symbol types which GNU ld didn't handle at the
time, such as XMC_TD.  I believe some new section types were added as
well.  Support may have been added for some of them since then.  I
don't really know the current status.  I do see that some work has
been done on xcofflink.c since I left Cygnus.

When I worked on the XCOFF linker, it was essentially undocumented.
Each symbol type has its own special weird behaviour.  IBM introduces
new weird symbol types and behaviour with no notice.  So it's hard to
keep the linker updated for new AIX releases.  You have to notice
problems, and reverse engineer the behaviour of the native linker.
It's a mess.  The AIX linker engineers had some good ideas, and then
proceeded to implement them in a very idiosyncratic, ad hoc and
undocumented fashion.  It's almost like working with Microsoft object
files, except that the documentation is worse.

> One issue I am working on is all of the kernel symbols defined in
> /lib/syscalls.exp.  They appear to be generated by the native linker
> with n_values with the values from the import file.  The nasty bit is
> that the n_values can be outside of the addresses defined by the
> sections. This causes firing of all kinds of errors.  Do you know of a
> cleaner way than hacking together a hash table entry with a new flag
> that is checked everywhere to bypasses the error messages?  Is this
> something that could be handled with a linker script and a special
> section? I like this last idea.

That is how /lib/syscalls.exp has always worked.  In the old days,
this did not trigger any errors.  So something must have changed.
Perhaps the linker now checks for errors which it did not check for
previously.  What errors exactly do you get?

(This is going to sound patronizing and arrogant, but I feel compelled
to offer this advice: when discussing a computer program, never say
things like ``all kinds of errors.''  Instead, take 30 seconds to
generate the exact errors and cut and paste an example or two into the
e-mail.  Or, put in a one sentence explanation of why that is
difficult or impossible.  This is computer programming; precision
matters, and using it saves time.)

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]