On 21/02/18 21:38, Michael Richardson wrote:
>
> I'm capturing from my DTLS client and server, with CoAP running on top.
> I've been debugging some ruby-level I/O buffering issues.
> I noticed this while capturing, and used tshark to get this print out.
> (I've added columns for port numbers)
>
>> And "the default for all v9 architectures is -xmemalign=8s".
> I'm getting confused. Since I did not specify -xmemalign at all,
And not specifying -xmemalign is equivalent of specifying 8s in 64-bit
build such as one in question.
> why
> did the test fail with SIGBUS in the first place? Seem
On 2/21/2018 12:46 PM, Andy Polyakov wrote:
And "the default for all v9 architectures is -xmemalign=8s".
I'm getting confused. Since I did not specify -xmemalign at all, why
did the test fail with SIGBUS in the first place? Seems like there
should have been no alignment problem if the compile
I'm capturing from my DTLS client and server, with CoAP running on top.
I've been debugging some ruby-level I/O buffering issues.
I noticed this while capturing, and used tshark to get this print out.
(I've added columns for port numbers)
2 66.009171 ::2 35345 ::2 5684 DTLSv1
> So really we could do all manner of nasty things here and watch all
> manner of performance results and cool coredumps and it would be fun to
> try. However the option -xmemalign=8s will enforce "There should be no
> misaligned accesses in the program".
And "the default for all v9 architectures
On 21/02/18 12:57 PM, Norm Green wrote:
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to th
On 2/20/2018 9:34 AM, J Decker wrote:
> Client does a verification and passes or fails, and via the SSL layer
> I can query if the client validated the certificate.
> If it failed, provide a option for the client to get a renewed
> certificate for verification. If success, no action.
> If an actor
On 21/02/18 12:57 PM, Norm Green wrote:
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to th
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to the compile/link flags.
Norm
--
openssl-
On 21/02/18 12:11 PM, Norm Green wrote:
> On 2/21/2018 8:42 AM, Dennis Clarke wrote:
>> Pretty sure I have done builds and tests. In fact I am certain of it.
>
> If you added -xmemalign=8s to the SPARC compiler flags (as shown in one
> of your emails from yesterday) then you would not see the prob
On 2/21/2018 8:42 AM, Dennis Clarke wrote:
Pretty sure I have done builds and tests. In fact I am certain of it.
If you added -xmemalign=8s to the SPARC compiler flags (as shown in one
of your emails from yesterday) then you would not see the problem.
-xmemalign=8s forces the compiler to use
Thanks for suggestion, don't understand why the compiler didn't complain
about the first argument. Unfortunately, that just brings out other
problem
code:
bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) {
if (_pDH == NULL) {
FATAL("DHWrapper not initialized");
> On Feb 21, 2018, at 11:42 AM, Dennis Clarke wrote:
>
> On 21/02/18 09:14 AM, Viktor Dukhovni wrote:
>>> On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote:
>>>
>>> I wonder how come the problem with asn1_encode_test.c went unnoticed so
>>> far. Objects on stack are customarily aligned at poin
On 21/02/18 09:14 AM, Viktor Dukhovni wrote:
On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote:
I wonder how come the problem with asn1_encode_test.c went unnoticed so
far. Objects on stack are customarily aligned at pointer size, even if
their declaration doesn't imply corresponding guarante
On 21/02/18 16:20, Benjamin Kaduk via openssl-users wrote:
> On 02/21/2018 10:16 AM, Robert Watson wrote:
>> I'm trying to update a crypto library for crtmpserver to work with
>> openssl 1.1.0. The software is no longer actively maintained and my
>> c++ skills are somewhat rudimentary but I keep
On 02/21/2018 10:16 AM, Robert Watson wrote:
> I'm trying to update a crypto library for crtmpserver to work with
> openssl 1.1.0. The software is no longer actively maintained and my
> c++ skills are somewhat rudimentary but I keep getting a compilation
> error for something that seems trivial.
>
I'm trying to update a crypto library for crtmpserver to work with openssl
1.1.0. The software is no longer actively maintained and my c++ skills are
somewhat rudimentary but I keep getting a compilation error for something
that seems trivial.
Here's the code snippet:
bool DHWrapper::CopyPublicKe
> On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote:
>
> I wonder how come the problem with asn1_encode_test.c went unnoticed so
> far. Objects on stack are customarily aligned at pointer size, even if
> their declaration doesn't imply corresponding guarantee. So there are
> two options here: a)
This is very useful! Can you post an udate to the wiki?
https://wiki.openssl.org/index.php/Binaries
On 2/21/18, 8:57 AM, "Angus Robertson - Magenta Systems Ltd"
wrote:
Windows developers may be interested in our Win32 build of OpenSSL
1.1.1-pre1 (alpha), the binaries are digitally
> https://github.com/openssl/openssl/pull/5423
I wonder how come the problem with asn1_encode_test.c went unnoticed so
far. Objects on stack are customarily aligned at pointer size, even if
their declaration doesn't imply corresponding guarantee. So there are
two options here: a) it's first time i
> Interesting comment :
>
>
> Solaris x86 with Sun C setups
> # There used to be solaris-x86-cc target, but it was removed,
> # primarily because vendor assembler can't assemble our modules
> # with -KPIC flag. As result it, assembly support, was not even
> # available as opt
On 21/02/18 01:19, Andrei Danaila wrote:
> Any insight would be greatly appreciated.
>
All OpenSSL versions before 1.1.0 provide no symbol version information.
However Debian distribute a patched version of OpenSSL that adds this -
so this is why you will see a difference between your system su
22 matches
Mail list logo
