Indent and formatting of elfutils
Hi, I'm trying to compile elfutils with clang. I haven't written new code but moved code around. In this process source code formatting is lost when I moved couple of functions. Do you have any indent settings or clang-format or any auto settings ? Regards, Navin
Re: [PATCH 14/14] segment_report_module: Inline consider_phdr() into only caller
On Fri, Nov 13, 2020, 13:11 Timm Bäder wrote: > On 12/11/2020 17:52, Navin P wrote: > > Hi, > > I already have a patch that makes elfutils compile with clang. Since > > you are working > > this will be of use to you. I've attached the patch since it is big. > > > > Here are some of the changes > > 1. All functions at file scope have static qualifier so that no > > collison with other files. > > 2. Non global variables declared in the outer function should be > > passed as pointer variable > > in the new outer file scope function whenever they are assigned in > > the nested function. The > > argument addition in new functions are at the end. > > > > 3. With the applied patch above , gcc passes all 220 tests where > > clang fails 3 tests which > > is due to llvm_addrsig (change in libelf/elf.h ) and other 2 tests > > are error related to > > .rela.eh_frame. > > Thanks, Navin. Has this been proposed for inclusion in elfutils? What's > the status on that? Or are you just keeping this locally? > > Locally. It is not proposed for inclusion in elfutils but you can fix few things or compare/modify and include it. > Looking at the patch, I'm not really a fan of a few of those changes, > from a code point of view. consider_phdr() takes 35 arguments now > for example. > You have few options like collect them in a struct and pass a pointer to struct with those members as fields. Create static global variables but it is bound to collision within same file. Macros are not a good idea because if you have return in a nested func it returns to the outer func ,where as in macro it returns from the outer func. Once you have all the tests passing , you can refactor it. or you can fix it and make the tests pass. > > Do you have more information on the test failures? Are they caused by > LLVM/clang bugs? > Well i don't think they are compiler bugs but rather extra output from utilities is causing the diff to fail like elflint size.o . I think we are good from that perspective unless i missed something . With patch applied gcc passes all tests, clang fails 3 out of 220. > > > > Thanks, > Timm > >
Subject: [PATCH] Make elflint and libebl understand .rela.eh_frame like other section type
Hi, elflint doesn't recognize .rela.eh_frame like it does for other .rela sections. Signed-off-by: Navin P --- libebl/eblcheckreloctargettype.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libebl/eblcheckreloctargettype.c b/libebl/eblcheckreloctargettype.c index 068ad8f1..9d814d27 100644 --- a/libebl/eblcheckreloctargettype.c +++ b/libebl/eblcheckreloctargettype.c @@ -47,6 +47,7 @@ ebl_check_reloc_target_type (Ebl *ebl, Elf64_Word sh_type) case SHT_FINI_ARRAY: case SHT_PREINIT_ARRAY: case SHT_NOTE: + case SHT_X86_64_UNWIND: // required by .rela.eh_frame return true; default: -- 2.25.1
[PATCH] define SHT_LLVM_ADDRSIG section rather than error out
make elflint ignore it rather error as unsupported type. Other tools like readelf , objdump understand this section. Signed-off-by: Navin P --- libelf/elf.h | 1 + src/elflint.c | 1 + 2 files changed, 2 insertions(+) diff --git a/libelf/elf.h b/libelf/elf.h index 6439c1a4..26420b45 100644 --- a/libelf/elf.h +++ b/libelf/elf.h @@ -444,6 +444,7 @@ typedef struct #define SHT_SYMTAB_SHNDX 18 /* Extended section indeces */ #define SHT_NUM 19 /* Number of defined types. */ #define SHT_LOOS 0x6000 /* Start OS-specific. */ +#define SHT_LLVM_ADDRSIG 0x6FFF4C03/* llvm address sig */ #define SHT_GNU_ATTRIBUTES 0x6ff5 /* Object attributes. */ #define SHT_GNU_HASH 0x6ff6 /* GNU-style hash table. */ #define SHT_GNU_LIBLIST 0x6ff7 /* Prelink library list */ 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 -- 2.25.1
Re: Subject: [PATCH] Make elflint and libebl understand .rela.eh_frame like other section type
with clang compiler build, before applying this patch 3 tests were failing and after applying the patch all tests pass. your patch is much better as it fixes the backend. On Tue, Nov 17, 2020 at 7:44 PM Mark Wielaard wrote: > > Hi Navin, > > > On Fri, 2020-11-13 at 20:17 +0530, Navin P via Elfutils-devel wrote: > > elflint doesn't recognize .rela.eh_frame like it does for other > > .rela sections. > > Timm also noticed https://sourceware.org/bugzilla/show_bug.cgi?id=26878 > > I have an alternative patch that only recognizes SHT_X86_64_UNWIND for > x86_64, because it is an architecture specific section type. > > Does the attached work for you? > > Thanks, > > Mark
Re: [PATCH] define SHT_LLVM_ADDRSIG section rather than error out
On Tue, Nov 17, 2020 at 7:49 PM Mark Wielaard wrote: > > Hi Navin, > > On Fri, 2020-11-13 at 20:45 +0530, Navin P via Elfutils-devel wrote: > > make elflint ignore it rather error as unsupported type. Other tools > > like > > readelf , objdump understand this section. > > Is there a specification of this section type? > > diff --git a/libelf/elf.h b/libelf/elf.h > > index 6439c1a4..26420b45 100644 > > --- a/libelf/elf.h > > +++ b/libelf/elf.h > > @@ -444,6 +444,7 @@ typedef struct > > #define SHT_SYMTAB_SHNDX 18 /* Extended section indeces */ > > #define SHT_NUM 19 /* Number of defined types. */ > > #define SHT_LOOS 0x6000 /* Start OS-specific. */ > > +#define SHT_LLVM_ADDRSIG 0x6FFF4C03/* llvm address sig */ > > #define SHT_GNU_ATTRIBUTES 0x6ff5 /* Object attributes. */ > > #define SHT_GNU_HASH 0x6ff6 /* GNU-style hash table. */ > > #define SHT_GNU_LIBLIST 0x6ff7 /* Prelink library list */ > > elf.h comes from the glibc project. > We should first try to upstream new constants there > (glibc-al...@sourceware.org) > > > 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 ... 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.
Pending nested function removal
Hi, I tried to compile the nested functions and most of the files are complete. I find few others still pending. Below is the list which still has a nested function. I'm attaching the logfile for line numbers and column no. grep "function definition is not allowed here" logfile elf-from-memory.c:234:2: error: function definition is not allowed here elf-from-memory.c:314:2: error: function definition is not allowed here readelf.c:391:3: error: function definition is not allowed here readelf.c:3617:7: error: function definition is not allowed here readelf.c:6222:3: error: function definition is not allowed here readelf.c:8747:7: error: function definition is not allowed here readelf.c:12119:3: error: function definition is not allowed here strip.c:524:4: error: function definition is not allowed here strip.c:1540:8: error: function definition is not allowed here strip.c:2131:2: error: function definition is not allowed here strip.c:2159:6: error: function definition is not allowed here elflint.c:3450:3: error: function definition is not allowed here elflint.c:3463:3: error: function definition is not allowed here addr2line.c:697:4: error: function definition is not allowed here addr2line.c:704:4: error: function definition is not allowed here arlib-argp.c:63:3: error: function definition is not allowed here ar.c:449:3: error: function definition is not allowed here unstrip.c:443:5: error: function definition is not allowed here unstrip.c:1202:5: error: function definition is not allowed here unstrip.c:1453:5: error: function definition is not allowed here unstrip.c:2236:3: error: function definition is not allowed here unstrip.c:2496:5: error: function definition is not allowed here elfcompress.c:280:3: error: function definition is not allowed here elfcompress.c:285:3: error: function definition is not allowed here elfcompress.c:291:3: error: function definition is not allowed here elfcompress.c:299:3: error: function definition is not allowed here Regards, Navin logfile.gz Description: application/gzip
Re: Pending nested function removal
On Thu, Jan 28, 2021, 13:16 Timm Bäder wrote: > On 28/01/2021 06:19, Navin P via Elfutils-devel wrote: > > Hi, > > I tried to compile the nested functions and most of the files are > > complete. I find few others still pending. Below is the list which > > still has a nested function. > > I'm attaching the logfile for line numbers and column no. > > > > grep "function definition is not allowed here" logfile > > elf-from-memory.c:234:2: error: function definition is not allowed here > > elf-from-memory.c:314:2: error: function definition is not allowed here > > elf-from-memory: > https://sourceware.org/pipermail/elfutils-devel/2021q1/003373.html > > > readelf.c:391:3: error: function definition is not allowed here > > readelf.c:3617:7: error: function definition is not allowed here > > readelf.c:6222:3: error: function definition is not allowed here > > readelf.c:8747:7: error: function definition is not allowed here > > readelf.c:12119:3: error: function definition is not allowed here > > readelf: > https://sourceware.org/pipermail/elfutils-devel/2021q1/003381.html > > > strip.c:524:4: error: function definition is not allowed here > > strip.c:1540:8: error: function definition is not allowed here > > strip.c:2131:2: error: function definition is not allowed here > > strip.c:2159:6: error: function definition is not allowed here > > strip: > https://sourceware.org/pipermail/elfutils-devel/2021q1/003368.html > > > > elflint.c:3450:3: error: function definition is not allowed here > > elflint.c:3463:3: error: function definition is not allowed here > > addr2line.c:697:4: error: function definition is not allowed here > > addr2line.c:704:4: error: function definition is not allowed here > > arlib-argp.c:63:3: error: function definition is not allowed here > > ar.c:449:3: error: function definition is not allowed here > > addr2line, arlib-argp, ar, zstrptr: > https://sourceware.org/pipermail/elfutils-devel/2021q1/003376.html > > > unstrip.c:443:5: error: function definition is not allowed here > > unstrip.c:1202:5: error: function definition is not allowed here > > unstrip.c:1453:5: error: function definition is not allowed here > > unstrip.c:2236:3: error: function definition is not allowed here > > unstrip.c:2496:5: error: function definition is not allowed here > > elfcompress.c:280:3: error: function definition is not allowed here > > elfcompress.c:285:3: error: function definition is not allowed here > > elfcompress.c:291:3: error: function definition is not allowed here > > elfcompress.c:299:3: error: function definition is not allowed here > > I have the others locally but wanted feedback on the patches I posted > first. Maybe I should re-post them with the changelog entries > I forgot :) > Yes, please merge them.The already committed ones are good. Please update when you are done >
Re: [PATCH] define SHT_LLVM_ADDRSIG section rather than error out
On Thu, Mar 4, 2021 at 7:14 PM Timm Bäder wrote:
>
> 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 ...
> >
> > 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.
>
clang has a flag -fno-addrsig that doesn't generate the addrsig section.
https://releases.llvm.org/7.0.0/tools/clang/docs/ClangCommandLineReference.html#cmdoption-clang-faddrsig
So adding that for option for only clang should work. I remember I
ran the tests and it worked. But you should check again.
As far as i remember this should complete the changes
Here is a small example
navin@mint-Aspire:~/c$ cat tmp.c
int main() { return 0 ; }
navin@mint-Aspire:~/c$ clang tmp.c -c
navin@mint-Aspire:~/c$ readelf -a tmp.o | grep -i addrsig
[ 7] .llvm_addrsig LOOS+0xfff4c03 0120
navin@mint-Aspire:~/c$ clang tmp.c -c -fno-addrsig
navin@mint-Aspire:~/c$ readelf -a tmp.o | grep -i addrsig
navin@mint-Aspire:~/c$
linker to be used for elfutils
Hi, I wanted to check if other linkers gold,lld are supported by elfutils. i have the following compilers and linkers a) gcc + ld.bfd all tests pass b) clang + ld.bfdall tests pass c) gcc + gold few tests fail d) clang + gold Still not tried e) gcc + lldStill not tried f) clang + lld few tests fail Before evening getting into the tests and trying to fix it i would like to know if all of these are supported ? For example gcc + gold fails due to zero sized AMS section in .rodata for elfstrmerge executable. Also we run elflint with --gnu-ld option for the tests. Will it run with --gnu-ld for lld and good ? Regards, Navin
