Mailing List Archive: OpenSSH: Dev

Problems porting to an ARM platform

Index | Next | Previous | View Threaded

c.baumann at ppc-ag

Oct 19, 2009, 5:20 AM

Post #1 of 14 (2016 views)
Permalink

Problems porting to an ARM platform

Hello,

currently I'm working on getting ssh and sshd running on an ARM
platform. The OS is Linux 2.6.10 with busybox.
I can run "ssh -v" to see the program version. But as soon as I try to
connect to a server I get a segmentation fault (SIGSEGV). The sshd seems
to work. Are there any known issues concerning ARM platforms? Or any
hints about compiler options (GCC)?

Regards,
Christoph Baumann

--

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax: +49(621)40165-???
mailto://c.baumann [at] ppc-ag
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Schönberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

dtucker at zip

Oct 19, 2009, 5:29 AM

Post #2 of 14 (1956 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

Christoph Baumann wrote:
> Hello,
>
> currently I'm working on getting ssh and sshd running on an ARM
> platform. The OS is Linux 2.6.10 with busybox.
> I can run "ssh -v" to see the program version. But as soon as I try to
> connect to a server I get a segmentation fault (SIGSEGV). The sshd seems
> to work. Are there any known issues concerning ARM platforms?

None that I'm aware of.

> Or any hints about compiler options (GCC)?

What point in the connection does it crash at? ("ssh -vvv server").
Can you run it under a debugger? If so what does the backtrace say?

The first thing I'd check is that OpenSSL passes its self-test "make
tests" and/or compile it without assembler optimizations (./Configure
no-asm). Failing that, I'd compile OpenSSL, zlib and OpenSSH without
compiler optimizations (gcc -O0).

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

c.baumann at ppc-ag

Oct 19, 2009, 5:44 AM

Post #3 of 14 (1960 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

On 19.10.2009 14:29, Darren Tucker wrote:
> What point in the connection does it crash at? ("ssh -vvv server"). Can
> you run it under a debugger? If so what does the backtrace say?

"
$ ssh -vvv 192.168.2.10
OpenSSH_4.3p2, OpenSSL 0.9.7j-dev XX xxx XXXX
SIGSEGV
"

I also tried the latest version of SSH with the same results.

> The first thing I'd check is that OpenSSL passes its self-test "make
> tests" and/or compile it without assembler optimizations (./Configure
> no-asm). Failing that, I'd compile OpenSSL, zlib and OpenSSH without
> compiler optimizations (gcc -O0).

Well maybe it's OpenSSL. In all cases I used the same (binary) version
of it.

--

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax: +49(621)40165-???
mailto://c.baumann [at] ppc-ag
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Schönberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

c.baumann at ppc-ag

Oct 21, 2009, 2:55 AM

Post #4 of 14 (1939 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

On 19.10.2009 14:29, Darren Tucker wrote:
> What point in the connection does it crash at? ("ssh -vvv server"). Can
> you run it under a debugger? If so what does the backtrace say?

I now compiled against OpenSSL 0.9.8k. This made the ssh client getting
a bit further.

$ ssh -vvv 192.168.2.10
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
/etc/ssh/ssh_config line 50: Unsupported option "GSSAPIAuthentication"
/etc/ssh/ssh_config line 51: Unsupported option "GSSAPIDelegateCredentials"
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.2.10 [192.168.2.10] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.1p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug2: fd 4 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc [at] lysator
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc [at] lysator
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64 [at] openssh,hmac-ripemd160,hmac-ripemd160 [at] openssh,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64 [at] openssh,hmac-ripemd160,hmac-ripemd160 [at] openssh,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib [at] openssh,zlib
debug2: kex_parse_kexinit: none,zlib [at] openssh,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc [at] lysator,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc [at] lysator,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64 [at] openssh,hmac-ripemd160,hmac-ripemd160 [at] openssh,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,umac-64 [at] openssh,hmac-ripemd160,hmac-ripemd160 [at] openssh,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib [at] openssh
debug2: kex_parse_kexinit: none,zlib [at] openssh
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 133/256
debug2: bits set: 514/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '192.168.2.10' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 500/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
SIGSEGV

Regards
Christoph Baumann

--

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax: +49(621)40165-???
mailto://c.baumann [at] ppc-ag
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Schönberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott

THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS
CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK
PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE
INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE
INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE,
DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS
STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL
TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE
ORIGINAL MESSAGE FROM YOUR DATABASE

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

dtucker at zip

Oct 21, 2009, 3:38 AM

Post #5 of 14 (1943 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

Christoph Baumann wrote:
> On 19.10.2009 14:29, Darren Tucker wrote:
>> What point in the connection does it crash at? ("ssh -vvv server"). Can
>> you run it under a debugger? If so what does the backtrace say?
>
> I now compiled against OpenSSL 0.9.8k. This made the ssh client getting
> a bit further.
>
> $ ssh -vvv 192.168.2.10
[...]
> debug2: service_accept: ssh-userauth
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> SIGSEGV

It's not obvious where it's crashing, but the next step is
authentication, and if you have any public keys it might be crashing
trying to load them.

How did you configure and compile OpenSSL? What compile options did you
use?

I'll ask the questions I asked previously that you haven't answered:
- does openssl's "make test" pass?
- can you run ssh under a debugger? if so what does the backtrace show?

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

c.baumann at ppc-ag

Oct 21, 2009, 7:49 AM

Post #6 of 14 (1934 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

On 21.10.2009 12:38, Darren Tucker wrote:
> It's not obvious where it's crashing, but the next step is
> authentication, and if you have any public keys it might be crashing
> trying to load them.

This is odd, as sshd runs stable with public key authentication.

>
> How did you configure and compile OpenSSL? What compile options did you
> use?

My configuration/build script for OpenSSL looks like this:

export CC=arm-uclinux-gcc
export LD=arm-uclinux-ld
make clean
./Configure linux-generic32 no-asm no-hw no-krb5 no-shared \
no-dso no-threads zlib -I../../../zlib -L../zlib \
-march=armv5 -msoft-float -mtune=arm926ejs -D_FILE_OFFSET_BITS=32
make -j2 build_libs

The script for OpenSSH is attached.

> I'll ask the questions I asked previously that you haven't answered:
> - does openssl's "make test" pass?

No. The test programs use the option "-ldl" to compile which is not
supported by our embedded platform (only static executables).

> - can you run ssh under a debugger? if so what does the backtrace show?

Currently I don't have a gdb suitable for running on the target (it uses
the bflt executable format).

Regards
Christoph Baumann

--

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax: +49(621)40165-???
mailto://c.baumann [at] ppc-ag
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Schönberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott

THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS
CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK
PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE
INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE
INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE,
DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS
STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL
TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE
ORIGINAL MESSAGE FROM YOUR DATABASE

Attachments:

config.ppc (1.21 KB)

alex at alex

Oct 21, 2009, 10:00 AM

Post #7 of 14 (1938 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

--On 21 October 2009 16:49:53 +0200 Christoph Baumann <c.baumann [at] ppc-ag>
wrote:

>> - can you run ssh under a debugger? if so what does the backtrace show?
>
> Currently I don't have a gdb suitable for running on the target (it uses
> the bflt executable format).

strace / ltrace might be your friends.

Crashes really early on are sometimes the result of a dynamically
linked library not loading. You might check using your preferred
library tool that the executable really is entirely static (as you
suggest that's all your platform supports). Sometimes configure
options don't do everything you expect them to (not a specific
reference to openssh).

You could also try compiling for the local platform with all the
same options except the arm specific ones and see if it crashes
in the same way.

--
Alex Bligh
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

c.baumann at ppc-ag

Oct 26, 2009, 8:31 AM

Post #8 of 14 (1892 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

Hello all,

using 'debug3' for debugging I traced the problem to 'getenv'. This call
crashes on my platform. To avoid this I inserted a wrapper to getenv
that returns some default values for 'TERM' and 'SSH_AUTH_SOCK'. Now ssh
runs until the output:
"debug1: Sending environment."

Here again the environment variables are accessed. The parameter 'env'
of 'client_session2_setup' has the value 0x58585858, which looks like a
rather improbable value for a pointer.
Currently I try to track this further down.

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax: +49(621)40165-???
mailto://c.baumann [at] ppc-ag
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Schönberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott

THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS
CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK
PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE
INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE
INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE,
DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS
STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL
TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE
ORIGINAL MESSAGE FROM YOUR DATABASE

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

peter at stuge

Oct 29, 2009, 7:41 PM

Post #9 of 14 (1856 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

Christoph Baumann wrote:
> Here again the environment variables are accessed. The parameter 'env'
> of 'client_session2_setup' has the value 0x58585858, which looks like
> a rather improbable value for a pointer.

0x58 == 'X'

> Currently I try to track this further down.

See if you can use valgrind on the target.

//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

c.baumann at ppc-ag

Oct 30, 2009, 6:25 AM

Post #10 of 14 (1850 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

On 30.10.2009 03:41, Peter Stuge wrote:
> Christoph Baumann wrote:
>> Here again the environment variables are accessed. The parameter 'env'
>> of 'client_session2_setup' has the value 0x58585858, which looks like
>> a rather improbable value for a pointer.
>
> 0x58 == 'X'

That's a good point! I searched for the values 0x58585858 and 'X' in the
sources and added more trace output. At the moment it looks like the
function "initialize_options" in readconf.c is the culprit. It uses a
"memset(options, 'X', sizeof(* options));" right at the start. After
calling this function the "environ" is overwritten with 'X'. But I can't
see why this happens.

--

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax: +49(621)40165-???
mailto://c.baumann [at] ppc-ag
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Schönberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott

THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS
CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK
PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE
INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE
INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE,
DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS
STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL
TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE
ORIGINAL MESSAGE FROM YOUR DATABASE

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

peter at stuge

Oct 30, 2009, 8:27 AM

Post #11 of 14 (1858 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

Christoph Baumann wrote:
> "initialize_options" in readconf.c is the culprit. It uses a
> "memset(options, 'X', sizeof(* options));" right at the start.
> After calling this function the "environ" is overwritten with 'X'.
> But I can't see why this happens.

Add debugging:

fprintf(stderr, "options=%p sizeof(* options)=%d 0x%x\n",
options, sizeof(* options), sizeof(* options));

Also check what type options is?

//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

c.baumann at ppc-ag

Oct 30, 2009, 8:32 AM

Post #12 of 14 (1847 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

On 30.10.2009 16:27, Peter Stuge wrote:
> Add debugging:
>
> fprintf(stderr, "options=%p sizeof(* options)=%d 0x%x\n",
> options, sizeof(* options), sizeof(* options));
>
> Also check what type options is?

The type of the global variable options is "Options" (note capital O).
My trace output of the interesting addresses is this:

&environ: 0x70cfb69c
&options: 0x70cfa218
&options.forward_agent: 0x70cfa218
&options.visual_host_key: 0x70cfb6c8
sizeof(Options): 5300

'forward_agent' is the first and 'visual_host_key' the last element of
the Options structure. As you can see the addresses overlap with 'environ'.

This looks like a compiler problem. Any hints to fix that?

--

Dipl.-Phys. Christoph Baumann
Power PLUS Communications AG
Am Exerzierplatz 2
68167 Mannheim
Germany

phone: +49(621)40165-???
fax: +49(621)40165-???
mailto://c.baumann [at] ppc-ag
http://www.ppc-ag.de

Handelsregister-Nr.: HRB 8853
Sitz und Registergericht: Mannheim
Vorstand: Ingo Schönberg (Vorsitzender), Eugen Mayer
Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

peter at stuge

Oct 30, 2009, 9:27 AM

Post #13 of 14 (1859 views)
Permalink

Re: Problems porting to an ARM platform [In reply to]

Christoph Baumann wrote:
> This looks like a compiler problem. Any hints to fix that?

Umm.. Use another toolchain?

//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

scott_n at xypro

Oct 30, 2009, 10:41 AM

Post #14 of 14 (1854 views)
Permalink

RE: Problems porting to an ARM platform [In reply to]

> Christoph Baumann wrote:
> > This looks like a compiler problem. Any hints to fix that?
>
> Umm.. Use another toolchain?
>

This is going to sound incredibly stupid and obvious. Any chance that
a complete "make clean" and rebuild will clean it up? Sounds almost
like
something is defined in multiple places with different sizes.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads