Objdump pop (8f opcode) misrepresentation? or "Objdump's trying too hard"

[gdb guy]

I ran objdump 2.17 on ls on a Debian 4 system, because I was looking
for a form of pop which I had never knew existed, namely the 0x8f
opcode form.

>From the intel spec:
8F /0           POP r/m32          N.E.  Valid        Pop top of stack
into m32; increment stack pointer.(Vol 2B page 4-130)

Now, the /0 I interpret from Vol 2A page 3-2
/digit — A digit between 0 and 7 indicates that the ModR/M byte of the
instruction uses only the r/m (register or memory) operand. The reg
field contains the digit that provides an extension to the
instruction's opcode.

which in this case, since it's /0 would mean it's all the various
forms which deal with eax on Vol 2A page 2-7.

So this makes sense to me:
8048984:       8f 00                   popl   (%eax)

But this does not:
80593f0:       8f ec                   pop    %esp
because that's not R/M = 0.

I know that this is just objdump trying to disassemble data, but
shouldn't it just say "(bad)", rather than printing out an instruction
which can't exist?

Thanks

Gary Guy