[Wireshark-dev] O2 compile option makes it difficult to debug.
Hi, It seems like the O2 option interferes with running the debugger. Would it be better to only use O2 on release builds? I'm not sure how to do that, add nmake -f makefile.nmake release option? 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
Re: [Wireshark-dev] O2 compile option makes it difficult to debug.
+1 I was trying to hold out until the CMake stuff for Windows is complete. Since it sounds close, I thought I could just deal with merging the removal of O2 option for awhile. -Original Message- From: Anders Broman a.broma...@gmail.com To: Developer support list for Wireshark wireshark-dev@wireshark.org Sent: Mon, Jul 28, 2014 8:13 am Subject: [Wireshark-dev] O2 compile option makes it difficult to debug. Hi, It seems like the O2 option interferes with running the debugger. Would it be better to only use O2 on release builds? I'm not sure how to do that, add nmake -f makefile.nmake release option? 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
Re: [Wireshark-dev] O2 compile option makes it difficult to debug.
What issues are you facing? I debug O2 code all the time, including profile guided optimised builds as well without too much difficulty. The most common problem is frame pointer omission making local variables and function parameters tough to locate. The /d2Zi+ switch (or /Zo for VS2013 Update 3) can help. See http://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/ for more info. On 28 July 2014 13:11, Anders Broman a.broma...@gmail.com wrote: Hi, It seems like the O2 option interferes with running the debugger. Would it be better to only use O2 on release builds? I'm not sure how to do that, add nmake -f makefile.nmake release option? 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 -- Graham Bloice Software Developer Trihedral UK Limited ___ 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
Re: [Wireshark-dev] O2 compile option makes it difficult to debug.
On 28 July 2014 13:35, mman...@netscape.net wrote: +1 I was trying to hold out until the CMake stuff for Windows is complete. Since it sounds close, I thought I could just deal with merging the removal of O2 option for awhile. Feedback on the latest CMake changes I added to Gerrit wold be handy :-) ___ 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
Re: [Wireshark-dev] O2 compile option makes it difficult to debug.
Hi, It seems like the O2 option interferes with running the debugger. Would it be better to only use O2 on release builds? I'm not sure how to do that, add nmake -f makefile.nmake release option? What I've done is to alter config.nmake slightly to allow the specification of WIRESHARK_ENVIRONMENT_CFLAGS as an environment variable the value of which is then added to the end of the CFLAGS (after all the other stuff) in config.nmake. So: I then set WIRESHARK_ENVIRONMENT_CFLAGS to /Od My experience has been that the last seen value for an option specified multiple times is the one that is used by the 'cl' command (at least for the options I've wanted to override). If this is considered useful (and not harmful), I can commit the config.nmake change. Bill ___ 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
Re: [Wireshark-dev] [Wireshark-announce] Wireshark 1.12.0rc3 is now available
On 07/27/14 13:34, Bálint Réczey wrote: 2014-07-25 23:49 GMT+02:00 Jeff Morriss jeff.morriss...@gmail.com: On 07/22/14 16:27, Wireshark announcements wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm proud to announce the release of Wireshark 1.12.0rc3. This is a public release candidate for Wireshark 1.12.0. Hmm, the source tarball isn't in the expected directory (rc2 is still there): http://wiresharkdownloads.riverbed.com/wireshark/src/ The all-versions directory does have it though. It also did not contain quite some files. Could release tarballs please be made using tools/git-export-release.sh? I had to use the tagged git-snapshot for the Debian packages. It worked well for me. What files were missing? I think changing to git-snapshot would be too significant a change this late in the game: it means a lot of the auto-generated files (like ./configure) would not be delivered, right? ___ 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
Re: [Wireshark-dev] O2 compile option makes it difficult to debug.
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Bill Meier Sent: den 28 juli 2014 15:24 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] O2 compile option makes it difficult to debug. Hi, It seems like the O2 option interferes with running the debugger. Would it be better to only use O2 on release builds? I'm not sure how to do that, add nmake -f makefile.nmake release option? What I've done is to alter config.nmake slightly to allow the specification of WIRESHARK_ENVIRONMENT_CFLAGS as an environment variable the value of which is then added to the end of the CFLAGS (after all the other stuff) in config.nmake. So: I then set WIRESHARK_ENVIRONMENT_CFLAGS to /Od My experience has been that the last seen value for an option specified multiple times is the one that is used by the 'cl' command (at least for the options I've wanted to override). If this is considered useful (and not harmful), I can commit the config.nmake change. Please upload it to gerrit, I think it would be useful. Bill ___ 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
[Wireshark-dev] switching to proto_tree_add_subtree()
Hi all, I'm sending out some unsorted thoughts, hoping that you can help me understand the issue I'm seeing. After the switch to proto_tree_add_subtree(), I found that some output of the DVB-CI dissector was different than before. Replacing ti = proto_tree_add_text(tree, tvb, offset, tvb_data_len, Resource ID: 0x%04x, res_id); res_tree = proto_item_add_subtree(ti, ett_dvbci_res); with res_tree = proto_tree_add_subtree_format(tree, tvb, offset, tvb_data_len, ett_dvbci_res, ti, Resource ID: 0x%04x, res_id); Does not give 100% identical behaviour. When tree!=NULL but not set to visible, ti will be !=NULL in the fist case and ==NULL after the change to proto_tree_add_subtree_format() I came across this in a function that does something like check if input is valid, return NULL on error create proto_item from the input create tree populate tree return proto_item The caller would then check the returned proto_item for NULL to see if the input could be processed. This started failing when proto_tree_add_subtree_format() is used. My gut feeling is that proto_tree_add_subtree_format() does the right thing and I should fix my dissector... However, I don't quite understand why for tree!=NULL but not visible, proto_tree_add_text() returns tree. I can see this in the code, we call TRY_TO_FAKE_THIS_ITEM(), which returns the tree itself when it's not visible. But what sense does this make for the caller? Best regards, Martin ___ 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
Re: [Wireshark-dev] [Wireshark-commits] master 31ecdf5: Refactor common Conversation table functionality.
On 07/26/14 16:59, Wireshark code review wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=31ecdf5b06bff3bb2e706e840c28c519698e6f67 Submitter: Gerald Combs (ger...@wireshark.org) Changed: branch: master Repository: wireshark Commits: 31ecdf5 by Michael Mann (mman...@netscape.net): Refactor common Conversation table functionality. Refactor (non-GUI) conversation table functionality from gtk/Qt to epan. Also refactor common GUI conversation table functionality. The idea is to not have to modify the GUI when a dissector adds a new conversation type Wow, nice work! ___ 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
Re: [Wireshark-dev] [Wireshark-commits] master 31ecdf5: Refactor common Conversation table functionality.
On Mon, Jul 28, 2014 at 06:17:37PM -0400, Jeff Morriss wrote: On 07/26/14 16:59, Wireshark code review wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=31ecdf5b06bff3bb2e706e840c28c519698e6f67 Submitter: Gerald Combs (ger...@wireshark.org) Changed: branch: master Repository: wireshark Commits: 31ecdf5 by Michael Mann (mman...@netscape.net): Refactor common Conversation table functionality. Refactor (non-GUI) conversation table functionality from gtk/Qt to epan. Also refactor common GUI conversation table functionality. The idea is to not have to modify the GUI when a dissector adds a new conversation type Wow, nice work! +2 -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ 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
Re: [Wireshark-dev] [Wireshark-commits] master 31ecdf5: Refactor common Conversation table functionality.
I think a lot of similar refactoring can be done in the area of statistics taps. The GUI layer for many of them is (or should be) fairly thin, mostly separated by number and types of columns. By using epan (and ui) directory as a middle layer, we can achieve more standard usage of statistic tap names across all GUIs. This will make migrating them to Qt easier, and will fill in some of the gaps left in TShark (where a few bugs have already been logged). Patches welcome! Ideally, I would like to see more statistical interfaces that can be GUI independent so the GUI can be more dynamic in its support of dissector functionality. The one thing about this architecture that I wasn't sure about was the notion of dissectors effectively registering taps to themselves. I think taps are the right mechanism, I have just always thought of them as being intentionally separated from the dissectors. On a related note, I took the common Conversation table functionality a step further and merged in the hostlist/endpoint functionality (https://code.wireshark.org/review/3214/). Since I don't know a lot about conversations/endpoints, does it make sense to separate the two (from a dissector/epan API standpoint) or combine them? Is it just a coincidence that the same dissectors that have conversations, also have endpoints? Or would it be possible for a dissector to have one without the other? Why is the tap name hosts for everything but TCP and UDP (which use endpoint). Should there be more consistency with the naming (with the risk of breaking backwards compatibility)? I myself have been confused with all of the naming used within the code itself, let alone what gets presented to the user. -Original Message- From: Jeff Morriss jeff.morriss...@gmail.com To: wireshark-dev wireshark-dev@wireshark.org Sent: Mon, Jul 28, 2014 6:19 pm Subject: Re: [Wireshark-dev] [Wireshark-commits] master 31ecdf5: Refactor common Conversation table functionality. On 07/26/14 16:59, Wireshark code review wrote: URL: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=31ecdf5b06bff3bb2e706e840c28c519698e6f67 Submitter: Gerald Combs (ger...@wireshark.org) Changed: branch: master Repository: wireshark Commits: 31ecdf5 by Michael Mann (mman...@netscape.net): Refactor common Conversation table functionality. Refactor (non-GUI) conversation table functionality from gtk/Qt to epan. Also refactor common GUI conversation table functionality. The idea is to not have to modify the GUI when a dissector adds a new conversation type Wow, nice work! ___ 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
