Re: BTF_TYPE_ID_LOCAL off by one?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2023-11-01 at 15:40 -0700, Andrii Nakryiko wrote:
> On Wed, Nov 1, 2023 at 2:27 AM Lorenz Bauer <lorenz.bauer@xxxxxxxxxxxxx> wrote:
> > 
> > On Tue, Oct 31, 2023 at 6:38 PM Andrii Nakryiko
> > <andrii.nakryiko@xxxxxxxxx> wrote:
> > > 
> > > I don't remember if this is intention or not, but the main part is
> > > adjusting CO-RE relocation, the actual instruction value is less
> > > important. But this is happening after static linking, because BTF is
> > > deduplicated (there is a duplication in BTF generated by Clang).
> > 
> > Ah I see! And the deduplication is done by libbpf during linking? So
> 
> yes
> 
> > far, we've been validating that the instruction immediate matches what
> > is in ext_infos. Should I just stop doing that?
> 
> probably, because I just checked libbpf's linker code, I don't think
> we adjust instructions that have CO-RE relocations. We might probably
> add that, but it's basically just BTF_TYPE_ID_LOCAL that would need
> this special handling. If someone sends the patch I'll accept it :)
> 
> > 
> > > There are at least two identical prototypes (which is strange and
> > > might be worth looking into from Clang side).
> > 
> > That would be good!
> 
> Agreed, maybe Yonghong or Eduard can take a look when they get time?

I'll take a look, probably on Sat/Sun.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux