> Date: Sat, 22 Oct 2022 11:21:17 +
> From: Klemens Nanni
>
> On Fri, Oct 21, 2022 at 10:55:57PM +0200, Mark Kettenis wrote:
> > Be careful. By moving more stuff into .rodata, you may overflow the
> > .text/.rodata block. Make sure you build and test the kernels and
> > also test an actual
On Fri, Oct 21, 2022 at 10:55:57PM +0200, Mark Kettenis wrote:
> Be careful. By moving more stuff into .rodata, you may overflow the
> .text/.rodata block. Make sure you build and test the kernels and
> also test an actual bsd.rd.
Yes, I keep testing bsd and bsd.rd/miniroot on amd64 and
Todd C. Miller wrote:
> On Fri, 21 Oct 2022 22:55:57 +0200, Mark Kettenis wrote:
>
> > Be careful. By moving more stuff into .rodata, you may overflow the
> > .text/.rodata block. Make sure you build and test the kernels and
> > also test an actual bsd.rd.
>
> Do we know exactly what these
On Fri, 21 Oct 2022 22:55:57 +0200, Mark Kettenis wrote:
> Be careful. By moving more stuff into .rodata, you may overflow the
> .text/.rodata block. Make sure you build and test the kernels and
> also test an actual bsd.rd.
Do we know exactly what these limits are? If so, couldn't we test
Mark Kettenis wrote:
> Be careful. By moving more stuff into .rodata, you may overflow the
> .text/.rodata block. Make sure you build and test the kernels and
> also test an actual bsd.rd.
Unless it fits, just barely, and then a commit three weeks later breaks it.
Or three months. Or two
> Date: Fri, 21 Oct 2022 20:02:48 +
> From: Klemens Nanni
>
> This is the second biggest read-write global in a sparc64 bsd.mp:
> 01c091b8 g O .data 2cb8 sparc_i
>
> ddb(4) does not ever write to it and happily decodes instructions after
> moving it to .rodata:
>
>
On Fri, Oct 21, 2022 at 11:29:32AM -0900, Philip Guenther wrote:
> On Fri, Oct 21, 2022 at 11:04 AM Klemens Nanni wrote:
>
> > --- a/sys/arch/sparc64/sparc64/db_disasm.c
> > +++ b/sys/arch/sparc64/sparc64/db_disasm.c
> >
> ...
>
> > @@ -877,7 +877,7 @@ struct sparc_insn sparc_i[] = {
> >
On Fri, Oct 21, 2022 at 11:04 AM Klemens Nanni wrote:
> --- a/sys/arch/sparc64/sparc64/db_disasm.c
> +++ b/sys/arch/sparc64/sparc64/db_disasm.c
>
...
> @@ -877,7 +877,7 @@ struct sparc_insn sparc_i[] = {
> vaddr_t
> db_disasm(vaddr_t loc, int altfmt)
> {
> - struct sparc_insn*
This is the second biggest read-write global in a sparc64 bsd.mp:
01c091b8 g O .data 2cb8 sparc_i
ddb(4) does not ever write to it and happily decodes instructions after
moving it to .rodata:
ddb{3}> x /i %pc
db_inst_branch+0x10:be,pn
