Re: Adventures with gcc: code vs object-code size
On Sun, Mar 21, 2004 at 02:20:13AM -0500, Matt Emmerton wrote: - Original Message - From: Garance A Drosihn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 20, 2004 5:45 PM Subject: Adventures with gcc: code vs object-code size if (strcmp(elemcopy, :) == 0) ... I don't know why the code bloats so much on i386, but I do question the use of strcmp() for a single-character compare. Something like the following would probably be better (and would avoid your problem): if (elemcopy[0] == ':') inf-count = 0; else inf-addelem(inf, elemcopy); That code isn't equivalent in general. Your code just checks that the first character is ':'. It doesn't verify that the string is exactly one character long. It's possible that in this particular context, elemcopy may be constrained such that it must be : if the first character is ':' but this isn't clear from Garances posting. The equivalent code would be: if (elemcopy[0] == ':' elemcopy[1] == '\0') inf-count = 0; else inf-addelem(inf, elemcopy); But (IMHO) this is a lot less clear than the former code (thought I admit I'm guilty of doing this quite a lot in my code). Note that a modern C compiler is free to convert strcpy(elemcopy, :) == 0 into elemcopy[0] == ':' elemcopy[1] == '\0' assuming the relevant header (string.h) is in scope. (I was under the impression that gcc did this). Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
On Sat, 20 Mar 2004, Garance A Drosihn wrote: I am not a compilier guru, so I suspect it would take me hours to pin this down. I don't want to do that, so I'm wondering if anyone understands how such a minor code-change can POSSIBLY cause such a huge change in resulting object file... I also wonder if this same issue pops up in other programs, too. I'm not a guru either, but I've seen a case where adding code (mostly switch clauses) caused a size reduction (on i386 anyway)... Depending on the optimisation level, it might be that the added code is affecting the heuristics gcc is using for inlined functions etc. -- Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
On Sun, Mar 21, 2004 at 07:45:43PM +1100, Peter Jeremy wrote: But (IMHO) this is a lot less clear than the former code (thought I admit I'm guilty of doing this quite a lot in my code). Note that a modern C compiler is free to convert strcpy(elemcopy, :) == 0 into elemcopy[0] == ':' elemcopy[1] == '\0' assuming the relevant header (string.h) is in scope. (I was under the impression that gcc did this). You're mixing up strcpy() with strcmp(), but you are right, unless -fno-builtin is specified. Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus_alloc_resource() returns NULL, but why?
In message: [EMAIL PROTECTED] thefly [EMAIL PROTECTED] writes: : but the problem is that bus_alloc_resource() returns NULL. I don't have : a clue about WHY it should. It's running on: FreeBSD 5.2.1-RELEASE with : GENERIC kernel in a dual pentium 200MMX. Maybe because the device is not on a self-identifying bus and therefore needs a hint (or possibly an identify rouitne). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
Date: Sat, 20 Mar 2004 17:45:04 -0500 From: Garance A Drosihn [EMAIL PROTECTED] Subject: Adventures with gcc: code vs object-code size To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii ; format=flowed I have written a fairly major set of changes to the `ps' command, which is available as: http://people.freebsd.org/~gad/ps-susv3.diff Debate/discussion about the changes themselves actual changes should be going on in the freebsd-standards mailing list. So for purposes of this mailing list, please ignore most of that. But while doing it, I was somewhat obsessed about making sure that my changes wouldn't cause a dramatic increase in the size of the executable for `ps'. Due to that, I tripped over one example of code vs object-code produced which makes no sense to me. So, consider just this section of the update (with some reformatting so it is easy to see the code): char elemcopy[PATH_MAX]; ...do stuff... #if !defined(ADD_PS_LISTRESET) inf-addelem(inf, elemcopy); #else /* * We now have a single element. Add it to the * list, unless the element is :. In that case, * reset the list so previous entries are ignored. */ if (strcmp(elemcopy, :) == 0) inf-count = 0; else inf-addelem(inf, elemcopy); #endif Now, here is what I noticed: * XXX - Adding this check increases the total size of `ps' by * 3940 bytes on i386! That's 12% of the entire program! * { using gcc (GCC) 3.3.3 [FreeBSD] 20031106 } * * When compiling for sparc, adding this option causes NO * change in the size of the `ps' executable. And on alpha, * adding this option adds only 8 bytes to the executable. So, by adding one call to strcmp() to check for a : string, I end up with /bin/ps (the stripped-object-file) which has grown by 12.6% !! This is for a program which is almost 2500 lines spread out over 5 '.c'-files. How is that possible? What am I missing here? In my coding experience (especially back in embedded-land when I cared a *lot* about code size) when this happens, the reason is usually nothing to do with the compiler per se, but with the packaging of library functions into modules. If it happens that strcmp was not previously being referenced at all, absent this one line, then of course this change will pull in the strcmp routine. Now while strcmp itself is not likely to be 3940 bytes, if it is packed together in the library with a number of other routines (e.g. a collection of hand-optimized assembler string routines, or of other routines which it's assumed are likely to be used in the same program) then the one module being pulled in can suddenly bloat the source surprisingly. This would be easy to test - extract the program's symbol table before stripping, with and without this one line, diff it, and see whether other new symbols are showing up along with strcmp. This may also be true even if gcc is partially inlining it - gcc may be pulling in a big clump of its own internal support routines in that case, on the assumption that when inlining you care only about speed and not about code size. Again, differencing the symbol table should give you some idea. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
At 10:22 AM -1000 3/21/04, Clifton Royston wrote: Date: Sat, 20 Mar 2004 From: Garance A Drosihn So, by adding one call to strcmp() to check for a : string, I end up with /bin/ps (the stripped-object-file) which has grown by 12.6% !! This is for a program which is almost 2500 lines spread out over 5 '.c'-files. How is that possible? What am I missing here? If it happens that strcmp was not previously being referenced at all, absent this one line, then of course this change will pull in the strcmp routine. Now while strcmp itself is not ... I forgot to include a significant part of this puzzle. The same ps.c file already had two calls to strcmp() in it: ps.c: if (strcmp(elem, co) == 0) ps.c: if (strcmp(elemcopy, :) == 0) ps.c: if (strcmp(vent-var-name, v-name) == 0) There was no strcmp() in the subroutine that I added it to, but I would assume that those other references would have already pulled in the routine. This may also be true even if gcc is partially inlining it. gcc may be pulling in a big clump of its own internal support routines in that case, ... but would it inline it's own routines multiple times in the same source file? Again, differencing the symbol table should give you some idea. Well, I was hoping someone would have already seen this before, but I guess I will need to do some more checking if I'm going to get a better idea of what is going on. I'll put it on my list of things to look at when I have some spare time... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
The heuristics vary from platform to platform - what does objdump -d show? -Kip Well, I was hoping someone would have already seen this before, but I guess I will need to do some more checking if I'm going to get a better idea of what is going on. I'll put it on my list of things to look at when I have some spare time... -- If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
At 2:52 PM -0800 3/21/04, Kip Macy wrote: The heuristics vary from platform to platform - what does objdump -d show? Based on what I see from that, the 'ps.o' which has the extra strcmp is about 40 bytes larger than the one without it. And now that you mention it, doing a plain 'ls -l' of ps.o shows that it is only 40 bytes larger. It's when you combine that file with the other *.o files, and strip it, that the final result ends up 3940 bytes larger. So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adventures with gcc: code vs object-code size
From: Garance A Drosihn [mailto:[EMAIL PROTECTED] At 2:52 PM -0800 3/21/04, Kip Macy wrote: The heuristics vary from platform to platform - what does objdump -d show? Based on what I see from that, the 'ps.o' which has the extra strcmp is about 40 bytes larger than the one without it. And now that you mention it, doing a plain 'ls -l' of ps.o shows that it is only 40 bytes larger. It's when you combine that file with the other *.o files, and strip it, that the final result ends up 3940 bytes larger. So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... Its not just bumping you up another module 4K pages? The linker aligns text, data, bss, rodata, etc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adventures with gcc: code vs object-code size
At 7:35 PM -0500 3/21/04, Don Bowman wrote: From: Garance A Drosihn [mailto:[EMAIL PROTECTED] So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... It's not just bumping you up another module 4K pages? The linker aligns text, data, bss, rodata, etc. (65) ls -l /bin/ps* -r-xr-xr-x 1 root wheel 27100 Mar 20 14:29 /bin/ps -r-xr-xr-x 1 root wheel 27296 Mar 21 18:21 /bin/ps-sanscmp -r-xr-xr-x 1 root wheel 31204 Mar 21 19:46 /bin/ps-withcmp The first one is the `ps' before all of my recent changes, the second is all of the changes except for that strcmp(), and the third adds the strcmp. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adventures with gcc: code vs object-code size
From: Garance A Drosihn [mailto:[EMAIL PROTECTED] At 7:35 PM -0500 3/21/04, Don Bowman wrote: From: Garance A Drosihn [mailto:[EMAIL PROTECTED] So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... It's not just bumping you up another module 4K pages? The linker aligns text, data, bss, rodata, etc. (65) ls -l /bin/ps* -r-xr-xr-x 1 root wheel 27100 Mar 20 14:29 /bin/ps -r-xr-xr-x 1 root wheel 27296 Mar 21 18:21 /bin/ps-sanscmp -r-xr-xr-x 1 root wheel 31204 Mar 21 19:46 /bin/ps-withcmp The first one is the `ps' before all of my recent changes, the second is all of the changes except for that strcmp(), and the third adds the strcmp. and objdump --headers shows? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
On Sun, Mar 21, 2004 at 05:39:58PM -0500, Garance A Drosihn wrote: At 10:22 AM -1000 3/21/04, Clifton Royston wrote: Date: Sat, 20 Mar 2004 From: Garance A Drosihn So, by adding one call to strcmp() to check for a : string, I end up with /bin/ps (the stripped-object-file) which has grown by 12.6% !! This is for a program which is almost 2500 lines spread out over 5 '.c'-files. How is that possible? What am I missing here? If it happens that strcmp was not previously being referenced at all, absent this one line, then of course this change will pull in the strcmp routine. Now while strcmp itself is not ... I forgot to include a significant part of this puzzle. The same ps.c file already had two calls to strcmp() in it: ps.c: if (strcmp(elem, co) == 0) ps.c: if (strcmp(elemcopy, :) == 0) ps.c: if (strcmp(vent-var-name, v-name) == 0) There was no strcmp() in the subroutine that I added it to, but I would assume that those other references would have already pulled in the routine. Ah, totally different story then. OK, I'm baffled too. This may also be true even if gcc is partially inlining it. gcc may be pulling in a big clump of its own internal support routines in that case, ... but would it inline it's own routines multiple times in the same source file? No, it definitely shouldn't. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Diagnosing unrecognized hardware
Hello, I'm running FreeBSD 5.2.1-RELEASE on an HP OmniBook 4150 laptop. I have a D-Link DWL-650 802.11b wireless ethernet card that doesn't seem to be recognized. I have built a kernel with the wi and wlan drivers: devicewlan devicewi Relevant boot messages: cbb0: TI1225 PCI-CardBus Bridge at device 4.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 pci_cfgintr: 0:4 INTA routed to irq 10 cbb0: [MPSAFE] cbb1: TI1225 PCI-CardBus Bridge at device 4.1 on pci0 cardbus0: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 pci_cfgintr: 0:4 INTB routed to irq 10 cbb1: [MPSAFE] My question is, how do I diagnose the problem? When the card is inserted, the following is logged to the console: pccard0: unknown card (manufacturer=0x000b, product=0x7110) at function 0 pccard0:CIS info: D-Link, DWL-650 Wireless PC Card RevP, ISL37101P-10 However, running ifconfig -a does not show a wi interface. I can send more dmesg output and additional information tomorrow (I hand- typed the above messages). I just thought it might be something obvious that I'm missing. According to wi(4), the DWL-650 card is supported. What do I need to do to get it to work? Thanks, -brian __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]