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

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Section information of ADS generated assembly file


Hi Ketan,

Concerning gcc-assembly, you should look for (g)as documents. Indeed, gcc generates (g)as asm. The complete directive syntax is described in gas manual (get one at ftp://ftp.gnu.org/gnu/Manuals/gas).

Doing the adaptative job is not so difficult; you may nevertheless have to rewrite a few things.
When I spoke about automated things, I meant you could use a perl script to do the thing, putting all patterns and their replacement directives.


I also include the info armdev support gave me (thanks Ian!) about such conversion (I was originally trying to find a way to link between ADS and GNU). You may find that useful.

Hope that helps.

Regards,

Vincent

*****************************************************************
Vincent,

ARM Support Ref 246337

eabi v1 == ADS ABI  (old ATPCS document)
eabi v2 == RVCT ABI, the one that is documented on http://www.armdevzone.com/EABI/HomePage.html

Interworking between ARM and GNU tools is a very complex issue - basically the answer is that there are fundamental problems and it is not currently possible to link objects together directly.

Both ADS and gcc currently conform to the old eabi v1 (ATPCS) but I believe there is a EABI version numbering difference which causes the link to fail. The ARM tools use the EABI numbers but the GNU tools do not. There could well be other differences such as relocation types, so just fixing the object file header (or disabling the version number check in the GNU linker) would probably just lead to further problems. The ATPCS standard only covers register usage over a function call - which permits simple C function calls to work but there are many other issues (see below).

We are working to resolve these issues in future versions of the RealView and GNU tools, when both compilers are updated to support the new ARM EABI standard, but realistically this will not happen until 2004 at the earliest.

We know of success compiling small critical parts of an application using armcc (e.g. for performance reasons) and then including that code in the rest of the application built by some other toolchain such as GNU by either:

1) converting armcc -S output to GNU assembler format (the problem here is that the asm format is very different)

or

2) converting armcc object code back into assembler. In fact ARM has an internal tool written in perl which has done this for some of our multimedia codecs - this does the following:
- compiles using ADS/RealView
- uses ARM fromelf tool to disassemble the object file
- processes the disassembly into the correct asm format for the target toolchain.
- assembles the file using the target assembler


but this tool has various problems and is not available outside ARM.

Our multimedia codecs have converted quite easily, since they have a simple API and there are few complex data structures passed over the interface.

There are many issues with taking ARM compiler output and trying to use it with another tool chain. It might work for simple data processing type algorithms but for large amounts of source code there are sure to be problems. For instance:

- alignment issues
- structure packing must be the same for data structures
- run time support functions such as divide, floating point support, special versions of memcpy
- C++ will not be compatible due to differing vtable implementations
- C-library compatibility issues - which C-library to use?

It *is* possible but it is lots of work. You should try to minimize the amount of source code compiled with the "other" toolchain. Debugging could also be very time consuming as you will need to understand the low level differences between the two toolchains.


Regards


-- Ian

> >
> > Hello,
> >
> > Would you mind giving me more information about the differences
> between eabi v1 and 2? I
> > would also be glad to know where are the documents describing such an
> interface.
> >
> > I am in fact trying to link ADS 1.2 compiled object with gcc 3.2.3
> ones using ld. It
> > complains about the differences on the eabi version (says that one is
> version 0 (which,
> > after having looked at the source, is version "unknown") and other is
> version 2).
> >
> > Thank you very much,
> >
> > Vincent

---
Ian Rickards
Senior Product Specialist
ARM, 110 Fulbourn Road, Cambridge CB1 9NJ, UK
Tel: +44 1223 400462
ian.rickards@arm.com
===
This e-mail message is intended for the addressee(s) only and may contain
information that is the property of, and/or subject to a confidentiality
agreement between the intended recipient(s), their organisation and/or
the ARM Group of Companies. If you are not an intended recipient of this
e-mail message, you should not read, copy, forward or otherwise distribute
or further disclose the information in it; misuse of the contents of this
e-mail message may violate various laws in your state, country or
jurisdiction. If you have received this e-mail message in error, please
contact the originator of this e-mail message via e-mail and delete all
copies of this message from your computer or network, thank you.


------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


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