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 1
在 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 at
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 togeth
在 2022/8/5 下午5:53, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 15:58 +0800, Lulu Cheng wrote:
I think the model of precpu is not very easy to describe.
model(got)?model(global)?
I also want to use attribute model and -mcmodel together, but this is just an
initial idea,
what do you think?
It seems I
On Fri, 2022-08-05 at 15:58 +0800, Lulu Cheng wrote:
> I think the model of precpu is not very easy to describe.
> model(got)?model(global)?
> I also want to use attribute model and -mcmodel together, but this is just an
> initial idea,
> what do you think?
It seems I had some misunderstanding
在 2022/8/5 下午3:41, WANG Xuerui 写道:
On 2022/8/5 15:19, Lulu Cheng wrote:
在 2022/8/5 下午2:03, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
在 2022/8/5 上午11:45, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
Or maybe we should just us
On 2022/8/5 15:19, Lulu Cheng wrote:
在 2022/8/5 下午2:03, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
在 2022/8/5 上午11:45, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
Or maybe we should just use a PC-relative addressing with 4 inst
在 2022/8/5 下午2:03, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
在 2022/8/5 上午11:45, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
Or maybe we should just use a PC-relative addressing with 4 instructions
instead of GOT f
On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote:
>
> 在 2022/8/5 上午11:45, Xi Ruoyao 写道:
>
>
>
>
> > On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
> >
> >
> >
> >
> >
> > > Or maybe we should just use a PC-relative addressing with 4 instructions
> > > instead of
在 2022/8/5 上午11:45, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
Or maybe we should just use a PC-relative addressing with 4 instructions
instead of GOT for -fno-PIC?
Not possible, Glibc does not support R_LARCH_PCALA* relocations in
ld.so. So we still n
On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote:
> Or maybe we should just use a PC-relative addressing with 4 instructions
> instead of GOT for -fno-PIC?
Not possible, Glibc does not support R_LARCH_PCALA* relocations in
ld.so. So we still need a -mno-got (or something) optio
On Fri, 2022-08-05 at 10:51 +0800, Xi Ruoyao via Gcc-patches wrote:
> > If it is accessed through the GOT table, dynamic relocation is required
> > when the module is loaded.
>
> Dynamic relocation is required when the module is loaded anyway. The
> .ko modules are actually relocatable ELF obje
On Fri, 2022-08-05 at 10:38 +0800, Lulu Cheng wrote:
> > > I'm working on the implementation of specifing attributes of variables
> > > for other architectures.
> > > If the address is obtained through the GOT table and 4 instructions,
> > > there is not much difference in performance.
> > In th
在 2022/8/5 上午9:28, Xi Ruoyao 写道:
On Fri, 2022-08-05 at 09:05 +0800, Lulu Cheng wrote:
I'm working on the implementation of specifing attributes of variables for
other architectures.
If the address is obtained through the GOT table and 4 instructions, there is
not much difference in performan
On Fri, 2022-08-05 at 09:05 +0800, Lulu Cheng wrote:
> I'm working on the implementation of specifing attributes of variables for
> other architectures.
> If the address is obtained through the GOT table and 4 instructions, there is
> not much difference in performance.
In this case I still pref
I'm working on the implementation of specifing attributes of variables
for other architectures. If the address is obtained through the GOT
table and 4 instructions, there is not much difference in performance.
Is it more reasonable for us to refer to the implementation of the model
attribute un
On Wed, 2022-08-03 at 11:10 +0800, Xi Ruoyao via Gcc-patches wrote:
> > I'd like to wait for the kernel team to test the performance data of
> > the two implementations before deciding whether to support this
> > attribute.
> >
> > What do you think？
>
> Perhaps, I can't access my dev system now
On Wed, 2022-08-03 at 10:59 +0800, WANG Xuerui wrote:
> I don't think mindlessly caring for vendor forks is always correct. In
> fact I find the name "movable" too generic, and something like
> "force_got_access" could be better.
The problem is "what will this behave *if* we later add some code
On Wed, 2022-08-03 at 10:55 +0800, chengl...@loongson.cn wrote:
> I think there is no problem with this patch。But I have a question. The
> visibility attribute works, so is it necessary to add the moveable
> attribute?
1. My use of -fPIC and visibility is not in the way ELF visibility has
been des
On 2022/8/3 09:36, Xi Ruoyao wrote:
Is it OK for trunk or I need to change something?
By the way, I'm seeking a possibility to include this into 12.2. Then
we leaves only 12.1 without this attribute, and we can just say
"building the kernel needs GCC 12.2 or later".
On Mon, 2022-08-01 at 18:07
Is it OK for trunk or I need to change something?
By the way, I'm seeking a possibility to include this into 12.2. Then
we leaves only 12.1 without this attribute, and we can just say
"building the kernel needs GCC 12.2 or later".
On Mon, 2022-08-01 at 18:07 +0800, Xi Ruoyao wrote:
> Changes v4
Changes v4 -> v5: Fix changelog. No code change.
Changes v3 -> v4:
* Use "movable" as the attribute name as Huacai says it's already used
in downstream GCC fork.
* Remove an inaccurate line from the doc. (Initially I tried to
implement a "model(...)" like IA64 or M32R. Then I changed my
22 matches
Mail list logo
