llvm dev - Jul 2015 - [LLVMdev] Request for help: why does the program link correctly?

Someone in my team pointed to an open bug about this in gcc:
	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514

Would this be applicable to Clang as well?

Thanks,
Soumitra

On 03-Jul-2015 10:53 AM, Tim Northover wrote:
> On 2 July 2015 at 21:51, Nema, Ashutosh <Ashutosh.Nema at amd.com>
wrote:
>> Jim, I didn’t understood why foo is not marked with type
'FUNC'.
>
> Just convention, as far as I can tell (certainly GNU as does the same
> thing for undefined symbols).
>
> The ARM ELF ABI says that either STT_NOTYPE or STT_FUNC would be
> acceptable on that platform, the x86_64 ABI seems to be silent on the
> issue.
>
>> At least as per elf standard symbol foo should be marked as
'FUNC'
>> STT_FUNC:    The symbol is associated with a function or other
executable code.
>
> For whatever reason, that's only taken to be necessary for defined
> symbols in reality (you could argue that wording only says "STT_FUNC
> => function symbol", not "function symbol =>
STT_FUNC").
>
> Cheers.
>
> Tim.
>

On 2 July 2015 at 23:32, Soumitra Chatterjee <soumitra at hp.com>
wrote:
> Someone in my team pointed to an open bug about this in gcc:
>         https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514
>
> Would this be applicable to Clang as well?
It's probably open for change. We'd have to work out who (if anyone)
was relying on the current behaviour and someone would have to be
motivated enough to write the patch.

Incidentally, what linker are you using? Neither ld.bfd nor ld.gold
actually seem to diagnose this if there *is* a mismatch. So changing
it wouldn't seem to improve matters much.

Cheers.

Tim.

On Friday 03 July 2015 08:27 PM, Tim Northover wrote:
> On 2 July 2015 at 23:32, Soumitra Chatterjee <soumitra at hp.com>
wrote:
>> Someone in my team pointed to an open bug about this in gcc:
>>          https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514
>>
>> Would this be applicable to Clang as well?
>
> It's probably open for change. We'd have to work out who (if
anyone)
> was relying on the current behaviour
And if we can not find who is that, at least we can introduce a new 
option to make warnings/diagnostic stricter? It would not break 
compatibility.
> and someone would have to be
> motivated enough to write the patch.
There are enough existing LLVM enthusiasts I would say (including me) 
:-) And then zillions are joining the bandwagon.
>
> Incidentally, what linker are you using?
ELF linkers on SVR4 compliant Unix like HP-UX and Solaris do diagnose 
and warn.

--
Supra