Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY

2021-08-11 Thread Richard Lowe
Ok yeah.  What seems to be happening is that we don't let you put a
mapping over the va hole (which I guess Oracle is smart about), and
obviously also don't let you put a mapping past userlimit.
So you'd need one segment that covers up as far as the va hole (which
is fine), and another bit that covers up from the end of the hole
until userlimit (which you can't do).  I'd guess Oracle did things
more thoroughly properly in their mapfile v2 changes.

Moving userlimit seems fine to me, I hope illumos does it (especially
if y'all already have).  We already (used to) set the limit that way
when running under xen.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY

2021-08-11 Thread Richard Lowe
the memsz there is waayyy too big.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY

2021-08-11 Thread s...@pandora.be


I just want to add that I think the current solution ,
with the  /etc/system.d/reserve_bits_for_tagged_pointers
is fine for me.

Also I am not knowledgeable at all about this issue (I have no experience with 
the link editor mapfiles).

Also the title subject line "RESERVE_SEGMENT or CAPABILITY" already indicates 
my misunderstanding, as it indicates a syntax that is NOT supported by OI if I 
understand correctly.

When I was looking at my current OpenSmalltalk cog-spur issue, I simply 
recalled the old discussion,
as it seems relevant, although perhaps not 100% the same issue, to my case.

There is an old blog at Oracle describing the "old AT&T link editor" mapfile 
syntax.

https://blogs.oracle.com/solaris/post/the-problems-with-solaris-svr4-link-editor-mapfiles

However the compiler tools used there are the Sun tools : cc and ld.

In the case of OI the GNU tools are used (gcc and perhaps /usr/gnu/bin/ld ?)

How exactly do you compile and link ?

You write "Linked with this mapfile" but how is this done , in the framework of 
oi-userland ?

Thanks,
David Stes

- Op 11 aug 2021 om 9:37 schreef oi-dev oi-dev@openindiana.org:

> Am 09.08.21 23:03 schrieb Richard Lowe :
> 
> 
> It's been so long I honestly don't remember right now, but it or V look right
> (ignoring the documentation, for now). You should be able to check it was
> created using elfdump -p
> 
> -- Rich
> 
> On Mon, Aug 9, 2021, 01:34 Carsten Grzemba via oi-dev < [
> mailto:oi-dev@openindiana.org | oi-dev@openindiana.org ] > wrote:
> 
> 
> 
> 
> Am 08.08.21 23:46 schrieb Richard Lowe < [ mailto:richl...@richlowe.net |
> richl...@richlowe.net ] >:
> 
> 
> We haven't added RESERVE_SEGMENT yet, though it would be fairly easy to do I
> think.
> You can do the same thing in the v1 syntax though, using the ?E flag to say 
> it's
> empty.
> 
> 
> 
> 
> I try to translate the mapfile version 2 to version 1
> version 2;
> 
> RESERVE_SEGMENT spidermonkey_reserve {
> VADDR = 0x8000;
> SIZE = 0x7fff;
> };
> 
> Is the following correct in version = 1?
> 
> spidermonkey_reserve = LOAD A0x8000 L0x7fff ?E;
> 
> 
> Linked with this mapfile I get with elfdump -p xpcshell:
> 
> 
> Program Header[0]:
> p_vaddr: 0x400040 p_flags: [ PF_X PF_R ]
> p_paddr: 0 p_type: [ PT_PHDR ]
> p_filesz: 0x1c0 p_memsz: 0x1c0
> p_offset: 0x40 p_align: 0
> 
> Program Header[1]:
> p_vaddr: 0x400200 p_flags: [ PF_R ]
> p_paddr: 0 p_type: [ PT_INTERP ]
> p_filesz: 0x17 p_memsz: 0x17
> p_offset: 0x200 p_align: 0
> 
> Program Header[2]:
> p_vaddr: 0x40 p_flags: [ PF_X PF_R ]
> p_paddr: 0 p_type: [ PT_LOAD ]
> p_filesz: 0x3f811 p_memsz: 0x3f811
> p_offset: 0 p_align: 0x1
> 
> Program Header[3]:
> p_vaddr: 0x44f820 p_flags: [ PF_W PF_R ]
> p_paddr: 0 p_type: [ PT_LOAD ]
> p_filesz: 0x8a8 p_memsz: 0xdf8
> p_offset: 0x3f820 p_align: 0x1
> 
> Program Header[4]:
> p_vaddr: 0x8000 p_flags: 0
> p_paddr: 0 p_type: [ PT_LOAD ]
> p_filesz: 0 p_memsz: 0x7fff
> p_offset: 0 p_align: 0x10
> 
> Program Header[5]:
> p_vaddr: 0x44fb10 p_flags: [ PF_W PF_R ]
> p_paddr: 0 p_type: [ PT_DYNAMIC ]
> p_filesz: 0x470 p_memsz: 0
> p_offset: 0x3fb10 p_align: 0
> 
> Program Header[6]:
> p_vaddr: 0x4500c8 p_flags: [ PF_W PF_R ]
> p_paddr: 0 p_type: [ PT_TLS ]
> p_filesz: 0 p_memsz: 0x8
> p_offset: 0x400c8 p_align: 0x8
> 
> Program Header[7]:
> p_vaddr: 0x400218 p_flags: [ PF_R ]
> p_paddr: 0 p_type: [ PT_SUNW_UNWIND ]
> p_filesz: 0xe4c p_memsz: 0xe4c
> p_offset: 0x218 p_align: 0x8
> 
> If I try to run:
> $ LD_LIBRARY_PATH=. ./xpcshell
> Killed
> 
> or
> $ LD_LIBRARY_PATH=. ldd ./xpcshell
> ldd: ./xpcshell: execution failed due to signal 9
> 
> So I guess to use LOAD for this is no good idea because OS thinks this space 
> is
> really to reserve instead of not to use?
> --
> Carsten
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Re: [oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY

2021-08-11 Thread Carsten Grzemba via oi-dev


Am 09.08.21 23:03 schrieb Richard Lowe  : 
> 
> 
> It's been so long I honestly don't remember right now, but it or V look right 
> (ignoring the documentation, for now). You should be able to check it was 
> created using elfdump -p
> 
> -- Rich
> 
> 
> 
> On Mon, Aug 9, 2021, 01:34 Carsten Grzemba via oi-dev 
>  wrote:
> 
> > 
> > 
> > Am 08.08.21 23:46 schrieb Richard Lowe  :
> > > 
> > > 
> > > We haven't added RESERVE_SEGMENT yet, though it would be fairly easy to 
> > > do I think.
> > > 
> > > You can do the same thing in the v1 syntax though, using the ?E flag to 
> > > say it's empty.
> > > 
> > > 
> > > 
> > > 
> > 
> > I try to translate the mapfile version 2 to version 1
> > version 2;
> > 
> > 
> > RESERVE_SEGMENT spidermonkey_reserve {
> >  VADDR = 0x8000;
> >  SIZE = 0x7fff;
> >  };
> > 
> > 
> > Is the following correct in version = 1?
> > 
> > spidermonkey_reserve = LOAD A0x8000 L0x7fff ?E;
> > 
> > 
> 
> 

 
Linked with this mapfile I get with elfdump -p xpcshell: 

 

Program Header[0]:
 p_vaddr: 0x400040 p_flags: [ PF_X PF_R ]
 p_paddr: 0 p_type: [ PT_PHDR ]
 p_filesz: 0x1c0 p_memsz: 0x1c0
 p_offset: 0x40 p_align: 0

Program Header[1]:
 p_vaddr: 0x400200 p_flags: [ PF_R ]
 p_paddr: 0 p_type: [ PT_INTERP ]
 p_filesz: 0x17 p_memsz: 0x17
 p_offset: 0x200 p_align: 0

Program Header[2]:
 p_vaddr: 0x40 p_flags: [ PF_X PF_R ]
 p_paddr: 0 p_type: [ PT_LOAD ]
 p_filesz: 0x3f811 p_memsz: 0x3f811
 p_offset: 0 p_align: 0x1

Program Header[3]:
 p_vaddr: 0x44f820 p_flags: [ PF_W PF_R ]
 p_paddr: 0 p_type: [ PT_LOAD ]
 p_filesz: 0x8a8 p_memsz: 0xdf8
 p_offset: 0x3f820 p_align: 0x1

Program Header[4]:
 p_vaddr: 0x8000 p_flags: 0
 p_paddr: 0 p_type: [ PT_LOAD ]
 p_filesz: 0 p_memsz: 0x7fff
 p_offset: 0 p_align: 0x10

Program Header[5]:
 p_vaddr: 0x44fb10 p_flags: [ PF_W PF_R ]
 p_paddr: 0 p_type: [ PT_DYNAMIC ]
 p_filesz: 0x470 p_memsz: 0
 p_offset: 0x3fb10 p_align: 0

Program Header[6]:
 p_vaddr: 0x4500c8 p_flags: [ PF_W PF_R ]
 p_paddr: 0 p_type: [ PT_TLS ]
 p_filesz: 0 p_memsz: 0x8
 p_offset: 0x400c8 p_align: 0x8

Program Header[7]:
 p_vaddr: 0x400218 p_flags: [ PF_R ]
 p_paddr: 0 p_type: [ PT_SUNW_UNWIND ]
 p_filesz: 0xe4c p_memsz: 0xe4c
 p_offset: 0x218 p_align: 0x8
 

 
If I try to run: 
$ LD_LIBRARY_PATH=. ./xpcshell 
Killed 

 
or
 
$ LD_LIBRARY_PATH=. ldd ./xpcshell 
ldd: ./xpcshell: execution failed due to signal 9 
 

 
So I guess to use LOAD for this is no good idea because OS thinks this space is 
really to reserve instead of not to use?
 
 
-- 
Carsten
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev