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

Jim, I didn’t understood why foo is not marked with type 'FUNC'.

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.

Regards,
Ashutosh

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Jim Grosbach
Sent: Friday, July 03, 2015 3:31 AM
To: Soumitra Chatterjee
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Request for help: why does the program link correctly?

Linking typically doesn’t pay attention to types, just to symbol names. The
symbol is indeed defined, so it links OK. This is one of the problems name
mangling helps solve in C++.

-Jim
> On Jul 1, 2015, at 10:09 PM, Soumitra Chatterjee <soumitra at hp.com>
wrote:
> 
> Hi,
> 	I am a bit stumped on the following case, and hopefully missing something
very basic. Can someone please help me understand why the following is allowed
to link correctly?
> 
> $ cat -n main.c
>     1  extern void foo();
>     2
>     3  int main() { foo(); }
> 
> $ cat -n def.c
>     1  int foo = 99;
> 
> $ clang main.c def.c ; echo $?
> 0
> 
> I guess the answer depends on why is 'main.c::foo' not marked as
func?
> 
> $ clang -c main.c def.c
> $ readelf -s main.o def.o | grep foo
>     9: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND foo
>     7: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    2 foo
> 
> Thanks,
> Soumitra
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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.

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.
>