FAQ
This trivial patch convinces gdb to display the enum opcode symbol
for the op_type, where it formerly showed a (obfuscated) number.

(gdb) p *o
$1 = {op_next = 0x8c9c668, op_sibling = 0x8c9c668,
op_ppaddr = 0x80d5f50 <Perl_pp_enter>, op_targ = 0, op_type = OP_ENTER,
op_opt = 0, op_latefree = 0, op_latefreed = 0, op_attached = 0,
op_spare = 0, op_flags = 0 '\0', op_private = 0 '\0'}
(gdb)

(gdb) p o->op_type
$2 = OP_ENTER
(gdb) p o->op_ppaddr
$3 = (OP *(*)(PerlInterpreter *)) 0x80d5f50 <Perl_pp_enter>
(gdb) p PL_op_name[o->op_type]
$4 = 0x825c401 "enter"
(gdb) p PL_op_desc[o->op_type]
$5 = 0x825cfc5 "block entry"

I suppose one could argue that op_ppaddr also shows the op-type
in the pp-function, and that the extra info is unneeded,
but its easy to imagine it being helpful - and the UPPERCASE
catches the eye.

Given that an enum is an int, I dont anticipate problems with CPAN
modules, though I havent tried any.

passes all tests on threaded build

<tangent> are there any pp-funcs that service multiple op-types ?

Search Discussions

  • Rafael Garcia-Suarez at Oct 1, 2007 at 12:58 pm

    On 28/09/2007, Jim Cromie wrote:
    This trivial patch convinces gdb to display the enum opcode symbol
    for the op_type, where it formerly showed a (obfuscated) number. ...
    Given that an enum is an int, I dont anticipate problems with CPAN
    modules, though I havent tried any.
    But I can anticipate problems with non-gcc compilers, regarding the
    support for enum names in bitfield structures (instead of the more
    common "unsigned" and "int".)

    Also, might this interfere with -DDEBUGGING_OPS ? And what is
    DEBUGGING_OPS anyway ? hasn't it become obsolete when the op_type
    became a bit field ?
  • Paul Johnson at Oct 1, 2007 at 1:50 pm

    On Mon, Oct 01, 2007 at 02:58:21PM +0200, Rafael Garcia-Suarez wrote:

    Also, might this interfere with -DDEBUGGING_OPS ? And what is
    DEBUGGING_OPS anyway ? hasn't it become obsolete when the op_type
    became a bit field ?
    That's quite possible. I didn't really understand the need for DEBUGGING_OPS
    when I wrote that so I didn't mess with it.

    Does anyone use it? I have never done so. Cursory investigation suggests
    that it was last hacked on by Spider Boardman about eight years ago. But it
    seems to compile and pass all tests anyway.

    PS I can't find any trace of the old perlcabal site.

    --
    Paul Johnson - paul@pjcj.net
    http://www.pjcj.net
  • Jim Cromie at Oct 1, 2007 at 6:11 pm

    Rafael Garcia-Suarez wrote:
    On 28/09/2007, Jim Cromie wrote:

    This trivial patch convinces gdb to display the enum opcode symbol
    for the op_type, where it formerly showed a (obfuscated) number. ...
    Given that an enum is an int, I dont anticipate problems with CPAN
    modules, though I havent tried any.
    But I can anticipate problems with non-gcc compilers, regarding the
    support for enum names in bitfield structures (instead of the more
    common "unsigned" and "int".)
    I'll ack that I don't have any other compilers, and am not sensitive to
    the portability issues with enums and bitfields (or many other such
    issues ;-)
    Also, might this interfere with -DDEBUGGING_OPS ? And what is
    DEBUGGING_OPS anyway ? hasn't it become obsolete when the op_type
    became a bit field ?
    It sure looks obsolete.
    blead, maint have but 1 occurrence, in op.h
    perlbrowse shows it to be from rev1, but doesnt show patch 1
    I pulled perl5.005_04, it also has but 1 occurrence.

    BTW, I recall that someone's got legacy perls on-line somewhere,
    perhaps a link should be added to perlhist.pod ?


    So attached patch kills it (along with commented out mention in
    win32/Makefile.ce
    I find it somewhat amusing that OPCODE (which is used in a number of files)
    is #defined as 'opcode' (the typedef of enum opcode in opnames.h)
    It debatable whether cleaning that tiny bit of cruft is worthwhile - I
    didnt do it.

    your call (as ever) whether this is 'icy' enough.
  • Paul Johnson at Oct 1, 2007 at 9:27 pm

    On Mon, Oct 01, 2007 at 12:02:02PM -0600, Jim Cromie wrote:

    Also, might this interfere with -DDEBUGGING_OPS ? And what is
    DEBUGGING_OPS anyway ? hasn't it become obsolete when the op_type
    became a bit field ?
    It sure looks obsolete.
    blead, maint have but 1 occurrence, in op.h
    perlbrowse shows it to be from rev1, but doesnt show patch 1
    I pulled perl5.005_04, it also has but 1 occurrence.

    So attached patch kills it (along with commented out mention in
    win32/Makefile.ce
    I find it somewhat amusing that OPCODE (which is used in a number of files)
    is #defined as 'opcode' (the typedef of enum opcode in opnames.h)
    It debatable whether cleaning that tiny bit of cruft is worthwhile - I
    didnt do it.

    your call (as ever) whether this is 'icy' enough.
    diff -ruNp -X exclude-diffs ../bleadperl/op.h no-dbg-ops/op.h
    --- ../bleadperl/op.h 2007-09-20 13:36:23.000000000 -0600
    +++ no-dbg-ops/op.h 2007-10-01 11:50:30.000000000 -0600
    @@ -37,11 +37,7 @@
    * which may or may not check number of children).
    */

    -#ifdef DEBUGGING_OPS
    #define OPCODE opcode
    -#else
    -#define OPCODE U16
    -#endif
    Hold on. Isn't this backwards? We want the U16 rather than the opcode enum
    which is probably twice the size.

    --
    Paul Johnson - paul@pjcj.net
    http://www.pjcj.net
  • Jim Cromie at Oct 2, 2007 at 1:08 am

    Paul Johnson wrote:
    On Mon, Oct 01, 2007 at 12:02:02PM -0600, Jim Cromie wrote:

    diff -ruNp -X exclude-diffs ../bleadperl/op.h no-dbg-ops/op.h
    --- ../bleadperl/op.h 2007-09-20 13:36:23.000000000 -0600
    +++ no-dbg-ops/op.h 2007-10-01 11:50:30.000000000 -0600
    @@ -37,11 +37,7 @@
    * which may or may not check number of children).
    */

    -#ifdef DEBUGGING_OPS
    #define OPCODE opcode
    -#else
    -#define OPCODE U16
    -#endif
    Hold on. Isn't this backwards? We want the U16 rather than the opcode enum
    which is probably twice the size.
    OOPS - mea culpa - Corrected patch attached.
    BTW, both versions pass all tests on threaded



    As penance (and out of curiosity) I took a look at the respective op.o
    objects

    the correct version is ~120 bytes smaller (x86)
    -rw-rw-r-- 1 jimc jimc 352872 Oct 1 16:32 ../no-dbg-ops-enum/op.o
    -rw-rw-r-- 1 jimc jimc 343756 Oct 1 16:07 ../no-dbg-ops/op.o

    nm -S shows a few differences ( ex: Perl_bind_match )
    and a different starting address for Perl_allocmy
    ( due to the static functions up front, as shown by objdump )


    U PL_thr_key (
    U PerlIO_printf (
    U Perl_PerlIO_stderr (
    000163b0 000002ea T Perl_allocmy | 00016380 000002ea T
    Perl_allocmy
    00007cd0 00000088 T Perl_append_elem | 00007c90 00000088 T
    Perl_append_elem
    00007d60 0000009c T Perl_append_list | 00007d20 0000009c T
    Perl_append_list
    0000e370 000001eb T Perl_apply_attrs_string | 0000e340 000001eb T
    Perl_apply_attrs_string
    U Perl_av_create_and_push (
    U Perl_av_create_and_unshift_one (
    U Perl_av_fetch (
    U Perl_av_len (
    U Perl_av_pop (
    U Perl_av_push (
    0000c2a0 000002de T Perl_bind_match | 0000c270 000002d2 T
    Perl_bind_match
    00008130 00000074 T Perl_block_end | 000080f0 00000074 T
    Perl_block_end
    ...
  • Rafael Garcia-Suarez at Oct 2, 2007 at 12:00 pm

    On 02/10/2007, Jim Cromie wrote:
    OOPS - mea culpa - Corrected patch attached.
    BTW, both versions pass all tests on threaded
    Thanks, applied.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedSep 28, '07 at 5:23p
activeOct 2, '07 at 12:00p
posts7
users3
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase