[Bug cli/24124] Command `b *804874e` sets breakpoint at 0xc480a - hex value of 804874

[Bug cli/24124] Command `b *804874e` sets breakpoint at 0xc480a - hex value of 804874

[lienze at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24124

Enze Li <lienze at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lienze at sourceware dot org

--- Comment #2 from Enze Li <lienze at sourceware dot org> ---
(In reply to Tom Tromey from comment #1)
> This is a funny one!  "804874e" is being parsed as a floating-point number,
> which is why it works and "d" or "f" do not.
> 
> Arguably "break *" should reject floating point numbers as being a
> weird way to write an address.

Hi Tom,

I am trying to solve this problem.

"804874e" is parsed as a floating point number because "en" stands for "10^n". 
If there is no decimal number after "e", "e" will be ignored.  "d" and "f" are
not as special as "e", that is why breakpoint address with a "d" or "f" are
recognized as illegal.  This is my understanding.

In GDB, do users usually use decimal numbers to define the address of
breakpoints?  Or, if only hexadecimal numbers are used to set the breakpoint
address, how about we restrict the value of the address to start with 0x?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/24124] Command `b *804874e` sets breakpoint at 0xc480a - hex value of 804874

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24124

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Enze Li from comment #2)

> "804874e" is parsed as a floating point number because "en" stands for
> "10^n".  If there is no decimal number after "e", "e" will be ignored.  "d"
> and "f" are not as special as "e", that is why breakpoint address with a "d"
> or "f" are recognized as illegal.  This is my understanding.

I think gdb's lexing here is weird, because it disagrees with C:

prentzel. gcc --syntax-only q.c
q.c:1:11: error: exponent has no digits
    1 | float x = 80e;
      |           ^~~

(gdb) print 80e
$1 = 80
(gdb) ptype 80e
type = double

So not treating this as floating point (and rejecting the parse)
might be fine.

> In GDB, do users usually use decimal numbers to define the address of
> breakpoints?

No but nothing prohibits it.

> Or, if only hexadecimal numbers are used to set the breakpoint
> address, how about we restrict the value of the address to start with 0x?

That's harder than it sounds because the text after the "*" is an
arbitrary expression, not just an integer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/24124] Command `b *804874e` sets breakpoint at 0xc480a - hex value of 804874

[lienze at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24124

--- Comment #4 from Enze Li <lienze at sourceware dot org> ---
(In reply to Tom Tromey from comment #3)
> (In reply to Enze Li from comment #2)
> 
> > "804874e" is parsed as a floating point number because "en" stands for
> > "10^n".  If there is no decimal number after "e", "e" will be ignored.  "d"
> > and "f" are not as special as "e", that is why breakpoint address with a "d"
> > or "f" are recognized as illegal.  This is my understanding.
> 
> I think gdb's lexing here is weird, because it disagrees with C:
> 
> prentzel. gcc --syntax-only q.c
> q.c:1:11: error: exponent has no digits
>     1 | float x = 80e;
>       |           ^~~
> 
> (gdb) print 80e
> $1 = 80
> (gdb) ptype 80e
> type = double
> 
> So not treating this as floating point (and rejecting the parse)
> might be fine.
> 
> > In GDB, do users usually use decimal numbers to define the address of
> > breakpoints?
> 
> No but nothing prohibits it.
> 
> > Or, if only hexadecimal numbers are used to set the breakpoint
> > address, how about we restrict the value of the address to start with 0x?
> 
> That's harder than it sounds because the text after the "*" is an
> arbitrary expression, not just an integer.

Hi Tom,

Thanks for your reply.

I have a proposed patch.  FTR, I've posted here[1]. 

[1] https://sourceware.org/pipermail/gdb-patches/2022-September/191680.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.