[oi-dev] mapfile and RESERVE_SEGMENT or CAPABILITY
stes@PANDORA.BE
stes at telenet.be
Wed Aug 11 18:08:39 UTC 2021
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 at openindiana.org:
> Am 09.08.21 23:03 schrieb Richard Lowe <richlowe at richlowe.net>:
>
>
> 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 at openindiana.org | oi-dev at openindiana.org ] > wrote:
>
>
>
>
> Am 08.08.21 23:46 schrieb Richard Lowe < [ mailto:richlowe at richlowe.net |
> richlowe at 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 = 0x800000000000;
> SIZE = 0xffff7fffffff0000;
> };
>
> Is the following correct in version = 1?
>
> spidermonkey_reserve = LOAD A0x800000000000 L0xffff7fffffff0000 ?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: 0x400000 p_flags: [ PF_X PF_R ]
> p_paddr: 0 p_type: [ PT_LOAD ]
> p_filesz: 0x3f811 p_memsz: 0x3f811
> p_offset: 0 p_align: 0x10000
>
> 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: 0x10000
>
> Program Header[4]:
> p_vaddr: 0x800000000000 p_flags: 0
> p_paddr: 0 p_type: [ PT_LOAD ]
> p_filesz: 0 p_memsz: 0xffff7fffffff0000
> p_offset: 0 p_align: 0x100000
>
> 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 at openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
More information about the oi-dev
mailing list