Re: [avr-gcc-list] GCC Testing having problem with main returning - library/binutils problem -Help!

[Paulo Marques]

Quoting Andrew Hutchinson <address@hidden>:

> While running testsuite with gcc 4.3  I have found that some standard 
> tests expect a return from main()
> [...] while others explicitly call abort() or exit(0)
>
> The avr-gcc configuration I have built is creating a run-time JMP to 
> main() after c initialization  - on return it will thus crash with 
> stack underflow.
> [...]
> Could someone help solve this?

I've started looking into the testsuite too, to see what needs to be 
done in avrtest to use it as a simulator to run it (after all, this was 
the main purpose of developing it in the first place).

It seems to me that the current setup is overly complicated and that 
avrtest can in fact simplify a lot of the ugly stuff.

From the "run-avr" script:

# - This script first starts simulavr with the -d -g # - It then runs 
avr-gdb and attaches to simulavr using the target remote
#   protocol.
# - It then activates breakpoints at the functions exit() and abort()
# - In the next step the simulation is started with a time limit of
#   60 seconds.
# - If the simulation happens to stop within this time limit at one of the
#   two breakpoints (abort() or exit() ) the script outputs the strings
#   "EXIT" or "ABORTED" and the name of the avr-binary.
# - In case of a timeout it outputs "TIMEOUT".

This can all be simplified (in fact I don't think we need the run-avr 
script at all) using avrtest:

- we don't need breakpoints if we change "exit.c" so that the "abort()" 
and "exit()" functions write to a specific ioport that the simulator 
recognizes as exit or abort and performs the corresponding action. This 
is just a couple of lines in the "data_write_byte" function in the 
simulator, and a single line of code for each function in exit.c (I can 
do this patch if it helps).

- the timeout is already in place we just need to make it output 
"TIMEOUT" (and it can probably be a lot smaller, from the tests I've 
already seen)

- some of the ugliness in "exit.c" can be simplified:
  - we can implement an actual "putchar_exit_c" function similar to 
the demo program of avrtest, so that we actually get output from the 
test programs (if neccessary)
  - the "dummy_in_exit_c" can probably disappear as it is likely to be 
there just to allow a safe margin for breakpoints

The return from main is trickier, though. If we assume that the 
compiler will cntinue to do this in the future, we could trap the stack 
underflow and just call "exit" with the return code being the value 
currently in R24. That should result in the expected behavior for the 
testsuite.

This is ugly to say the least, though. If the code has an actual bug 
that results in a stack underflow and the R24 register just happens to 
have 0 in it, the testsuite will report a PASS, when it should FAIL.

Another possibilty is to assume that gcc only calls a RET for something 
that was placed on the stack by a CALL, and have the simulator keep 
track of the backtrace. This way we could fail when RET was called for 
something that was simply PUSH'ed onto the stack and just exit on that 
last return that causes the underflow. Not 100% safe, but still better 
than nothing.

It would be better to change the tests to never use return from main, 
though...

On an unrelated note, it should also be really easy to change avrtest 
to do at least dynamic stack usage analysis. It isn't as good as static 
analysis (that should measure the worst case), but it should allow us 
to find some regressions at least.

And we don't need to play tricks with "special markers" in RAM to find 
the stack usage. We can save the actual lowest address the stack has 
ever used in RAM directly.

Anyway, I'll keep trying to run the testsuite using avrtest (I've 
almost finished seting up all the prerequisites) and keep you posted of 
my progress so that we can help each other along the way.

--
Paulo Marques


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.