[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: I HATE OPTIMISING COMPILERS
From:       grog () lemis ! de (Greg Lehey)
Date:       1996-05-30 8:03:21
[Download RAW message or body]

Gary Palmer writes:
>
> Greg Lehey wrote in message ID
> <199605291652.SAA24396@allegro.lemis.de>:
>> At this point, of course, our mileage varies.  Here, you would get the
>> result:
>
>> + (gdb) p pdu->version
>> + $3 = -1
>
> Sorry, BZZZZZZZT

Thank you.  I needed that.

> The actual program, producing the actual results:
>
> gdb apps/snmpwalk
> GDB is free software and you are welcome to distribute copies of it
>  under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.13 (i386-unknown-freebsd),
> Copyright 1994 Free Software Foundation, Inc...
> (gdb) break snmp_api.c:1006

You can abbreviate these commands, you know.

> Breakpoint 1 at 0x96df: file snmp_api.c, line 1006.
> (gdb) run -v 1 localhost public
> Starting program: /mnt/root/usr/home/gary/ftp/ucd-snmp-3.1/apps/snmpwalk -v 1 localhost public
>
> Breakpoint 1, snmp_send (session=0x65100, pdu=0x65180) at snmp_api.c:1007
> 1007        if (pdu->version == SNMP_DEFAULT_VERSION){
> (gdb) print pdu->version
> $1 = -1
> (gdb) print session->version
> $2 = 0

I no longer have your original message, but I thought it said this
variable had the value 2.

> (gdb) break 1009
> Breakpoint 2 at 0x96ef: file snmp_api.c, line 1009.
> (gdb) cont
> Continuing.
>
> Breakpoint 2, snmp_send (session=0x65100, pdu=0x65180) at snmp_api.c:1010
> 1010        if (pdu->version == SNMP_DEFAULT_VERSION){
> (gdb) print pdu->version
> $3 = 0
> (gdb) print session->version
> $4 = 0
> (gdb) s
> 1011            fprintf(stderr, "No version specified\n");
> (gdb)
> 1013            return 0;
> (gdb)
> No version specified
> 1068                    snmp_errno = SNMPERR_BAD_ADDRESS;
>
> So, you see, GDB says that pdu->version does NOT equal
> SNMP_DEFAULT_VERSION. I guess it would have tracked down the problem
> quicker, but I STILL don't like gdb :-)

You have the choice.  If you choose to waste time, that's up to you.
FWIW, I don't think too much of gdb either, but it's there, and it
beats the hell out of printf.  I just don't understand what you're
trying to say in this example.  I said that the real thing would be
different.

The problem here is, of course, that gdb is going by line numbers, and
the optimizer has rearranged things.  It would have been instructive
to single-step through these instructions (with 'n(ext)', not
's(tep)') to show where gdb thinks it was going.

> I guess it comes from a time when I tried (and NEARLY suceeded) in
> porting the FreeBSD kernel to another machine ... printf was all I had
>: -)

I would have ported a debugger first.

>> I'd do this differently in gdb.  Personally, I'd look at the code that
>> was generated.  Your code won't look like this, of course, because
>> this code works.  But you can see a few things:
>
> Only if you read 80x86, which I don't, and probably never will. I've
> been corrupted by a RISC processor, and hope never to have to touch a
> CISC assembler ever again :-) I know (or used to) 6502 and 68000, and
> that's plenty CISC to last enough a lifetime :-)

Hmm.  Depends on the RISC processor.

>> Reading assembler is tough, of course, but there are other ways.  In
>> any case, you save a lot by doing it this way rather than going and
>> editing and recompiling possibly dozens of times.
>
> Hmm. Maybe. Call me stoopid, but I still like my printf's thankyou :-)

Your choice.

Greg

[prev in list] [next in list] [prev in thread] [next in thread]