Georg-Johann Lay writes:
> On 22.06.2016 19:06, Mike Stump wrote:
>> On Jun 22, 2016, at 7:21 AM, Georg-Johann Lay wrote:
>>>
>>> Some tests for PR71151 assume that the target MCU has a 3-byte PC. The
>>> tests are failing because the simulator (avrtest) rejects to load the
>>> respective executables if .text exceeds 128KiB, e.g. for -mmcu=atmega128
>>> which has only flash of 128KiB and only a 2-byte PC.
>>>
>>> Hence the tests have to be skipped if the target MCU has no 3-byte PC,
>>> hence a new dg-require-effective-target proc supporting "avr_3byte_pc".
>>>
>>> I added the new proc right after the last check_effective_target_arm_***
>>> so that the test is in ASCII collating order.
>>>
>>> Ok for trunk and v6?
>>
>> No. Please see target-utils.exp and ensure that the tools generate a
>> stylized message and then add support for that to target-utils.exp. If you
>> are using binutils, the text should go into a memory segment that will fill
>
> Binutils don't produce a message so there is nothing to scan for. Hacking
> binutils is beyond my scope.
binutils doesn't produce a message because
1. The size of text is not device specific right now - IIRC, it's set to
the max flash size for the emulation. I have a partial fix for this -
the text region size can now be set via a linker symbol
(__TEXT_REGION_LENGTH__). I'm planning to patch avr-libc to
automatically set this symbol based on flash size information
present in the device header file.
2. Even if (1) is fixed, the custom section (.foo) is not mapped to
any output section or region in the linker script. The linker can
error out only if the contents overflow a region.
If we have a custom linker script that places .foo in the text region,
and if we set the location counter to the address .foo should be placed,
i.e. something like
<snip>
.text :
{
...
*(.fini0) /* Infinite loop after program termination. */
KEEP (*(.fini0))
. = FOO_START;
KEEP(*(.foo))
_etext = . ;
} > text
and then if we pass -Wl,--defsym=FOO_START=0x20002 when linking, we'll get
the linker to report overflow.
Not sure if it's worth the effort though.
Mike, how about effective targets for sub arch/ISA variants
(avr51/avrxmega6/avrtiny..)? I guess arm has these for thumb1/thumb2/neon/dsp
etc. That would help us skip arch specific test cases, and will help
with testcases like these too - we can infer PC size from the arch.
Regards
Senthil
>
>> when it is too large. When it does, then binutils will generate one of the
>> messages already handled, then you're done.
>
> avrtest behaves just as if the program under test would call abort. There
> are
> at least 2 other AVR simulators; dunno how they would handle the situation.
>
> I don't see how an a-posteriori test could be independent of simulator,
> independent of board descriptions and all that stuff.
>
> The tests in question don't fail because the program is too big as a result
> of
> some mussed optimization; some code is deliberately placed across a 64KiB or
> 128KiB boundary or beyond 128KiB. All this is known a priori.
>
> Hence dropping the original patch and proposing a new one that doesn't need
> extensions to lib.
>
> The new tests just won't put any code at places where we know in advance some
> simulator might barf. As the compiler has no idea of exact flash size, the
> relevant flash property is deduced from ISA properties.
>
> Is this one ok?
>
> Johann
>
>
> gcc/testsuite/
> PR target/71151
> * gcc.target/avr/pr71151-common.h (foo): Use macro SECTION_NAME
> instead of ".foo" for its section name.
> * gcc.target/avr/pr71151-2.c (SECTION_NAME): Define appropriately
> depending on MCU's flash size.
> * gcc.target/avr/pr71151-3.c (SECTION_NAME): Dito.
> * gcc.target/avr/pr71151-4.c (SECTION_NAME): Dito.
> * gcc.target/avr/pr71151-5.c (SECTION_NAME): Dito.
> * gcc.target/avr/pr71151-6.c (SECTION_NAME): Dito.
> * gcc.target/avr/pr71151-7.c (SECTION_NAME): Dito.
> * gcc.target/avr/pr71151-8.c (SECTION_NAME): Dito.
