> From: owner-openssl-us...@openssl.org 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 openssl-users@openssl.org
Automated List Manager majord...@openssl.org
