problem about "value optimized out"

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

problem about "value optimized out"

lux_cnis
Dear all,

My code segment is to get a private key from a pem file for the data signing. The code is as the following:

1    BIO *priv_pem;
   
2    OpenSSL_add_all_algorithms();

3    priv_pem = BIO_new_file("privkey.pem", "rb");

 4   pKey_priv = RSA_new();

 5   pKey_priv = PEM_read_bio_RSAPrivateKey(priv_pem, &pKey_priv, NULL, "3042");

 6   BIO_free(priv_pem);

  7  data_generator(data_len, raw_apdu);

  8  hdr_generator(p_h);

   As you see, the first six lines are to get the private key, and the last two lines are to generate the data. My problem is that all the code below the line 6 are optimized out in gcc with the optimization option "-O2". The problem disappears when the option is set to "-O0", that means shut down the code optimization in gcc. In addition, when "-O2", the order of the code execution is strange when using gdb for debugging.

   I am not sure about the source of this problem. I guess that I made some mistakes when I used the function "PEM_read_bio_RSAPrivateKey()". Could anybody please tell me the method for me to use the function? Or, could you please help me to fix this problem. Thank you so much.

Best Regards,
Xiang
Reply | Threaded
Open this post in threaded view
|

RE: problem about "value optimized out"

Dave Thompson-5
> From: [hidden email] On Behalf Of ??
> Sent: Thursday, 01 July, 2010 18:13

> My code segment is to get a private key from a pem file for the data
signing.
> The code is as the following:
       
> 1    BIO *priv_pem;
           
> 2    OpenSSL_add_all_algorithms();
       
> 3    priv_pem = BIO_new_file("privkey.pem", "rb");

Should check priv_pem==NULL and handle error.
       
> 4   pKey_priv = RSA_new();
       
> 5   pKey_priv = PEM_read_bio_RSAPrivateKey(priv_pem, &pKey_priv,
NULL, "3042");

This is a little wasteful but not wrong. Unlike some other OpenSSL 'read x'
routines
which can store into an existing object, PEM_read[_bio]_(alg)PrivateKey
actually uses
the generic (EVP) version and then extracts the particular-type key, so it
can't reuse
an existing object. All of the 'read x' routines *can* create a new object,
and that's
usually the easiest way for all of them. I.e. skip line 4 and make second
argument NULL.

> 6   BIO_free(priv_pem);
       
>  7  data_generator(data_len, raw_apdu);
       
>  8  hdr_generator(p_h);
       
>   As you see, the first six lines are to get the private key, and
the last two lines
> are to generate the data. My problem is that all the code below the line 6
are optimized
> out in gcc with the optimization option "-O2". The problem disappears when
the option is
> set to "-O0", that means shut down the code optimization in gcc. In
addition, when "-O2",
> the order of the code execution is strange when using gdb for debugging.

'Strange' order of execution is normal for high optimization, which often
rearranges
(parts of) your code to make it run faster. It's usually easier to debug
unoptimized
compilation and then recompile with optimization. (Of course some really
nasty bugs
only show up in the optimized version, either because the optimizer has a
flaw and
actually generates bad code, which is rare, or because your program has an
obscure
aliasing or timing dependency which is exposed by optimization.)

But not "optimized out". The optimizer shouldn't entirely delete nondead
code.
Are those actually functions, or macros? If functions, are they visible (in
the same
translation unit, i.e. source file after preprocessing) and small/simple
enough to be
inlined? Especially if they are declared as inline or __inline__ (depending
on gcc
version and compilation mode)? That might (although I think not) result in
no code
*mapped to those line numbers* even though actual code exists; and certainly
could
result in no calls to the actual functions if that's where you set a
breakpoint.

>   I am not sure about the source of this problem. I guess that I
made some mistakes
> when I used the function "PEM_read_bio_RSAPrivateKey()". Could anybody
please tell me
> the method for me to use the function? Or, could you please help me to fix
this problem.
> Thank you so much.

What you did is OK, although as noted above there is a slightly better
option.

More likely your problem is in your use of gcc, or other tools like gdb.
Try deleteing or #if'ing-out your OpenSSL calls and data items, and compile
and debug your 'data' part by itself, then add the OpenSSL back in.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: problem about "value optimized out"

lux_cnis
Dear Dave,

Thank you for your detailed explanation. However, I still confused with those "optimized" line, which also occurs in the verification process. Here is the code to get a public key from the corresponding certificate, which follows your suggestions about EVP.

    OpenSSL_add_all_algorithms();
    BIO *cert;
    X509 *x;
    EVP_PKEY *evp_key;
    RSA *pKey_pub = NULL;
    cert = BIO_new_file("cacert.pem", "rb");
    pKey_pub  = RSA_new();
    x = X509_new();
    x = PEM_read_bio_X509(cert, &x, NULL, NULL);
    evp_key = X509_get_pubkey(x);
    pKey_pub = EVP_PKEY_get1_RSA(evp_key);

I even can not make "x = X509_new()" executed, which always been optimized out. If the process is correct, I am not sure if my code has other holes to lead this problem. Thank you so much.

Best Regards,
Xiang

2010/7/2 Dave Thompson <[hidden email]>
>       From: [hidden email] On Behalf Of ??
>       Sent: Thursday, 01 July, 2010 18:13

>       My code segment is to get a private key from a pem file for the data
signing.
> The code is as the following:

>       1    BIO *priv_pem;

>       2    OpenSSL_add_all_algorithms();

>       3    priv_pem = BIO_new_file("privkey.pem", "rb");

Should check priv_pem==NULL and handle error.

>        4   pKey_priv = RSA_new();

>        5   pKey_priv = PEM_read_bio_RSAPrivateKey(priv_pem, &pKey_priv,
NULL, "3042");

This is a little wasteful but not wrong. Unlike some other OpenSSL 'read x'
routines
which can store into an existing object, PEM_read[_bio]_(alg)PrivateKey
actually uses
the generic (EVP) version and then extracts the particular-type key, so it
can't reuse
an existing object. All of the 'read x' routines *can* create a new object,
and that's
usually the easiest way for all of them. I.e. skip line 4 and make second
argument NULL.

>        6   BIO_free(priv_pem);

>         7  data_generator(data_len, raw_apdu);

>         8  hdr_generator(p_h);

>          As you see, the first six lines are to get the private key, and
the last two lines
> are to generate the data. My problem is that all the code below the line 6
are optimized
> out in gcc with the optimization option "-O2". The problem disappears when
the option is
> set to "-O0", that means shut down the code optimization in gcc. In
addition, when "-O2",
> the order of the code execution is strange when using gdb for debugging.

'Strange' order of execution is normal for high optimization, which often
rearranges
(parts of) your code to make it run faster. It's usually easier to debug
unoptimized
compilation and then recompile with optimization. (Of course some really
nasty bugs
only show up in the optimized version, either because the optimizer has a
flaw and
actually generates bad code, which is rare, or because your program has an
obscure
aliasing or timing dependency which is exposed by optimization.)

But not "optimized out". The optimizer shouldn't entirely delete nondead
code.
Are those actually functions, or macros? If functions, are they visible (in
the same
translation unit, i.e. source file after preprocessing) and small/simple
enough to be
inlined? Especially if they are declared as inline or __inline__ (depending
on gcc
version and compilation mode)? That might (although I think not) result in
no code
*mapped to those line numbers* even though actual code exists; and certainly
could
result in no calls to the actual functions if that's where you set a
breakpoint.

>          I am not sure about the source of this problem. I guess that I
made some mistakes
> when I used the function "PEM_read_bio_RSAPrivateKey()". Could anybody
please tell me
> the method for me to use the function? Or, could you please help me to fix
this problem.
> Thank you so much.

What you did is OK, although as noted above there is a slightly better
option.

More likely your problem is in your use of gcc, or other tools like gdb.
Try deleteing or #if'ing-out your OpenSSL calls and data items, and compile
and debug your 'data' part by itself, then add the OpenSSL back in.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: problem about "value optimized out"

Jakob Bohm-7
In reply to this post by lux_cnis
On 02-07-2010 00:12, 翔芦 wrote:

> Dear all,
>
> My code segment is to get a private key from a pem file for the data
> signing. The code is as the following:
>
> 1    BIO *priv_pem;
>
> 2    OpenSSL_add_all_algorithms();
>
> 3    priv_pem = BIO_new_file("privkey.pem", "rb");
>
>   4   pKey_priv = RSA_new();
>
>   5   pKey_priv = PEM_read_bio_RSAPrivateKey(priv_pem, &pKey_priv, NULL,
> "3042");
>
>   6   BIO_free(priv_pem);
>
>    7  data_generator(data_len, raw_apdu);
>
>    8  hdr_generator(p_h);
>


There is apparently nothing in your code that uses the results from
lines 7 and 8, so the compiler optimizes it away as it doesn't
contribute to the result of your program.  The compiler could/should
have done the same for lines 1 through 6 (as you don't actually use the
loaded key for anything), but just doesn't know enough about openssl
internals to be sure the openssl calls don't output something useful.

Once you write lines 9 and later (to actually use the key and the
generated data) and some lines to actually output the result to your
smart card, the optimizer should stop optimizing away those lines.

(Compiling with -O0 tells gcc to be too stupid to eliminate the unused
lines).
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: problem about "value optimized out"

lux_cnis
Dear Jakob,

Thank your for your analysis. I am sorry for only post the part of my code. Actually, the result from Line 1 to Line 6 is to get the private key and make the pointer pKey_priv point to the private key. In the following lines below Line 8, I will use the pKey_priv to sign the data generated in Line 7 and Line 8.

Yes, I change the optimization option from -O2 to -O0. Only in this case, I can execute all the code lines. But I would like to know if the optimization will bring heavy negative impacts on the performance of the signing and verifying operation, which means the signing and verifying speed will be slow. That is my concern. Thank you.

Best Regards,
Xiang

2010/7/2 Jakob Bohm <[hidden email]>
On 02-07-2010 00:12, 翔芦 wrote:
Dear all,

My code segment is to get a private key from a pem file for the data
signing. The code is as the following:

1    BIO *priv_pem;

2    OpenSSL_add_all_algorithms();

3    priv_pem = BIO_new_file("privkey.pem", "rb");

 4   pKey_priv = RSA_new();

 5   pKey_priv = PEM_read_bio_RSAPrivateKey(priv_pem, &pKey_priv, NULL,
"3042");

 6   BIO_free(priv_pem);

  7  data_generator(data_len, raw_apdu);

  8  hdr_generator(p_h);



There is apparently nothing in your code that uses the results from lines 7 and 8, so the compiler optimizes it away as it doesn't contribute to the result of your program.  The compiler could/should
have done the same for lines 1 through 6 (as you don't actually use the
loaded key for anything), but just doesn't know enough about openssl internals to be sure the openssl calls don't output something useful.

Once you write lines 9 and later (to actually use the key and the generated data) and some lines to actually output the result to your
smart card, the optimizer should stop optimizing away those lines.

(Compiling with -O0 tells gcc to be too stupid to eliminate the unused
lines).

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: problem about "value optimized out"

Dave Thompson-5
In reply to this post by lux_cnis
> From: [hidden email] On Behalf Of ??
> Sent: Friday, 02 July, 2010 00:10

> Thank you for your detailed explanation. However, I still confused
with
> those "optimized" line, which also occurs in the verification process.
> Here is the code to get a public key from the corresponding certificate,
> which follows your suggestions about EVP.

Well, on the X.509 side you don't have a choice; the pubkey
in a cert is necessarily generic=EVP.

>    OpenSSL_add_all_algorithms();
>    BIO *cert;
>    X509 *x;
>    EVP_PKEY *evp_key;
>    RSA *pKey_pub = NULL;
>    cert = BIO_new_file("cacert.pem", "rb");
>    pKey_pub  = RSA_new();
>    x = X509_new();
>    x = PEM_read_bio_X509(cert, &x, NULL, NULL);
>    evp_key = X509_get_pubkey(x);
>    pKey_pub = EVP_PKEY_get1_RSA(evp_key);

> I even can not make "x = X509_new()" executed, which always
> been optimized out. If the process is correct, I am not sure if
> my code has other holes to lead this problem. Thank you so much.

What exactly do you mean by "optimized out"?
As I said this shouldn't be deleted entirely, since it is used.
But it's possible that the optimizer could rearrange the code
enough that nothing is *labelled* with that line number.

Note this differs slightly from the RSAprivate case because
read__X509 *can* use an existing object, although it *can* also
create a new object which I suggested as the better practice.
I believe recent versions of the GCC suite can do whole-program
optimization in at least some cases, but I thought not without
being asked specifically, and even if they did here that value
is truly used and couldn't be optimized away.

I tried a slightly simplified version of your code on the most
convenient system, which is gcc 3.4.4 x86 (Linux), with -O2.
Even without any use of the result it executes as expected:

(gdb) list 9,16
9               BIO * cert = BIO_new_file ("cacert.pem", "rb");
10              X509 *x;
11              x = X509_new();
12              x = PEM_read_bio_X509 (cert,&x,NULL,NULL);
13              //EVP_PKEY *evp_key = X509_get_pubkey (x);
14              //RSA *pub = EVP_PKEY_get1_RSA (evp_key);
15              //printf ("length %d\n", RSA_size(pub));
16              return 0;
(gdb) info line 9
Line 9 of "xiang.c" starts at address 0x80492b3 <main+11>
   and ends at 0x80492c4 <main+28>.
(gdb) info line 10
Line 10 of "xiang.c" is at address 0x80492c4 <main+28> but contains no code.
(gdb) info line 11
Line 11 of "xiang.c" starts at address 0x80492c4 <main+28>
   and ends at 0x80492c9 <main+33>.
(gdb) info line 12
Line 12 of "xiang.c" starts at address 0x80492c9 <main+33>
   and ends at 0x80492cd <main+37>.
(gdb) info line 16
Line 16 of "xiang.c" is at address 0x80492da <main+50> but contains no code.
(gdb) disass main
Dump of assembler code for function main:
0x080492a8 <main+0>:    push   %ebp
0x080492a9 <main+1>:    mov    %esp,%ebp
0x080492ab <main+3>:    push   %ebx
0x080492ac <main+4>:    push   %eax
0x080492ad <main+5>:    and    $0xfffffff0,%esp
0x080492b0 <main+8>:    sub    $0x18,%esp
0x080492b3 <main+11>:   push   $0x80b7648
0x080492b8 <main+16>:   push   $0x80b764b
0x080492bd <main+21>:   call   0x8049300 <BIO_new_file>
0x080492c2 <main+26>:   mov    %eax,%ebx
0x080492c4 <main+28>:   call   0x804b7c0 <X509_new>
0x080492c9 <main+33>:   push   $0x0
0x080492cb <main+35>:   push   $0x0
0x080492cd <main+37>:   mov    %eax,0xfffffff8(%ebp)
0x080492d0 <main+40>:   lea    0xfffffff8(%ebp),%eax
0x080492d3 <main+43>:   push   %eax
0x080492d4 <main+44>:   push   %ebx
0x080492d5 <main+45>:   call   0x8050780 <PEM_read_bio_X509>
0x080492da <main+50>:   xor    %eax,%eax
0x080492dc <main+52>:   mov    0xfffffffc(%ebp),%ebx
0x080492df <main+55>:   leave  
0x080492e0 <main+56>:   ret    
End of assembler dump.
(gdb) b 16
Breakpoint 1 at 0x80492da: file xiang.c, line 16.
(gdb) r
Starting program: /home1/dthomps/CSdev/hack/xiang

Breakpoint 1, main () at xiang.c:17
17      }
(gdb) p *x
$1 = {cert_info = 0x80d7318, sig_alg = 0x80d7498, signature = 0x80d74a8,
  valid = 0, references = 1,
  name = 0x80d87c0 "/C=US/ST=NJ/L=Princeton/O=Dave/OU=DSA test/CN=dsatest",
  ex_data = {sk = 0x0, dummy = 0}, ex_pathlen = -1, ex_pcpathlen = 0,
  ex_flags = 0, ex_kusage = 0, ex_xkusage = 0, ex_nscert = 0, skid = 0x0,
  akid = 0x0, policy_cache = 0x0, sha1_hash = '\0' <repeats 19 times>,
  aux = 0x0}
(gdb)

Note that the second instruction implementing line 11 namely
the store at main+37, is deferred to the middle of the code
implementing line 12, and thus the code from main+37 to main+50
isn't in the 'official' range for any line but nevertheless
gets executed and does the right thing. The return value from
PEM_read_bio_X509 is dead and doesn't actually get stored,
but it happens to be the same as the previously stored x.
(Though I'm not sure what main+52 is supposed to be doing.)

If your gcc is truly eliding a value that is used, or even worse
a call not provably effectless, you should be able to create
a minimal example with your own trivial (but separate) routines
instead of OpenSSL, and complain to the gcc folks (either trunk
or the packager for your distro if that's what you are using).
You should search or ask first to see if this is an already known
or even already fixed problem for the version you are using.

However, you (apparently) ask in another post if -O0 "will be slow".
All of the crypto computation is done deep in the OpenSSL library,
not in your code. You just call OpenSSL. What matters for speed
is how OpenSSL *was* compiled, not how your code is compiled.

And on any reasonable general-purpose system today (not
e.g. a router or cellphone) unless you're doing hundreds or
more PKE operations per second, it's probably fast enough.
If you want more exact times/numbers for your build,
commandline 'openssl speed $algorithm' will measure that
algorithm, or if omitted the 'usual suspects'.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: problem about "value optimized out"

lux_cnis
Dear Dave,

I really appreciate your detailed test and explanation. Now, I get your point. The "optimized out" means the code can not be executed in the execution. I guess the optimization reason lies in that those signed data are not be actually sent. I will review my code and the whole logic of my application.

In addition, I think you explanation about the performance makes sense. The optimization option only determine the efficiency of my code, not openssl lib.

Thank you very much.

Best Regards,
Xiang

2010/7/3 Dave Thompson <[hidden email]>
>       From: [hidden email] On Behalf Of ??
>       Sent: Friday, 02 July, 2010 00:10

>       Thank you for your detailed explanation. However, I still confused
with
> those "optimized" line, which also occurs in the verification process.
> Here is the code to get a public key from the corresponding certificate,
> which follows your suggestions about EVP.

Well, on the X.509 side you don't have a choice; the pubkey
in a cert is necessarily generic=EVP.

>           OpenSSL_add_all_algorithms();
>           BIO *cert;
>           X509 *x;
>           EVP_PKEY *evp_key;
>           RSA *pKey_pub = NULL;
>           cert = BIO_new_file("cacert.pem", "rb");
>           pKey_pub  = RSA_new();
>           x = X509_new();
>           x = PEM_read_bio_X509(cert, &x, NULL, NULL);
>           evp_key = X509_get_pubkey(x);
>           pKey_pub = EVP_PKEY_get1_RSA(evp_key);

>       I even can not make "x = X509_new()" executed, which always
> been optimized out. If the process is correct, I am not sure if
> my code has other holes to lead this problem. Thank you so much.

What exactly do you mean by "optimized out"?
As I said this shouldn't be deleted entirely, since it is used.
But it's possible that the optimizer could rearrange the code
enough that nothing is *labelled* with that line number.

Note this differs slightly from the RSAprivate case because
read__X509 *can* use an existing object, although it *can* also
create a new object which I suggested as the better practice.
I believe recent versions of the GCC suite can do whole-program
optimization in at least some cases, but I thought not without
being asked specifically, and even if they did here that value
is truly used and couldn't be optimized away.

I tried a slightly simplified version of your code on the most
convenient system, which is gcc 3.4.4 x86 (Linux), with -O2.
Even without any use of the result it executes as expected:

(gdb) list 9,16
9               BIO * cert = BIO_new_file ("cacert.pem", "rb");
10              X509 *x;
11              x = X509_new();
12              x = PEM_read_bio_X509 (cert,&x,NULL,NULL);
13              //EVP_PKEY *evp_key = X509_get_pubkey (x);
14              //RSA *pub = EVP_PKEY_get1_RSA (evp_key);
15              //printf ("length %d\n", RSA_size(pub));
16              return 0;
(gdb) info line 9
Line 9 of "xiang.c" starts at address 0x80492b3 <main+11>
  and ends at 0x80492c4 <main+28>.
(gdb) info line 10
Line 10 of "xiang.c" is at address 0x80492c4 <main+28> but contains no code.
(gdb) info line 11
Line 11 of "xiang.c" starts at address 0x80492c4 <main+28>
  and ends at 0x80492c9 <main+33>.
(gdb) info line 12
Line 12 of "xiang.c" starts at address 0x80492c9 <main+33>
  and ends at 0x80492cd <main+37>.
(gdb) info line 16
Line 16 of "xiang.c" is at address 0x80492da <main+50> but contains no code.
(gdb) disass main
Dump of assembler code for function main:
0x080492a8 <main+0>:    push   %ebp
0x080492a9 <main+1>:    mov    %esp,%ebp
0x080492ab <main+3>:    push   %ebx
0x080492ac <main+4>:    push   %eax
0x080492ad <main+5>:    and    $0xfffffff0,%esp
0x080492b0 <main+8>:    sub    $0x18,%esp
0x080492b3 <main+11>:   push   $0x80b7648
0x080492b8 <main+16>:   push   $0x80b764b
0x080492bd <main+21>:   call   0x8049300 <BIO_new_file>
0x080492c2 <main+26>:   mov    %eax,%ebx
0x080492c4 <main+28>:   call   0x804b7c0 <X509_new>
0x080492c9 <main+33>:   push   $0x0
0x080492cb <main+35>:   push   $0x0
0x080492cd <main+37>:   mov    %eax,0xfffffff8(%ebp)
0x080492d0 <main+40>:   lea    0xfffffff8(%ebp),%eax
0x080492d3 <main+43>:   push   %eax
0x080492d4 <main+44>:   push   %ebx
0x080492d5 <main+45>:   call   0x8050780 <PEM_read_bio_X509>
0x080492da <main+50>:   xor    %eax,%eax
0x080492dc <main+52>:   mov    0xfffffffc(%ebp),%ebx
0x080492df <main+55>:   leave
0x080492e0 <main+56>:   ret
End of assembler dump.
(gdb) b 16
Breakpoint 1 at 0x80492da: file xiang.c, line 16.
(gdb) r
Starting program: /home1/dthomps/CSdev/hack/xiang

Breakpoint 1, main () at xiang.c:17
17      }
(gdb) p *x
$1 = {cert_info = 0x80d7318, sig_alg = 0x80d7498, signature = 0x80d74a8,
 valid = 0, references = 1,
 name = 0x80d87c0 "/C=US/ST=NJ/L=Princeton/O=Dave/OU=DSA test/CN=dsatest",
 ex_data = {sk = 0x0, dummy = 0}, ex_pathlen = -1, ex_pcpathlen = 0,
 ex_flags = 0, ex_kusage = 0, ex_xkusage = 0, ex_nscert = 0, skid = 0x0,
 akid = 0x0, policy_cache = 0x0, sha1_hash = '\0' <repeats 19 times>,
 aux = 0x0}
(gdb)

Note that the second instruction implementing line 11 namely
the store at main+37, is deferred to the middle of the code
implementing line 12, and thus the code from main+37 to main+50
isn't in the 'official' range for any line but nevertheless
gets executed and does the right thing. The return value from
PEM_read_bio_X509 is dead and doesn't actually get stored,
but it happens to be the same as the previously stored x.
(Though I'm not sure what main+52 is supposed to be doing.)

If your gcc is truly eliding a value that is used, or even worse
a call not provably effectless, you should be able to create
a minimal example with your own trivial (but separate) routines
instead of OpenSSL, and complain to the gcc folks (either trunk
or the packager for your distro if that's what you are using).
You should search or ask first to see if this is an already known
or even already fixed problem for the version you are using.

However, you (apparently) ask in another post if -O0 "will be slow".
All of the crypto computation is done deep in the OpenSSL library,
not in your code. You just call OpenSSL. What matters for speed
is how OpenSSL *was* compiled, not how your code is compiled.

And on any reasonable general-purpose system today (not
e.g. a router or cellphone) unless you're doing hundreds or
more PKE operations per second, it's probably fast enough.
If you want more exact times/numbers for your build,
commandline 'openssl speed $algorithm' will measure that
algorithm, or if omitted the 'usual suspects'.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]