Anders Broman
Wed, 27 Jan 2010 22:38:45 -0800
-----Ursprungligt meddelande----- Från: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] För Jaap Keuter Skickat: den 28 januari 2010 00:05 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Wireshark won't compile on PPC64 boxes didier wrote: >>> Le mercredi 27 janvier 2010 à 23:12 +0200, Gerasimos Dimitriadis a >>> écrit : >>> 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++) >>> { >>> hfC.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. >> No I don't think it could. I replaced the whole >> static hf_register_info hf[] >> with >> extern hf_register_info hf[]; >> >> and it still didn't compile with gcc -m64 (4.4.1) >> >> The problem or one problem is all these: >> >> const per_sequence_t foo[] = { >> ... >> }; >> >> int dissect_ber_xxx() { >> offset = dissect_per_sequence(tvb, ..., foo); >> return offset; >> } >> >> const per_sequence_t bar[] = { >> ... >> }; >> >> int dissect_ber_yyy() { >> offset = dissect_per_sequence(tvb, ..., bar); >> return offset; >> } >> >> ----------------- >> >> As suggested using: >> const per_sequence_t foo[] = { >> ... >> }; >> >> const per_sequence_t bar[] = { >> ... >> }; >> >> const per_sequence_t *foobar[] = { >> &foo[0], >> &bar[0], >> }; >> >> int dissect_ber_xxx() { >> offset = dissect_per_sequence(tvb, ..., foobar[0]); >> return offset; >> } >> >> int dissect_ber_yyy() { >> offset = dissect_per_sequence(tvb, ..., foobar[1]); >> return offset; >> } >> >> Reduce the number of toc entries but it may not be enough and it needs >> some work in asn2wrs.py. >> >> IMO not compiling this protocol or using a stub for ppc64 is an easier >> option :) >> >> Note: >> I don't have a full powerpc 64bits setup thus I can only compile not >> link 64 bits code. >> >> Didier >> > ><rant> >I agree with not compiling or put in a stub for ppc64. > >64bit CPU's, Multiple cores, TB's of disk space, many Gig's of memory and >we're >still hitting a 64 kB limit? Geez, it's 2010 for crying out loud! ></rant> > >Oke, can we break this into smaller translation units? That means splitting >up >the ASN.1 ? > >Thanks, >Jaap _ Back in the dark ages I think I originally submitted this dissector in three parts based on Internode-definitions.asn, PDU-definitions.asn and InformationElements.asn because of the size. I suppose we could split it again. Regards Anders __________________________________________________________________________ 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