From: Mark Wielaard <mark@klomp.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
Brian Cain <bcain@quicinc.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
Yujie Liu <yujie.liu@intel.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
kernel test robot <lkp@intel.com>,
"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
"oe-kbuild-all@lists.linux.dev" <oe-kbuild-all@lists.linux.dev>,
"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
"dwarves@vger.kernel.org" <dwarves@vger.kernel.org>,
Sid Manning <sidneym@quicinc.com>
Subject: Re: [bcachefs:header_cleanup 21/51] /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eep...
Date: Fri, 09 Feb 2024 14:34:39 +0100 [thread overview]
Message-ID: <6498586d7d0ed112e6c44be98d439abc549653c7.camel@klomp.org> (raw)
In-Reply-To: <ZZXHTawRETL4XNmc@kernel.org>
Hi,
On Wed, 2024-01-03 at 17:45 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 03, 2024 at 05:25:11PM +0000, Brian Cain escreveu:
> > > From: Mark Wielaard <mark@klomp.org>
> > > To: Arnaldo Carvalho de Melo <acme@kernel.org>
> > >
> > > > Mark, do you know about work on elfutils to support:
>
> > > > ⬢[acme@toolbox hexagon-randconfig-r005-20220913-pahole-crash]$ llvm-
> > > dwarfdump at24.ko | head -22
> > > > at24.ko: file format elf32-hexagon
>
> > > That seems to identify itself as an EM_QDSP6 (QUALCOMM DSP6) 32bit ELF
> > > file. Neither binutils not elfutils seems to know how to resolve
> > > EM_QDSP6 specific relocations. Normally that wouldn't be necessary,
> > > but sadly kernel modules are still ET_REL files, so eu-readelf/readelf
> > > needs relocations resolved to process the DWARF .debug sections.
>
> > > This seems to need Qualcomm to upstream support for this processor
> > > type to bintuils and elfutils.
>
> > We can take a look at this. But - please forgive my inexperience here
> > -- do the corresponding tools such as llvm-readelf not suffice here?
> > Would it be welcome for us to change pahole to support those if it
> > doesn't already?
>
> pahole uses the DWARF library that comes with elfutils, so the changes
> that were made to the DWARF library used by llvm-readelf would have to
> be done to elfutils' DWARF library for pahole to be able to process
> these files.
>
> IANAL to say if you can copy code across these these codebases.
Literally copying code over between those codebases is probably not
going to work anyway. But it shouldn't be too hard to get just the
support for handling ET_REL kernel modules in elfutils.
Basically you'll have to add a new backend and at least implement the
reloc_simple_type callback (this is the one that tells elfutils which
relocations are "simple" and how they can be resolved between .debug
sections). An example to follow might be the initial LoongArch backend
support:
https://sourceware.org/cgit/elfutils/commit?id=13a4d1279c5b7847049ca3045d04f2705c45ce31
This one is just ~200 lines long, and the reloc_simple_types callback
is bigger than most, often arches have just really simple relocations
without any need for add/sub support. e.g the aarch backend simply has
support for 16, 32 and 64 offsets without any additional addsub addend:
/* Check for the simple reloc types. */
Elf_Type
aarch64_reloc_simple_type (Ebl *ebl __attribute__ ((unused)), int type,
int *addsub __attribute__ ((unused)))
{
switch (type)
{
case R_AARCH64_ABS64:
return ELF_T_XWORD;
case R_AARCH64_ABS32:
return ELF_T_WORD;
case R_AARCH64_ABS16:
return ELF_T_HALF;
default:
return ELF_T_NUM;
}
}
The only relocations that are really relevant here are those that are
used for the .debug sections.
Then follow the CONTRIBUTING guide to submit the new (partial) port:
https://sourceware.org/cgit/elfutils/tree/CONTRIBUTING
Cheers,
Mark
prev parent reply other threads:[~2024-02-09 13:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202312192107.wMIKiZWw-lkp@intel.com>
2023-12-19 20:53 ` [bcachefs:header_cleanup 21/51] /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eeprom/at24.ko Kent Overstreet
2023-12-19 20:58 ` Nick Desaulniers
2023-12-19 21:04 ` Kent Overstreet
2023-12-19 21:04 ` Nathan Chancellor
2023-12-19 21:12 ` [bcachefs:header_cleanup 21/51] /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eep Brian Cain
2023-12-20 7:24 ` [bcachefs:header_cleanup 21/51] /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eeprom/at24.ko Yujie Liu
2023-12-27 22:43 ` Nathan Chancellor
2023-12-28 14:21 ` Arnaldo Carvalho de Melo
2023-12-28 17:34 ` Nathan Chancellor
2024-01-02 16:30 ` Arnaldo Carvalho de Melo
2024-01-02 17:53 ` Mark Wielaard
2024-01-03 16:20 ` Nick Desaulniers
2024-01-03 22:03 ` Kent Overstreet
2024-01-03 23:55 ` Nathan Chancellor
2024-01-04 15:10 ` [bcachefs:header_cleanup 21/51] /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eep Brian Cain
2024-01-03 17:25 ` Brian Cain
2024-01-03 20:45 ` Arnaldo Carvalho de Melo
2024-02-09 13:34 ` Mark Wielaard [this message]
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=6498586d7d0ed112e6c44be98d439abc549653c7.camel@klomp.org \
--to=mark@klomp.org \
--cc=acme@kernel.org \
--cc=bcain@quicinc.com \
--cc=dwarves@vger.kernel.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-hexagon@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=sidneym@quicinc.com \
--cc=yujie.liu@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).