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 Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>
> > > To: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
> > > 
> > > > 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





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux