make check for h8300-elf - unresolving test cases

["D.Venkatasubramanian, Noida" <dvenkat at noida dot hcltech dot com>]

Hi,

I built a h8300-elf cross compiler with the following specs on a x86 system
with RedHat Linux 7.3.
 
[venkat@peacock bugfix]$ h8300-elf-gcc -v
Reading specs from
/home/venkat/gcc_release/h8300-elf/tools/bin/../lib/gcc-lib/h8300-elf/3.1.1/
specs
Configured with: /export/niting/WorkArea/gcc-release/src/configure
--target=h8300-elf --enable-languages=c,c++
--prefix=/home/venkat/gcc_release/h8300-elf/tools/ --with-newlib
--with-gnu-ld --with-gnu-as
Thread model: single
gcc version 3.1.1

On running make check on the compiler, I found compilation errors with all
test cases being compiled with -fprofile-arcs option.

With a minimal test case test.c, the error message I got.

[venkat@peacock experiment]$ h8300-elf-gcc -mh -fprofile-arcs test.c
/tmp/ccFTbg93.o: In function `__GLOBAL__I_mainGCOV':
/tmp/ccFTbg93.o(.text+0x53): undefined reference to `___bb_init_func'
collect2: ld returned 1 exit status

The problem seems that while building with newlib, some function definitions
are not present due to inhibitlibc in libgcc2.c

And as _INHIBITLIBC is passed during compilation, these functions are
absent, and hence, the linker gives an error.

Remedy : As this behaviour may be expected, we should actually modify the
test suite, and put test cases which compile with -fprofile-arcs in the
unresolved category (when the compiler is built using newlib), so that they
don't fail.

Do you think I am thinking on the correct lines?

Any help will be highly appreciated.

Thanx and Regards,

Venky




_______________________________________________________


I find that a great part of the information I have was acquired by looking
up something and finding something else on the way. 
Franklin P. Adams 



-----Original Message-----
From: Richard Earnshaw [mailto:rearnsha@cambridge.arm.com]
Sent: Tuesday, September 10, 2002 2:54 PM
To: Andreas Bauer
Cc: Richard Henderson; gcc@gcc.gnu.org; pizka@in.tum.de;
jason.ozolins@anu.edu.au; Richard.Earnshaw@arm.com
Subject: Re: Work in progress: "Super Sib Calls"; opinions sought 



> So, maybe it would be more appropriate redesigning the sibcall stuff and
> simply add my argument marshalling mechanism to it, but I do not see how
> I could possibly address indirect calls without making ARM maintainers
> (and others) unhappy.

As long as it doesn't mean that we loose the existing level of tail-call 
support I doubt there will be any complaint.  As for ARM code, I've 
already pointed out that I think we can use IP in the majority of 
circumstances (though untill I see details I can't be sure of that; for 
Thumb code, tail-calling is pretty close to impossible anyway for anything 
except the most basic of cases.

R.