From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107407 invoked by alias); 17 Mar 2015 08:57:14 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 107395 invoked by uid 89); 17 Mar 2015 08:57:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_50,KAM_STOCKGEN autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Mar 2015 08:57:11 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id DD23EA807C9; Tue, 17 Mar 2015 09:57:08 +0100 (CET) Date: Tue, 17 Mar 2015 08:57:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: backtrace(3) in Cygwin Message-ID: <20150317085708.GA20267@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <5505E2DA.6090806@tiscali.co.uk> <20150316100713.GF6096@calimero.vinschen.de> <55075780.9010505@tiscali.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <55075780.9010505@tiscali.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-03/txt/msg00008.txt.bz2 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 7149 Hi David, On Mar 16 22:21, David Stacey wrote: > On 16/03/15 10:07, Corinna Vinschen wrote: > >Unfortunately there are some preliminaries before I can take a closer > >look, namely the copyright assignment we need from everybody who's > >providing more than just trivial patches to Cygwin, see > >https://cygwin.com/contrib.html, the "Before you get started" section. > >Fill out https://cygwin.com/assign.txt and send it to the address given > >in the pamphlet. If you're writing code for Cygwin only in your spare > >time, forget the part about your employer. >=20 > I'm hoping that this won't be a problem. I'm more than happy to assign my > own copyright to Red Hat. My employer has no claim to work I do in my own > time on my own equipment. However, Cygwin might be a grey area, as we use > Cygwin extensively in our development work. So I've already asked my > employer to sign the copyright and patent waiver. Assuming this is signed, > I'll send both parts together. >=20 > So let's proceed assuming that this is going to happen. Cool, thanks. However, it doesn't depend on how and where you use Cygwin, it depends on how and where you hack on Cygwin. Not Cygwin packages, not python scripts running under Cygwin, just Cygwin itself as it's stored in the git repo. Even minus newlib due to the different licensing situation. > >But submissions almost always have to jump a couple of hurdles > >(i.e., see how many iterations some patches need to make it into the > >official Linux kernel) , so I'm asking for your patience in return, ok? >=20 > Submitting code to the Linux kernel also involves one of us ranting and > shouting obscenities, but hopefully we don't have to emulate Linux that > closely ;-) I don't think I can emulate Linus for any length of time, really :} > >* While you're already providing code, I'm missing a bit of discussion > > first. You didn't respond to > > https://cygwin.com/ml/cygwin/2015-03/msg00206.html at all. > > > > Of course, it's ideally discussed on cygwin-developers anyway, but a > > discussion should ideally preceed a code submission :} >=20 > Sorry - that's my fault for not understanding. The code I posted was in no > way a finished item; it was just to get the discussion started. I kind of thought so. More or less. > And I wasn't > trying to avoid a discussion - in fact quite the opposite. Talking about > code is *so* much more interesting when there's actual code to talk about= ! I > simply presented one way in which it /might/ work, but... >=20 > > My main point: Only *one* implementation of the stack walk code, > > not one for generating stackdumps and one for implementing backtrace(= 3). > > > > That doesn't mean we have to stick to the current stack_info class in > > exceptions.cc, but it's certainly still a good idea to implement the > > entire stack walking stuff in a class which allows usage from both > > places. >=20 > ... it sounds like you have an idea of how you'd like this implemented - = and > that's fine. This is your project, so I'll keep reworking the code until > we're both happy. I haven't had chance to look at the code you mentioned > yet, but I will. I'm rather busy this week, so it might be a while before= I > come back to you. No worries. I don't have a fixed idea in mind, it's just that we're using C++ anyway, and since we need the stack trace in more than one place, the underlying implementation for both, the stackdump and the backtrace(3) facility, should be a single piece of code or class. > >* Your coding style doesn't match the GNU coding style, >=20 > That's OK. I've been long enough in the coding game that I can write code= in > anybody's style. Now I know what you want, future code will adhere to the > GNU standard (hopefully). A couple of questions not covered in the standa= rd: >=20 > - I assume from the examples that indentation is two spaces (I didn't s= ee > this stated explicitly). And I assume that you always use spaces and never > tab characters; Not quite. In vi terms, sw=3D2,ts=3D8. Max line length 80. > - in comments, do you prefer English spellings or their American > equivalents? Yes. ;) > >Don't use assert here. Generate an error instead. >=20 > Please could you point me at an example of error reporting elsewhere in t= he > Cygwin code so I can see how you'd like that doing. What I meant was, just do the usual error action for backtrace. AFAICS, there's only a NULL value returned without declaration of setting errno or something. As for debug output, grep for, e.g. debug_printf, syscall_printf, etc.=20 This is an internal implementation using slightly different format characters, see smallprint.cc line 95ff. There were fixed rules for when using when at one point, but these days it's been used a bit arbitrarily in some places. Just use common sense. > >>/* backtrace_symbols_fd() takes the same buffer and size arguments as > >> * backtrace_symbols(), but instead of returning an array of strings t= o the > >> * caller, it writes the strings, one per line, to the file descriptor= fd. > >> * backtrace_symbols_fd() does not call malloc(3), and so can be emplo= yed in > >> * situations where the latter function might fail. > >> */ > >>void backtrace_symbols_fd(void *const *buffer, int size, int fd) > >>{ > >> /* A Cygwin implementation of backtrace_symbols_fd(3) is going to = be > >> * somewhat problematic and will demand a compromise at some point= along > >> * the way. The problem is how to allocate memory for the SYMBOL_I= NFO > >> * structure, given that we're not supposed to use heap memory. Wi= ndows > >> * defines MAX_SYM_NAME as 2000 characters, and clearly we shouldn= 't go > >> * trying to allocate that much memory on the stack. > >This is Windows. What you can do to make sure not to use any existing > >heap is this: Create your own Windows heap and use this exclusively > >from the C++ class implementing the stack walk. If creating the heap > >fails, we're screwed, but otherwise you can allocate memory from a > >pristine heap not related to other stuff in the application. >=20 > I've done a little investigation, and it seems that the stack size on Cyg= win > is much larger than I thought. For the main thread 2 Megs, for other threads 1 Meg by default. However, you don't know what's left. The thread you're called from could be low on stack already. > So I should be able to allocate a couple of > 2k buffers on the stack without any problem. Coverity (for instance) will > only start grumbling about excessive stack use once a function has used 1= 0k. > However, if I use your existing stack walker class then > backtrace_symbols_fd(3) will be implemented differently anyway. >=20 > Thank you for your feedback, and apologies once again for any > misunderstanding. No apologies necessary, not at all! I'm happy to discuss this stuff further. It's always nice to have somebody else hacking on Cygwin. Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVB+xkAAoJEPU2Bp2uRE+gsWwP/0vndT764lAWTSDPE6t5AH0Z Djmo4GzOmFNliTxrqcBqXjpRalsrnTRQj00ibc3/ddkOygUqjPCAvIvF7to447ZG r9/C8drXXxogjdy5bdSaLW80qVr2uhmpWEYml9coiu618M2QJVVMuGOtGZ3V2/Ro 9oPyXSv/vkHfYiaM3V3ALCXDD17v7UvzT7xeMKmTawcKRPGsMy2/ual7ofF+TWqz 8iFdTnjf7zuKNwxnjW3DYl1Z4spZZSqBz6ZPQRw9K1I2f1QSbpr3gvASexITqnhn RvI42XO5/T04U5rMXvphWCoQN+Frz4iCzFtlKzM+dR1tEL3kZ2g8GPKCwNSVRUP5 QHYvku3cZqexRqeO2Fvjw11lvniXtW2goJXeYySUnN3td5NSYsdwKCX6P0Mm7diu VSiZZ/tbV33qW9zIw39givpAMQwEpBPyZx+XRyjXT+2Oq1dygTRUW2A6aXcJT4qQ XpTVaIa/H7WmP86Uw4KY4+awhCS+tmiJvPGsaI+S9bfzLrLse6m1PnElbKgWBOsn iLi2c3dSrEZYd/GDsGbHKE7MW5W5+3ghLPBZzM4fVM+cbt5UMWIAdGjq4GjFiovi emgvIJMvBCz2M29652oQiEAz3i4UlZMMwIPl+h+yuT67ubzpI458VGtW54jPXpd/ ybBxx8I2Fm7DL6AsQWa5 =UdJ0 -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc--