From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10554 invoked by alias); 14 Mar 2015 20:44:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 10545 invoked by uid 89); 14 Mar 2015 20:44:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: bin-vsp-out-03.atm.binero.net Received: from vsp-authed01.binero.net (HELO bin-vsp-out-03.atm.binero.net) (195.74.38.224) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 14 Mar 2015 20:44:52 +0000 X-Halon-ID: f2aafa47-ca8a-11e4-9958-0050569116f7 Authorized-sender: jiri@gaisler.se Received: from [192.168.9.20] (unknown [46.246.50.236]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPA for ; Sat, 14 Mar 2015 21:44:45 +0100 (CET) Message-ID: <55049DBE.5080204@gaisler.se> Date: Sat, 14 Mar 2015 20:44:00 -0000 From: Jiri Gaisler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [PATCH v3 03/14] sim/erc32: Switched emulated memory to host endian order. References: <1425244244-27709-1-git-send-email-jiri@gaisler.se> <1425244244-27709-4-git-send-email-jiri@gaisler.se> <20150302011342.GH19363@vapier> <55020453.9080502@gaisler.se> <20150312235507.GG877@vapier> <55029ED9.5070009@gaisler.se> <20150314074532.GX877@vapier> <5503FDF9.8000109@gaisler.se> <20150314102356.GZ877@vapier> In-Reply-To: <20150314102356.GZ877@vapier> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LdQXh0nc0TuthO2A53RTfA7OjBCflgh8d" X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00423.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LdQXh0nc0TuthO2A53RTfA7OjBCflgh8d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 4134 On 14/03/15 11:23, Mike Frysinger wrote: > On 14 Mar 2015 10:23, Jiri Gaisler wrote: >> On 14/03/15 08:45, Mike Frysinger wrote: >>> On 13 Mar 2015 09:24, Jiri Gaisler wrote: >>>> On 13/03/15 00:55, Mike Frysinger wrote: >>>>> On 12 Mar 2015 22:25, Jiri Gaisler wrote: >>>>>> On 02/03/15 02:13, Mike Frysinger wrote: >>>>>>>> +#ifdef HOST_LITTLE_ENDIAN >>>>>>>>> + for (i =3D 0; i < (count / 4); i++) wbuffer[i] =3D ntohl(w= buffer[i]); // endian swap >>>>>>>>> +#endif >>>>>>> >>>>>>> sim-endian.h already provides a lot of helper funcs that i'm pretty= sure you=20 >>>>>>> can use here. >>>>>> >>>>>> I don't understand why ntohl() is a problem. It is a common Posix fu= nction >>>>>> that converts big endian to host endian, exactly what is needed. Usi= ng >>>>>> sim-endian.h pulls in a lot of the sim-*.c files due to dependencies= and >>>>>> makes the simulator larger than necessary .... >>>>> >>>>> "network" has no meaning here. using it as a proxy for moving betwee= n big=20 >>>>> endian and native endian when there are clear functions that the sim = has=20 >>>>> standardized on isn't correct. your code also (1) requires duplicati= ng branches=20 >>>>> and (2) inline preprocessor checks. it also does not properly handle= bi-endian=20 >>>>> builds. sim-endian does all of these for you. the whole point of co= mmon/ is=20 >>>>> to delete code from each sim rather than open coding it everywhere. >>>>> >>>>> wrt size, i don't think that's a compelling argument. we're talking = units of=20 >>>>> KiB here, and i can't even count that low :P. >>>>> >>>>> if you're having trouble converting the build over (compiling/linking= errors),=20 >>>>> then we can discuss that. but it'd be a matter of "do we do it now o= r later"=20 >>>>> rather than "do we do ever convert". >>>> >>>> Right. I tried to use the T2H_4 macro, but can't get it to compile. >>>> I included and added sim-endian.o and sim-io.o to the >>>> Makefile, but it complains about unresolved function etc. Do I really >>>> need to create a sim-main.c and sim-main.h just to use T2H? >>> >>> i've pushed a patch to bury the sim-io.h include in sim-assert.h (since= that's=20 >>> the header that actually uses the sim_io_xxx funcs). if you define you= r own=20 >>> ASSERT/SIM_ASSERT macros, it should be avoided for now. just make sure= you add=20 >>> a note that they should get converted to sim-assert.h at some point. >> >> I'm not sure this helps. sim-endian.c includes sim-assert.h, so I get the >> same problem even after your patch: >> >> gcc -DHAVE_CONFIG_H -DPROFILE=3D1 -DWITH_PROFILE=3D-1 -DWITH= _HOST_BYTE_ORDER=3DLITTLE_ENDIAN -DDEFAULT_INLINE=3D0 -DFAST_UART= -I../../../../../ibm/src/gdb/binutils-gdb/sim/erc32/../.. -I. -I../../..= /../../ibm/src/gdb/binutils-gdb/sim/erc32 -I../common >> -I../../../../../ibm/src/gdb/binutils-gdb/sim/erc32/../common -I../../in= clude -I../../../../../ibm/src/gdb/binutils-gdb/sim/erc32/../../include -I.= ./../bfd -I../../../../../ibm/src/gdb/binutils-gdb/sim/erc32/../../bfd -I..= /../opcodes >> -I../../../../../ibm/src/gdb/binutils-gdb/sim/erc32/../../opcodes -g -O= 2 -static-libstdc++ -static-libgcc -o run \ >> run.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a ../../l= ibiberty/libiberty.a -ltermcap -ldl -lz -lnsl ../../readline/libreadline.a= -ltermcap -lm >> libsim.a(sim-endian.o): In function `offset_1': >> /home/jiri/src/gdb/v4/sim/erc32/../../../../../ibm/src/gdb/binutils-gdb/= sim/erc32/../common/sim-n-endian.h:145: undefined reference to `sim_io_erro= r' >=20 > did you define ASSERT/SIM_ASSERT before including sim-endian.h ? No, I included sim-basic.h in my code. Including sim-endian.h only will not work due to dependencies on other include files. I don't see how this will change how sim-endian.o is built though, as it is compiled separately. I did manage to compile the code by including sim-endian.c directly into my own code (func.c) rather then building it separately: #include #undef ASSERT #define ASSERT(x) if (0) {} #include Is this acceptable ...? Jiri. --LdQXh0nc0TuthO2A53RTfA7OjBCflgh8d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 884 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJVBJ2+AAoJEIAIwBKmO2+bfKkP/0NKBqu2eUaTKaJdHKM4+ze/ V9fQRbFxb4e6ubAoCLXvccKnTFsAPJN39vuL8ERKcCv74GmwKVlpLHLq0xqSFv9w p/uxZkG1wjK3rA/RJUxtVVPBvhRGdLRmpJDcOyn6LY9/a3z/mATLbwguFZMDrFY3 HAUe3MXYSPYsVWt51iR1mn2MCxGOFxcyJrMHwzaDT2OR78vIR7BBYM8bHn2w/d2V SRKr/QV45U4bhhf02AeHmtFmQd+cdqAnoEcCJ/WPJGobDQYAkE/iIdWE1jDBNRBD HmNfgoHMbXZ9Vizb4bxrL/ldWNKHEokdOzcmWcKiymNzCBifiJtsmnBW7V5Cmmwm MB3yIZkJVbfVPK5K7fXxNi2wwwGH7FUD5fh82t9a7nY/d04NrVYaIbVJvITmHjf6 NKMJ0Ew87h1J/7AOeDX4ABmMqBFEseDFwxGoktjHIAL9Mx7vw3phTgqsZChqO/wo hQAltzwDGYKMHbq0ejxVcAI1N7zVVhLs9M+WH29K+Q9YPyJ065ijfsEHcloYhlye waUBkrpPt8ZKyC6dfaazr2KKMzqPpl+6EUckFg5jx9sUbo6YF10QvwKI9QkKyOHs p/ub8iX3pSOwpbvU69mYteFljTrArxTnYbeHeVajU/Ek1GVXeG5eHa+UT/f5dMil O33ACiuJOIboqx8zdfbk =JEkp -----END PGP SIGNATURE----- --LdQXh0nc0TuthO2A53RTfA7OjBCflgh8d--