Almost all of the string constants are used for initializing data structures, so an extra problem I think is that the contents of a strings array cannot be directly used for initializing e.g. the hf_register_info array, since constants are needed for that. A solution for that would be to initialize the hf_register_info array with all string pointers set to NULL like this: { &hf_rrc_DL_DCCH_Message_PDU, { NULL, NULL, FT_NONE, BASE_NONE, NULL, 0, NULL, HFILL }}, ....
and then before calling proto_register_field_array set the correct pointers in runtime, from arrays where all the strings have been collected: for(i = 0; i < array_length(hf); i++) { hf[i].hfinfo.name = bigNameArray[i]; hf[i].hfinfo.abbrev = bigAbbrevArray[i]; hf[i].hfinfo.blurb = bigBlurbArray[i]; } Do you think that such a thing could solve the problem? I will try to create a script for automating this process and see what comes from it. /Gerasimos 2010/1/27 didier <dgauthe...@magic.fr>: > Hi, > Le mercredi 27 janvier 2010 à 14:56 +0100, Radek Vokál a écrit : >> On 01/27/2010 09:32 AM, didier wrote: >> > Hi, >> > Le mercredi 27 janvier 2010 à 00:54 -0700, Stephen Fisher a écrit : >> >> On Tue, Jan 26, 2010 at 06:40:38PM +0100, Radek Vokál wrote: >> >> >> >>> The wireshark package cannot be build on ppc64 due to ppc64 ABI >> >>> limitation and RRC dissector source file which contains too many >> >>> string constants. >> >> >> >> That's not good :(. I didn't realize until now that packet-rrc.c is >> >> about 7MB of text (code) with over 150,000 lines! Only the similar >> >> dissector packet-nbap.c is even close at almost 70,000 lines at about >> >> 3.5MB. I assume that packet-nbap.c isn't causing compilation problems >> >> on ppc64? My first thought is to just pull packet-rrc.c from the >> >> makefile, but if you're building packages for others, then leaving out a >> >> dissector could be bad. I wonder if it would make a difference if we >> >> converted it to be a plug-in dissector that ships with Wireshark? >> >> >> >> Lacking that, we may be able to make the ASN.1 dissector generator spit >> >> out a file that works on ppc64. Sure seems like a lot of extra work to >> >> support one platform, but then again, maybe it would be easier to manage >> >> anyway having all of those strings handled differently. >> > There's a lot of stuff like: >> > { "midambleAllocationMode", "rrc.midambleAllocationMode", ... >> > Is it possible to compress it to the pseudo code: >> > >> > const foo = "rrc.midambleAllocationMode" >> > {&foo +4, foo, .... >> > >> > ? >> > It should be faster on all platforms. >> > >> > Don't know if it's enough. >> > >> > Didier >> > >> > Never mind it's about the number of toc entries, my idea doesn't work in > this case. > >> The other solution would be to move all string literals to an const char >> array and access them from that array. > Yes but with xxx_sequence_t the not const char, may blow latter though > this stuff is really big. > > Didier > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe