[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221229022622.khboqwfe23e7u2en@snowball.t-8ch.de>
Date: Thu, 29 Dec 2022 02:26:22 +0000
From: Thomas Weißschuh <thomas@...ch.de>
To: Rong Tao <rtoax@...mail.com>
Cc: linux@...ssschuh.net, jpoimboe@...nel.org,
linux-kernel@...r.kernel.org, peterz@...radead.org
Subject: Re: [PATCH v2 5/8] objtool: reduce memory usage of struct reloc
Hi Rong,
On Thu, Dec 29, 2022 at 09:33:32AM +0800, Rong Tao wrote:
> Is this likely to cause most RELOC failures? As shown in the following
> example:
>
> #include <bfd.h>
> #include <stdio.h>
>
> int main(void)
> {
> printf("%d\n", BFD_RELOC_S12Z_OPR);
> return 0;
> }
>
> The BFD_RELOC_S12Z_OPR equal to 2366.
I'm not familiar with libbfd, so please correct me if I'm wrong.
To me BFD_RELOC_S12Z_OPR looks like a value that is only used by libbfd.
objtool does not use libbfd.
The only values that objtools should see for the relocation types are
the R_* constants from elf.h as they are used by the compiler and linker
in the raw elf binary files.
These never exceed the value 255, one byte. Indeed they seem to have
been explicitly chosen like this.
$ grep 'define R_.*NUM' /usr/include/elf.h
#define R_68K_NUM 43
#define R_386_NUM 44
#define R_SPARC_NUM 253
#define R_MIPS_NUM 128
#define R_ALPHA_NUM 46
#define R_ARM_NUM 256
#define R_390_NUM 62
#define R_CRIS_NUM 20
#define R_X86_64_NUM 43
#define R_MN10300_NUM 35
#define R_M32R_NUM 256 /* Keep this the last entry. */
#define R_TILEPRO_NUM 130
#define R_TILEGX_NUM 130
#define R_RISCV_NUM 59
These _NUM constants are the highest actually used values, plus one.
So all real values are smaller than 256.
Thomas
Powered by blists - more mailing lists