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 <dgautheron@xxxxxxxx>:
> 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@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
