* Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c @ 2018-05-21 4:32 Remus Clearwater 2018-05-21 11:39 ` Godmar Back 2018-05-22 11:21 ` Florian Weimer 0 siblings, 2 replies; 7+ messages in thread From: Remus Clearwater @ 2018-05-21 4:32 UTC (permalink / raw) To: libc-help https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/makecontext.c;h=0d0802bf431326f7fcfe03d49df0c8ee7f4fdaab;hb=HEAD#l71 51 void 52 __makecontext (ucontext_t *ucp, void (*func) (void), int argc, ...) 53 { 54 extern void __start_context (void) attribute_hidden; 55 greg_t *sp; 56 unsigned int idx_uc_link; 57 va_list ap; 58 int i; 59 60 /* Generate room on stack for parameter if needed and uc_link. */ 61 sp = (greg_t *) ((uintptr_t) ucp->uc_stack.ss_sp 62 + ucp->uc_stack.ss_size); 63 sp -= (argc > 6 ? argc - 6 : 0) + 1; 64 /* Align stack and make space for trampoline address. */ 65 sp = (greg_t *) ((((uintptr_t) sp) & -16L) - 8); 66 67 idx_uc_link = (argc > 6 ? argc - 6 : 0) + 1; 68 69 /* Setup context ucp. */ 70 /* Address to jump to. */ 71 ucp->uc_mcontext.gregs[REG_RIP] = (uintptr_t) func; As far as I know cast a function pointer to ordinary integer type or void*/char* is undefined behaviour in C specification. Or this is a gcc extension? (use uintptr_t cast on a function pointer to get the start address of the function code). If it's true, where I could found the detailed specification? Thanks a lot :) Remus ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c 2018-05-21 4:32 Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c Remus Clearwater @ 2018-05-21 11:39 ` Godmar Back [not found] ` <CAMjELStuFqCE3iVUR-ju3nZqG89dzfPET9kTWniz+kGPOm12ug@mail.gmail.com> 2018-05-22 11:21 ` Florian Weimer 1 sibling, 1 reply; 7+ messages in thread From: Godmar Back @ 2018-05-21 11:39 UTC (permalink / raw) To: Remus Clearwater; +Cc: libc-help On Mon, May 21, 2018 at 12:32 AM, Remus Clearwater <remus.clearwater@gmail.com> wrote: > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/makecontext.c;h=0d0802bf431326f7fcfe03d49df0c8ee7f4fdaab;hb=HEAD#l71 > > 51 void > 52 __makecontext (ucontext_t *ucp, void (*func) (void), int argc, ...) > 53 { > 54 extern void __start_context (void) attribute_hidden; > 55 greg_t *sp; > 56 unsigned int idx_uc_link; > 57 va_list ap; > 58 int i; > 59 > 60 /* Generate room on stack for parameter if needed and uc_link. */ > 61 sp = (greg_t *) ((uintptr_t) ucp->uc_stack.ss_sp > 62 + ucp->uc_stack.ss_size); > 63 sp -= (argc > 6 ? argc - 6 : 0) + 1; > 64 /* Align stack and make space for trampoline address. */ > 65 sp = (greg_t *) ((((uintptr_t) sp) & -16L) - 8); > 66 > 67 idx_uc_link = (argc > 6 ? argc - 6 : 0) + 1; > 68 > 69 /* Setup context ucp. */ > 70 /* Address to jump to. */ > > 71 ucp->uc_mcontext.gregs[REG_RIP] = (uintptr_t) func; > > As far as I know cast a function pointer to ordinary integer type or > void*/char* is undefined behaviour in C specification. > My reading is that it is implementation-defined, not undefined. Looking at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf it says: "Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type." and moreover: "The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to be consistent with the addressing structure of the execution environment." ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAMjELStuFqCE3iVUR-ju3nZqG89dzfPET9kTWniz+kGPOm12ug@mail.gmail.com>]
* Fwd: Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c [not found] ` <CAMjELStuFqCE3iVUR-ju3nZqG89dzfPET9kTWniz+kGPOm12ug@mail.gmail.com> @ 2018-05-21 13:09 ` Remus Clearwater 2018-05-21 13:18 ` Remus Clearwater 0 siblings, 1 reply; 7+ messages in thread From: Remus Clearwater @ 2018-05-21 13:09 UTC (permalink / raw) To: Godmar Back; +Cc: libc-help Sorry for forgot to CC libc-help. ---- Thanks a lot Godmar. But it didn't say `sizeof(function_pointer)` are must equal or less than `sizeof(void*)`. I found this in POSIX.1-2008 http://pubs.opengroup.org/ onlinepubs/9699919799.2008edition/functions/V2_chap02.html#tag_15_12_03: "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. Note: The ISO C standard does not require this, but it is required for POSIX conformance." So under POSIX.1-2008 the kinda usage of `function_address = (uintptr_t) funcfp;` is correct, but in POSIX.1-2017 this section 2.13.3 has been removed. This means in POSIX.1-2017 that kinda conversition is still not defined. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c 2018-05-21 13:09 ` Fwd: " Remus Clearwater @ 2018-05-21 13:18 ` Remus Clearwater 2018-05-21 14:27 ` Godmar Back 0 siblings, 1 reply; 7+ messages in thread From: Remus Clearwater @ 2018-05-21 13:18 UTC (permalink / raw) To: Godmar Back; +Cc: libc-help PS: The definition of uintptr_t in C99 is: “an unsigned integer type with the property that any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer” On Mon, May 21, 2018 at 9:08 PM, Remus Clearwater < remus.clearwater@gmail.com> wrote: > Sorry for forgot to CC libc-help. > > ---- > > Thanks a lot Godmar. > > But it didn't say `sizeof(function_pointer)` are must equal or less than > `sizeof(void*)`. > > I found this in POSIX.1-2008 http://pubs.opengroup.org/onli > nepubs/9699919799.2008edition/functions/V2_chap02.html#tag_15_12_03: > > "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. > > Note: > The ISO C standard does not require this, but it is required for POSIX > conformance." > > So under POSIX.1-2008 the kinda usage of `function_address = (uintptr_t) > funcfp;` is correct, but in POSIX.1-2017 this section 2.13.3 has been > removed. This means in POSIX.1-2017 that kinda conversition is still not > defined. > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c 2018-05-21 13:18 ` Remus Clearwater @ 2018-05-21 14:27 ` Godmar Back 2018-05-22 6:47 ` Remus Clearwater 0 siblings, 1 reply; 7+ messages in thread From: Godmar Back @ 2018-05-21 14:27 UTC (permalink / raw) To: Remus Clearwater; +Cc: libc-help If you're looking at just the C standard, uintptr_t wouldn't help since it's only guaranteed to hold object pointers, not function pointers I would dig deeper in terms of "implementation-defined". The C standards says that a conforming implementation should define the behavior of pointer to int conversions (except where undefined, which conversion of function pointers to integers are not). So somewhere, gcc/clang etc. - if conforming - will have to define what a function pointer converts to when converted to an int. This is, IMO, different from undefined behavior where the compiler can do whatever they please and doesn't owe anyone an explanation. See J.3 pg 566 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf On Mon, May 21, 2018 at 9:18 AM, Remus Clearwater <remus.clearwater@gmail.com> wrote: > PS: > > The definition of uintptr_t in C99 is: > > “an unsigned integer type with the property that any valid pointer to void > can be converted to this type, then converted back to pointer to void, and > the result will compare equal to the original pointer” > > On Mon, May 21, 2018 at 9:08 PM, Remus Clearwater > <remus.clearwater@gmail.com> wrote: >> >> Sorry for forgot to CC libc-help. >> >> ---- >> >> Thanks a lot Godmar. >> >> But it didn't say `sizeof(function_pointer)` are must equal or less than >> `sizeof(void*)`. >> >> I found this in POSIX.1-2008 >> http://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/V2_chap02.html#tag_15_12_03: >> >> "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. >> >> Note: >> The ISO C standard does not require this, but it is required for POSIX >> conformance." >> >> So under POSIX.1-2008 the kinda usage of `function_address = (uintptr_t) >> funcfp;` is correct, but in POSIX.1-2017 this section 2.13.3 has been >> removed. This means in POSIX.1-2017 that kinda conversition is still not >> defined. >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c 2018-05-21 14:27 ` Godmar Back @ 2018-05-22 6:47 ` Remus Clearwater 0 siblings, 0 replies; 7+ messages in thread From: Remus Clearwater @ 2018-05-22 6:47 UTC (permalink / raw) To: Godmar Back; +Cc: libc-help Thanks a lot Godmar for your very kind and detailed explanation, and I quite agree with you :D All best Remus On Mon, May 21, 2018 at 10:26 PM, Godmar Back <godmar@gmail.com> wrote: > If you're looking at just the C standard, uintptr_t wouldn't help > since it's only guaranteed to hold object pointers, not function > pointers > > I would dig deeper in terms of "implementation-defined". The C > standards says that a conforming implementation should define the > behavior of pointer to int conversions (except where undefined, which > conversion of function pointers to integers are not). So somewhere, > gcc/clang etc. - if conforming - will have to define what a function > pointer converts to when converted to an int. This is, IMO, different > from undefined behavior where the compiler can do whatever they please > and doesn't owe anyone an explanation. > > See J.3 pg 566 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf > > On Mon, May 21, 2018 at 9:18 AM, Remus Clearwater > <remus.clearwater@gmail.com> wrote: > > PS: > > > > The definition of uintptr_t in C99 is: > > > > “an unsigned integer type with the property that any valid pointer to > void > > can be converted to this type, then converted back to pointer to void, > and > > the result will compare equal to the original pointer” > > > > On Mon, May 21, 2018 at 9:08 PM, Remus Clearwater > > <remus.clearwater@gmail.com> wrote: > >> > >> Sorry for forgot to CC libc-help. > >> > >> ---- > >> > >> Thanks a lot Godmar. > >> > >> But it didn't say `sizeof(function_pointer)` are must equal or less than > >> `sizeof(void*)`. > >> > >> I found this in POSIX.1-2008 > >> http://pubs.opengroup.org/onlinepubs/9699919799. > 2008edition/functions/V2_chap02.html#tag_15_12_03: > >> > >> "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. > >> > >> Note: > >> The ISO C standard does not require this, but it is required for POSIX > >> conformance." > >> > >> So under POSIX.1-2008 the kinda usage of `function_address = (uintptr_t) > >> funcfp;` is correct, but in POSIX.1-2017 this section 2.13.3 has been > >> removed. This means in POSIX.1-2017 that kinda conversition is still not > >> defined. > >> > > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c 2018-05-21 4:32 Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c Remus Clearwater 2018-05-21 11:39 ` Godmar Back @ 2018-05-22 11:21 ` Florian Weimer 1 sibling, 0 replies; 7+ messages in thread From: Florian Weimer @ 2018-05-22 11:21 UTC (permalink / raw) To: Remus Clearwater, libc-help On 05/21/2018 06:32 AM, Remus Clearwater wrote: > As far as I know cast a function pointer to ordinary integer type or > void*/char* is undefined behaviour in C specification. ELF doesn't really work unless all your pointers are the same size, so we assume this throughout the code base. Conceptually, the ELFv1 ABI for POWER has function pointers which consist of multiple words, and the way this is solved is that function pointers point to a function descriptor, not the code address. This pointer is again a single word, as expected. It works because there is no run-time code generation and all the functions are known at static link time, so the link editor can make sure that the required descriptors exist somewhere. Thanks, Florian ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-05-22 11:21 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-21 4:32 Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c Remus Clearwater 2018-05-21 11:39 ` Godmar Back [not found] ` <CAMjELStuFqCE3iVUR-ju3nZqG89dzfPET9kTWniz+kGPOm12ug@mail.gmail.com> 2018-05-21 13:09 ` Fwd: " Remus Clearwater 2018-05-21 13:18 ` Remus Clearwater 2018-05-21 14:27 ` Godmar Back 2018-05-22 6:47 ` Remus Clearwater 2018-05-22 11:21 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).