All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Cc: Jiri Olsa <olsajiri@gmail.com>,
	Eduard Zingerman <eddyz87@gmail.com>,
	dwarves@vger.kernel.org, arnaldo.melo@gmail.com,
	bpf@vger.kernel.org, kernel-team@fb.com, ast@kernel.org,
	daniel@iogearbox.net, andrii@kernel.org, yonghong.song@linux.dev,
	Alan Maguire <alan.maguire@oracle.com>, Daniel Xu <dxu@dxuuu.xyz>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>
Subject: Re: [PATCH dwarves v3 1/1] btf_encoder: handle .BTF_ids section endianness
Date: Wed, 27 Nov 2024 13:35:24 +0100	[thread overview]
Message-ID: <Z0cSDOtxLeqxbuzM@krava> (raw)
In-Reply-To: <6187706f-5c7f-4c22-9854-b3225b841385@linux.dev>

On Wed, Nov 27, 2024 at 12:03:59PM +0000, Vadim Fedorenko wrote:
> On 27/11/2024 11:00, Jiri Olsa wrote:
> > On Tue, Nov 26, 2024 at 05:50:06PM -0800, Eduard Zingerman wrote:
> > > btf_encoder__tag_kfuncs() reads .BTF_ids section to identify a set of
> > > kfuncs present in the ELF file being processed.
> > > This section consists of:
> > > - arrays of uint32_t elements;
> > > - arrays of records with the following structure:
> > >    struct btf_id_and_flag {
> > >        uint32_t id;
> > >        uint32_t flags;
> > >    };
> > > 
> > > When endianness of a binary operated by pahole differs from the host
> > > system's endianness, these fields require byte-swapping before use.
> > > Currently, this byte-swapping does not occur, resulting in kfuncs not
> > > being marked with declaration tags.
> > > 
> > > This commit resolves the issue by using elf_getdata_rawchunk()
> > > function to read .BTF_ids section data. When called with ELF_T_WORD as
> > > 'type' parameter it does necessary byte order conversion
> > > (only if host and elf endianness do not match).
> > > 
> > > Cc: Alan Maguire <alan.maguire@oracle.com>
> > > Cc: Andrii Nakryiko <andrii@kernel.org>
> > > Cc: Daniel Xu <dxu@dxuuu.xyz>
> > > Cc: Jiri Olsa <olsajiri@gmail.com>
> > > Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> > > Cc: Vadim Fedorenko <vadfed@meta.com>
> > > Fixes: 72e88f29c6f7 ("pahole: Inject kfunc decl tags into BTF")
> > > Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
> > > ---
> > >   btf_encoder.c | 26 ++++++++++++++++++++------
> > >   1 file changed, 20 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/btf_encoder.c b/btf_encoder.c
> > > index e1adddf..3754884 100644
> > > --- a/btf_encoder.c
> > > +++ b/btf_encoder.c
> > > @@ -1904,18 +1904,32 @@ static int btf_encoder__tag_kfuncs(struct btf_encoder *encoder)
> > >   			goto out;
> > >   		}
> > > -		data = elf_getdata(scn, 0);
> > > -		if (!data) {
> > > -			elf_error("Failed to get ELF section(%d) data", i);
> > > -			goto out;
> > > -		}
> > > -
> > >   		if (shdr.sh_type == SHT_SYMTAB) {
> > > +			data = elf_getdata(scn, 0);
> > > +			if (!data) {
> > > +				elf_error("Failed to get ELF section(%d) data", i);
> > > +				goto out;
> > > +			}
> > > +
> > >   			symbols_shndx = i;
> > >   			symscn = scn;
> > >   			symbols = data;
> > >   			strtabidx = shdr.sh_link;
> > >   		} else if (!strcmp(secname, BTF_IDS_SECTION)) {
> > > +			/* .BTF_ids section consists of uint32_t elements,
> > > +			 * and thus might need byte order conversion.
> > > +			 * However, it has type PROGBITS, hence elf_getdata()
> > > +			 * won't automatically do the conversion.
> > > +			 * Use elf_getdata_rawchunk() instead,
> > > +			 * ELF_T_WORD tells it to do the necessary conversion.
> > > +			 */
> > > +			data = elf_getdata_rawchunk(elf, shdr.sh_offset, shdr.sh_size, ELF_T_WORD);
> > 
> > looks good, I'm just curious about one thing..
> > 
> > so ELF_T_WORD enum has this comment: /* Elf32_Word, Elf64_Word, ... */
> > 
> > I did just quick check, ***so I might be easily wrong***, but I wonder the
> > code in __elf_xfctstom (which I assume is the one called for conversion)
> > chooses to swap 32/64 bits values based on elf->class .. so for 64bit ELF
> > class we swap 64bit values? ... while .BTF_ids has always 32 bit values
> 
> Well according to the doc:
> 
>        ELF_T_WORD     Unsigned 32-bit words.
>        ELF_T_XWORD    Unsigned 64-bit words.
> 
> It shouldn't use 64 bits swap:
> 
> const xfct_t __elf_xfctstom[EV_NUM - 1][EV_NUM - 1][ELFCLASSNUM -
> 1][ELF_T_NUM] =
> ....
> 	[ELF_T_WORD]	= ElfW2(Bits, cvt_Word),			
> 	[ELF_T_XWORD]	= ElfW2(Bits, cvt_Xword),			
> ...
> 
> Are you looking somewhere else?

nah I guess I got confused with Elf64_Word, which is still 32bits,
seems fine, sorry for noise 

Acked-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka

  reply	other threads:[~2024-11-27 12:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27  1:50 [PATCH dwarves v3 0/1] btf_encoder: handle .BTF_ids section endianness Eduard Zingerman
2024-11-27  1:50 ` [PATCH dwarves v3 1/1] " Eduard Zingerman
2024-11-27 11:00   ` Jiri Olsa
2024-11-27 12:03     ` Vadim Fedorenko
2024-11-27 12:35       ` Jiri Olsa [this message]
2024-11-27 17:53       ` Eduard Zingerman
2024-11-27 13:59   ` Vadim Fedorenko
2024-11-28 20:26     ` Arnaldo Carvalho de Melo
2024-11-28 21:14       ` Eduard Zingerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z0cSDOtxLeqxbuzM@krava \
    --to=olsajiri@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=arnaldo.melo@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dwarves@vger.kernel.org \
    --cc=dxu@dxuuu.xyz \
    --cc=eddyz87@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=memxor@gmail.com \
    --cc=vadim.fedorenko@linux.dev \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.