>
> I'm having a hard time debugging some virtual machine code because GDB
> won't break where it's supposed to.
>
A quick follow-up. The GDB folks were able to reproduce this in an XUbuntu
20.04 VM. I don't know if they tried straight Ubuntu, but as the main
difference between the two is the
On Tue, May 25, 2021 at 7:42 PM Inada Naoki wrote:
> On Tue, May 25, 2021 at 5:38 AM Guido van Rossum wrote:
> >
> > To the contrary, I think if you want the CI jobs to be faster you should
> add the CFLAGS to the configure call used to run the CI jobs.
> >
>
> -Og makes it faster not only CI
On Tue, May 25, 2021 at 7:49 PM Inada Naoki wrote:
> On Tue, May 25, 2021 at 5:38 AM Guido van Rossum wrote:
> >
> > To the contrary, I think if you want the CI jobs to be faster you should
> add the CFLAGS to the configure call used to run the CI jobs.
> >
>
> -Og makes it faster not only CI
On Tue, May 25, 2021 at 5:38 AM Guido van Rossum wrote:
>
> To the contrary, I think if you want the CI jobs to be faster you should add
> the CFLAGS to the configure call used to run the CI jobs.
>
-Og makes it faster not only CI jobs, but also everyday "edit code and
run `make test` with all
On 5/24/2021 9:38 PM, Guido van Rossum wrote:
To the contrary, I think if you want the CI jobs to be faster you should
add the CFLAGS to the configure call used to run the CI jobs.
Big +1
We should have the most useful interactive development/debugging options
set by default (or with an
me> I'm having a hard time debugging some virtual machine code because GDB
won't break where it's supposed to.
Here's a quick follow-up. I tried a number of different values of OPT
during configuration and compilation, but nothing changed the result. I
could never (and still can't) get GDB to
To the contrary, I think if you want the CI jobs to be faster you should
add the CFLAGS to the configure call used to run the CI jobs.
On Mon, May 24, 2021 at 1:30 PM Victor Stinner wrote:
> --with-pydebug default compiler flags is a trade-off between "runtime
> checks for debug" and
--with-pydebug default compiler flags is a trade-off between "runtime
checks for debug" and performance. -O0 makes Python slower. For
example, we want to Python CI to run as fast as possible.
I don't want to fight for https://bugs.python.org/issue38350 I simply
learnt to type: ./configure
I'm confused. I've always assumed that --with-pydebug was intended for the
situation where you're modifying the C code, so obviously you might have to
debug C code. (I know that was the case when we introduced it, decades
ago.) If that's not the goal, then what is --py-debug used for?
On Mon, May
"Debugging" means many things. Python is built with -Og because it
makes Python faster than -O0, and most developers debug Python code,
not C code (in gdb).
If you don't need to go up to the gdb/lldb level, -Og is fine.
It would even make sense to build Python with -O3 in debug mode if you
don't
> Just turn off optimisation when you want to single-step.
But I don't just want to single-step. I want to break at the target
label associated with a specific opcode. (I am - in fits and starts -
working on register-based virtual machine instructions). If I'm
working on, for example, the
On 2021-05-23 14:56, Skip Montanaro wrote:
I strongly suggest to only build Python with -O0 when using gdb. -Og
enables too many optimizations which makes gdb less usable.
Thanks, Victor. It never made sense to me that you would want any
optimizations enabled when truly debugging code (as
> I strongly suggest to only build Python with -O0 when using gdb. -Og
> enables too many optimizations which makes gdb less usable.
Thanks, Victor. It never made sense to me that you would want any
optimizations enabled when truly debugging code (as opposed to wanting
debug symbols and a sane
I strongly suggest to only build Python with -O0 when using gdb. -Og
enables too many optimizations which makes gdb less usable.
Victor
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
Huh, you're right, I forgot that Py_LOCAL_AGGRESSIVE is specific to MSVC
(maybe it wasn't always).
I can think of nothing else apart from a gcc or gdb bug. Oh, hm, maybe
computed gotos play havoc with the labels???
On Fri, May 21, 2021 at 2:01 PM Skip Montanaro
wrote:
>
>
> On Fri, May 21,
On Fri, May 21, 2021 at 2:48 PM Guido van Rossum wrote:
> I suspect that you're running into the issue where compiler optimizations
> are *forced* on for ceval.c.
>
> There's a comment near the top about this. Just comment out this line:
>
> #define PY_LOCAL_AGGRESSIVE
>
> We tried to define
I suspect that you're running into the issue where compiler optimizations
are *forced* on for ceval.c.
There's a comment near the top about this. Just comment out this line:
#define PY_LOCAL_AGGRESSIVE
We tried to define that macro conditionally, but something broke because
the C stack frame
17 matches
Mail list logo
