On Tue, 2022-08-09 at 21:03 +0800, Lulu Cheng wrote: > > 在 2022/8/9 下午7:30, Xi Ruoyao 写道: > > > > > > Sorry for late reply, I'm rebuilding my entire Linux system (from > > scratch) for Glibc-2.36 and Binutils-2.39 update and I just reached the > > mail client. > > > > On Mon, 2022-08-08 at 12:53 +0800, Lulu Cheng wrote: > > > > > > > > > > > I still think it makes a little bit more sense to put attribute(model) > > > and -mcmodel together. > > > > > > -mcmodel sets the access range of all symbols in a single fileand > > > attribute (model) sets the > > > > > > accsess range of a single symbol in a file. For example > > > __attribute__((model(normal/large/extreme))). > > It might make sense, but then it would not be what we want for per-CPU > > symbols. What we want here is "treat a local symbol as-if it's global", > > while each code model may already treat local symbol and global symbol > > differently. > > > > Disambiguation: here "local" means "defined in this TU", "global" > > otherwise (not "local variable" in C). > > > > I'll send v6 with the name "addr_global" if no objection. > > > I am implementing the mode of cmodel=extreme. > In this mode, the value of the relative offset is a signed 64-bit value, > so this can solve the access problem of the variables of the kernel precpu. > So I wonder if it is necessary to add another attribute like addr_global?
If we use GOT I can implement only PC_HI20 and PC_LO12 relocs in kernel module loader. If we use extreme I'll need to implement 4 ABS relocations along with them. But "the less the better" is not a very strong reason anyway. -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
