Warning-free dlsym() - Unix

This is a discussion on Warning-free dlsym() - Unix ; On this page: http://www.opengroup.org/onlinepubs/...ons/dlsym.html It states: "... a future version may either add a new function to return function pointers, or the current interface may be deprecated in favor of two new functions: one that returns data pointers and the ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Warning-free dlsym()

  1. Warning-free dlsym()

    On this page:

    http://www.opengroup.org/onlinepubs/...ons/dlsym.html

    It states:

    "... a future version may either add a new function to return function
    pointers, or the current interface may be deprecated in favor of two
    new functions: one that returns data pointers and the other that
    returns function pointers."

    Does anybody know if a "future version" is in the works?

  2. Re: Warning-free dlsym()

    "jason.cipriani@gmail.com" writes:

    > On this page:
    >
    > http://www.opengroup.org/onlinepubs/...ons/dlsym.html
    >
    > It states:
    >
    > "... a future version may either add a new function to return function
    > pointers, or the current interface may be deprecated in favor of two
    > new functions: one that returns data pointers and the other that
    > returns function pointers."
    >
    > Does anybody know if a "future version" is in the works?


    I've never heard of one, nor can I see any practical need for one.
    Nobody makes a distinction between function pointers and data pointers
    these days. The C standard is written the way it is to allow
    implementations on old, obscure hardware that does have this
    distinction.

    --
    Måns Rullgård
    mans@mansr.com

  3. Re: Warning-free dlsym()

    Måns Rullgård wrote:
    > "jason.cipriani@gmail.com" writes:
    >
    >> On this page:
    >>
    >> http://www.opengroup.org/onlinepubs/...ons/dlsym.html
    >>
    >> It states:
    >>
    >> "... a future version may either add a new function to return function
    >> pointers, or the current interface may be deprecated in favor of two
    >> new functions: one that returns data pointers and the other that
    >> returns function pointers."
    >>
    >> Does anybody know if a "future version" is in the works?

    >
    > I've never heard of one, nor can I see any practical need for one.
    > Nobody makes a distinction between function pointers and data pointers
    > these days. The C standard is written the way it is to allow
    > implementations on old, obscure hardware that does have this
    > distinction.


    Actually, the C standard is written the way it is to allow
    implementations on new, cutting-edge, yet-to-be-invented hardware
    that makes this distinction. ;-)

    Or, "All that was old is new again." Computing is a fashion-
    driven industry, and fashions change. Remember the great big
    computer machine rooms of the prehistoric past, and how they
    were rendered completely obsolete by the personal computer?
    Think about that next time you tour Googazon or Amabay or eGle.

    --
    Eric Sosman
    esosman@ieee-dot-org.invalid

  4. Re: Warning-free dlsym()

    On Jun 4, 9:59 am, Måns Rullgård wrote:
    > "jason.cipri...@gmail.com" writes:
    > > On this page:


    > >http://www.opengroup.org/onlinepubs/...ons/dlsym.html


    > > It states:


    > > "... a future version may either add a new function to
    > > return function pointers, or the current interface may be
    > > deprecated in favor of two new functions: one that returns
    > > data pointers and the other that returns function pointers."


    > > Does anybody know if a "future version" is in the works?


    > I've never heard of one, nor can I see any practical need for
    > one. Nobody makes a distinction between function pointers and
    > data pointers these days.


    Except, of course, on an IA-32 architecture, where you might
    have 48 bit data pointers and 32 bit function pointers, or vice
    versa.

    > The C standard is written the way it is to allow
    > implementations on old, obscure hardware that does have this
    > distinction.


    I'm not sure I'd call IA-32 old nor obscure.

    --
    James Kanze (GABI Software) email:james.kanze@gmail.com
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

  5. Re: Warning-free dlsym()

    jason.cipriani@gmail.com wrote:

    > On this page:
    >
    > http://www.opengroup.org/onlinepubs/...ons/dlsym.html
    >
    > It states:
    >
    > "... a future version may either add a new function to return function
    > pointers, or the current interface may be deprecated in favor of two
    > new functions: one that returns data pointers and the other that
    > returns function pointers."
    >
    > Does anybody know if a "future version" is in the works?


    The "future version" is nearing completion (expected to be approved
    by IEEE in September).

    The problem with dlsym() and function pointers was solved by requiring
    implementations to support existing usage. In particular, this section
    was added in XSH:

    2.12.3 Pointer Types
    All function pointer types shall have the same representation
    as the type pointer to void. Conversion of a function pointer
    to void * shall not alter the representation. A void * value
    resulting from such a conversion can be converted back to the
    original function pointer type, using an explicit cast, without
    loss of information.

    --
    Geoff Clare

  6. Re: Warning-free dlsym()

    James Kanze wrote:
    > On Jun 4, 9:59 am, Måns Rullgård wrote:
    >> "jason.cipri...@gmail.com" writes:
    >> > On this page:

    >
    >> >http://www.opengroup.org/onlinepubs/...ons/dlsym.html

    >
    >> > It states:

    >
    >> > "... a future version may either add a new function to
    >> > return function pointers, or the current interface may be
    >> > deprecated in favor of two new functions: one that returns
    >> > data pointers and the other that returns function pointers."

    >
    >> > Does anybody know if a "future version" is in the works?

    >
    >> I've never heard of one, nor can I see any practical need for
    >> one. Nobody makes a distinction between function pointers and
    >> data pointers these days.

    >
    > Except, of course, on an IA-32 architecture, where you might
    > have 48 bit data pointers and 32 bit function pointers, or vice
    > versa.


    Are you sure that applies to the IA-32? I don't recall this for the
    IA-32. The x86-64 architecture has 48-bit addressing, but not the IA-32
    AFAIK. IA-32 last I checked has support for 32 bits for virtual address
    space, and 36 bits of total memory (with PAE).

    >> The C standard is written the way it is to allow
    >> implementations on old, obscure hardware that does have this
    >> distinction.

    >
    > I'm not sure I'd call IA-32 old nor obscure.


    The basic ALU instructions in the IA-32 are definitely an obscure old
    design, though they translate to something much more sophisticated
    internally.


    George

  7. Re: Warning-free dlsym()

    George Peter Staplin writes:

    > James Kanze wrote:
    >> On Jun 4, 9:59 am, Måns Rullgård wrote:
    >>> "jason.cipri...@gmail.com" writes:
    >>> > On this page:

    >>
    >>> >http://www.opengroup.org/onlinepubs/...ons/dlsym.html

    >>
    >>> > It states:

    >>
    >>> > "... a future version may either add a new function to
    >>> > return function pointers, or the current interface may be
    >>> > deprecated in favor of two new functions: one that returns
    >>> > data pointers and the other that returns function pointers."

    >>
    >>> > Does anybody know if a "future version" is in the works?

    >>
    >>> I've never heard of one, nor can I see any practical need for
    >>> one. Nobody makes a distinction between function pointers and
    >>> data pointers these days.

    >>
    >> Except, of course, on an IA-32 architecture, where you might
    >> have 48 bit data pointers and 32 bit function pointers, or vice
    >> versa.

    >
    > Are you sure that applies to the IA-32? I don't recall this for the
    > IA-32. The x86-64 architecture has 48-bit addressing, but not the IA-32
    > AFAIK. IA-32 last I checked has support for 32 bits for virtual address
    > space, and 36 bits of total memory (with PAE).


    The TLB on PAE-equipped IA-32 accepts physical addresses wider than 32
    bits (probably 36, if you say so). A normal instruction will never
    see one of these addresses, nor is there any way to directly address
    memory using one.

    Code and data pointers can be different for other reasons than size,
    too. It is conceivable to have a machine with separate physical
    address spaces for instructions and data, and the compiler would need
    to decide which types of instructions to generate when dereferencing
    these pointers.

    --
    Måns Rullgård
    mans@mansr.com

  8. Re: Warning-free dlsym()

    In article ,
    Måns Rullgård wrote:

    > Code and data pointers can be different for other reasons than size,
    > too. It is conceivable to have a machine with separate physical
    > address spaces for instructions and data, and the compiler would need
    > to decide which types of instructions to generate when dereferencing
    > these pointers.


    That's not a problem for users of dlsym(). If you're looking up a
    function, you'll never dereference it, you'll just use it in function
    calls, and the compiler can emit the appropraite instructions for access
    I-space. If it's a data pointer, you'll dereference it, and the
    compiler will generate D-space instructions.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  9. Re: Warning-free dlsym()

    Barry Margolin writes:

    > In article ,
    > Måns Rullgård wrote:
    >
    >> Code and data pointers can be different for other reasons than size,
    >> too. It is conceivable to have a machine with separate physical
    >> address spaces for instructions and data, and the compiler would need
    >> to decide which types of instructions to generate when dereferencing
    >> these pointers.

    >
    > That's not a problem for users of dlsym(). If you're looking up a
    > function, you'll never dereference it, you'll just use it in function
    > calls, and the compiler can emit the appropraite instructions for access
    > I-space. If it's a data pointer, you'll dereference it, and the
    > compiler will generate D-space instructions.


    What if I want to modify the code at run-time?

    --
    Måns Rullgård
    mans@mansr.com

  10. Re: Warning-free dlsym()

    On Jun 5, 4:57 pm, George Peter Staplin wrote:
    > James Kanze wrote:
    > > On Jun 4, 9:59 am, Måns Rullgård wrote:
    > >> "jason.cipri...@gmail.com" writes:
    > >> > On this page:


    > >> >http://www.opengroup.org/onlinepubs/...ons/dlsym.html


    > >> > It states:


    > >> > "... a future version may either add a new function to
    > >> > return function pointers, or the current interface may be
    > >> > deprecated in favor of two new functions: one that returns
    > >> > data pointers and the other that returns function pointers."


    > >> > Does anybody know if a "future version" is in the works?


    > >> I've never heard of one, nor can I see any practical need for
    > >> one. Nobody makes a distinction between function pointers and
    > >> data pointers these days.


    > > Except, of course, on an IA-32 architecture, where you might
    > > have 48 bit data pointers and 32 bit function pointers, or vice
    > > versa.


    > Are you sure that applies to the IA-32?


    Unless they've changed it since the 80386. I've definitely used
    48 bit data pointers on a 80386 (with 32 bit function pointers).
    And I can hardly imagine their removing something this basic.

    > I don't recall this for the IA-32. The x86-64 architecture
    > has 48-bit addressing, but not the IA-32 AFAIK. IA-32 last I
    > checked has support for 32 bits for virtual address space, and
    > 36 bits of total memory (with PAE).


    The IA-32 has 32 bit virtual address space for each segment.
    You have a 16 bit segment selector in there. (I rather doubt
    that it would really support 48 bits at the physical memory
    level, but you'd still have 48 bit pointers.)

    > >> The C standard is written the way it is to allow
    > >> implementations on old, obscure hardware that does have
    > >> this distinction.


    > > I'm not sure I'd call IA-32 old nor obscure.


    > The basic ALU instructions in the IA-32 are definitely an
    > obscure old design, though they translate to something much
    > more sophisticated internally.


    The architecture was already out of date when it appeared on the
    8086, almost 30 years ago. I meant old in the sense of "no
    longer being used or supported".

    --
    James Kanze (GABI Software) email:james.kanze@gmail.com
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

  11. Re: Warning-free dlsym()

    On Jun 6, 4:04 am, Barry Margolin wrote:
    > In article ,
    > Måns Rullgård wrote:


    > > Code and data pointers can be different for other reasons
    > > than size, too. It is conceivable to have a machine with
    > > separate physical address spaces for instructions and data,
    > > and the compiler would need to decide which types of
    > > instructions to generate when dereferencing these pointers.


    > That's not a problem for users of dlsym(). If you're looking
    > up a function, you'll never dereference it, you'll just use it
    > in function calls, and the compiler can emit the appropraite
    > instructions for access I-space. If it's a data pointer,
    > you'll dereference it, and the compiler will generate D-space
    > instructions.


    There's nothing to prevent you from having several different
    data segments, if you need to access more that 4 GB of RAM, or
    for other reasons. The problem is that if you conpile in model
    compact (for example), your data pointers will be 6 bytes wide,
    and your function pointers only 4 bytes.

    --
    James Kanze (GABI Software) email:james.kanze@gmail.com
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

  12. Re: Warning-free dlsym()

    In article ,
    Måns Rullgård wrote:

    > Barry Margolin writes:
    >
    > > In article ,
    > > Måns Rullgård wrote:
    > >
    > >> Code and data pointers can be different for other reasons than size,
    > >> too. It is conceivable to have a machine with separate physical
    > >> address spaces for instructions and data, and the compiler would need
    > >> to decide which types of instructions to generate when dereferencing
    > >> these pointers.

    > >
    > > That's not a problem for users of dlsym(). If you're looking up a
    > > function, you'll never dereference it, you'll just use it in function
    > > calls, and the compiler can emit the appropraite instructions for access
    > > I-space. If it's a data pointer, you'll dereference it, and the
    > > compiler will generate D-space instructions.

    >
    > What if I want to modify the code at run-time?


    You'll need to use system-dependent operations.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  13. Re: Warning-free dlsym()

    Barry Margolin writes:

    > In article ,
    > Måns Rullgård wrote:
    >
    >> Barry Margolin writes:
    >>
    >> > In article ,
    >> > Måns Rullgård wrote:
    >> >
    >> >> Code and data pointers can be different for other reasons than size,
    >> >> too. It is conceivable to have a machine with separate physical
    >> >> address spaces for instructions and data, and the compiler would need
    >> >> to decide which types of instructions to generate when dereferencing
    >> >> these pointers.
    >> >
    >> > That's not a problem for users of dlsym(). If you're looking up a
    >> > function, you'll never dereference it, you'll just use it in function
    >> > calls, and the compiler can emit the appropraite instructions for access
    >> > I-space. If it's a data pointer, you'll dereference it, and the
    >> > compiler will generate D-space instructions.

    >>
    >> What if I want to modify the code at run-time?

    >
    > You'll need to use system-dependent operations.


    System-specific stuff might be needed to flush I-caches and such, but
    nothing special should be required to find the address of a function.

    --
    Måns Rullgård
    mans@mansr.com

  14. Re: Warning-free dlsym()

    On Jun 7, 7:55 pm, Måns Rullgård wrote:
    > >> What if I want to modify the code at run-time?

    >
    > > You'll need to use system-dependent operations.

    >
    > System-specific stuff might be needed to flush I-caches and such, but
    > nothing special should be required to find the address of a function.


    Nothing special is required to *find* the address but you will need to
    rely on system-specific behavior to actually *interpret* that address,
    and to modify data at it. E.g. the following code is not guaranteed to
    work in C, or in C++, and there certainly exists hardware that it
    won't work on, but it is a hack that *might* work on very specific
    machines -- even though it's officially undefined:

    #include

    void function (void) {
    printf("function\n");
    }

    int main (int argc, char **argv) {
    unsigned char *code = (unsigned char *)&function;
    code[0] = 0x90;
    code[1] = 0xC3;
    return 0;
    }

    There's nothing portable, standard, or defined about that... in fact,
    that code actually crashes when compiled with MinGW GCC on an Intel
    T2600, causing an access violation when attempting to write to the
    area of memory it loads function() into.

    Jason

  15. Re: Warning-free dlsym()

    In article ,
    Måns Rullgård wrote:

    > Barry Margolin writes:
    >
    > > In article ,
    > > Måns Rullgård wrote:
    > >
    > >> Barry Margolin writes:
    > >>
    > >> > In article ,
    > >> > Måns Rullgård wrote:
    > >> >
    > >> >> Code and data pointers can be different for other reasons than size,
    > >> >> too. It is conceivable to have a machine with separate physical
    > >> >> address spaces for instructions and data, and the compiler would need
    > >> >> to decide which types of instructions to generate when dereferencing
    > >> >> these pointers.
    > >> >
    > >> > That's not a problem for users of dlsym(). If you're looking up a
    > >> > function, you'll never dereference it, you'll just use it in function
    > >> > calls, and the compiler can emit the appropraite instructions for access
    > >> > I-space. If it's a data pointer, you'll dereference it, and the
    > >> > compiler will generate D-space instructions.
    > >>
    > >> What if I want to modify the code at run-time?

    > >
    > > You'll need to use system-dependent operations.

    >
    > System-specific stuff might be needed to flush I-caches and such, but
    > nothing special should be required to find the address of a function.


    But if the function is in I-space, while the normal C indirection
    operators operate on D-space, you'd need a system-dependent way to
    modify I-space.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

+ Reply to Thread