Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Wireshark won't compile on PPC64 boxes

From: "Anders Broman" <a.broman@xxxxxxxxx>
Date: Thu, 28 Jan 2010 07:37:05 +0100

-----Ursprungligt meddelande-----
Från: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe