[PATCH] define SHT_LLVM_ADDRSIG section rather than error out

[Timm Bäder]

On 18/11/2020 06:34, Navin P via Elfutils-devel wrote:
>>> diff --git a/src/elflint.c b/src/elflint.c
>>> index ef3e3732..62663800 100644
>>> --- a/src/elflint.c
>>> +++ b/src/elflint.c
>>> @@ -3905,6 +3905,7 @@ section [%2zu] '%s': size not multiple of entry
>>> size\n"),
>>>      && shdr->sh_type != SHT_GNU_ATTRIBUTES
>>>      && shdr->sh_type != SHT_GNU_LIBLIST
>>>      && shdr->sh_type != SHT_CHECKSUM
>>> +   && shdr->sh_type != SHT_LLVM_ADDRSIG
>>>      && shdr->sh_type != SHT_GNU_verdef
>>>      && shdr->sh_type != SHT_GNU_verneed
>>>      && shdr->sh_type != SHT_GNU_versym
>>
>> Note that for various of these SHT_GNU extensions we actually do have
>> some extra checks. Do we need to check anything for a section marked
>> SHT_LLVM_ADDRSIG?
>>
> We can do two things here
> a) Recognize the section exists but ignore its contents which is what i
> do. This needn't be the correct approach.
> You may need to check the contents to sht_llvm_addrsig but that is
> lot of work after the format has been frozen.
> https://www.mail-archive.com/netdev@vger.kernel.org/msg348254.html
> readelf output
> [22] .llvm_addrsig     LOOS+0xfff4c03  0000000000000000 ...
> 
> b) If we don't want to recognize SHT_LLVM_ADDRSIG
> you can strip section from object file by objcopy -R .llvm_addrsig size.o
> conditionally  based on clang compiler.
> 

Hey Navin and Mark,

any update on this? I see that SHT_LLVM_ADDRSIG is still not in upstream
glibc. Are you working on that, Navin?

As for the checks, I'm not sure we can do anything here since elfutils
can't know whether a symbol is rightfully marked as address-significant.



Thanks,
Timm


-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric 
Shander