On 08/01/18 12:31, Jeffrey Walton wrote:
> On Mon, Jan 8, 2018 at 6:26 AM, Christer Solskogen
> <christer.solskogen@xxxxxxxxx> wrote:
>> On 08.01.2018 11:33, Mason wrote:
>>
>>> Can you apply the following patch and report what was printed?
>>>
>> A oldpos=0 i=0 size=32 name=/home/alarm/amiberry-dev zipname=(null)
>> size=4096 seek=0
>> B oldpos=0 i=0 size=32 name=/home/alarm/amiberry-dev zipname=(null)
>> size=4096 seek=0
>> A oldpos=0 i=0 size=32 name=/home/alarm/amiberry-dev zipname=(null)
>> size=4096 seek=0
>> B oldpos=0 i=0 size=32 name=/home/alarm/amiberry-dev zipname=(null)
>> size=4096 seek=0
>> A oldpos=0 i=0 size=32 name=/home/alarm/amiberry-dev zipname=(null)
>> size=4096 seek=0
>> B oldpos=0 i=0 size=32 name=/home/alarm/amiberry-dev zipname=(null)
>> size=4096 seek=0
>>
>>
>> The thing is that the emulator "expects" kickstart rom files in kickstart/ -
>> if those files are present there's no segfault with Ofast. It only segfaults
>> if there are no kickstart rom files there.
>
> I noticed on OS X some miscompiles occurred if using -Ofast without
> -fno-common. Eventually we avoided -fno-common, and used
> __attribute__((section ("nocommon"))) on the variables producing the
> findings. We were catching Valgrind findings, not crashes though.
>
> Jeff
>
If you have got "common" symbols, you have problems in your code.
"common" symbols result from having more than one source file containing
definitions for the same external linkage identifier. That might be
just poor quality code (like having "int globalVar" in two files,
instead of defining it in one and using "extern int globalVar" in the
other) - or it might be a serious flaw (like having "int globalVar" in
one file and "double globalVar" in antoerh).
It is better to compile with -fno-common and /correct/ each finding by
identifying the multiple definitions, and using just one.
