(BUG) Inline assembly/breakpoints in lcc

[Chris Peters]

Hello Group

Can anyone confirm or suggest workrounds for the following bug in
lccwin32. If an inline assembly statement immediately follows a for loop
and you try to set a breakpoint on it, then the breakpoint is hit at each
iteration of the loop, not after the loop finishes.

Thanks

Chris

[jacob navia]

Chris Peters wrote:

Hello Group

Can anyone confirm or suggest workrounds for the following bug in
lccwin32. If an inline assembly statement immediately follows a for loop
and you try to set a breakpoint on it, then the breakpoint is hit at each
iteration of the loop, not after the loop finishes.

Thanks

Chris

The compiler does NOT emit any debug info when using
inline assembly. That is why the debugger get's confused.

One workaround is to write
_asm("int\t$3") ;
and you will get a breakpoint without any ambiguity.

The problem of not emitting debug info for inline
assembly is an old one. Fixing it would take a lot
of effort.

Soryy about this problem.

jacob

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Mark McIntyre]

Chris Peters wrote:

Hello Group

Can anyone confirm or suggest workrounds for the following bug in
lccwin32.

I believe lcc-win32 has its own newsgroup which may be a better place to
post, especially since the topic of CLC is strictly the language rather
than specific implementations , and the operation of inline assembly is
even more offtopic.

That said, the developer of lcc-win32 does post here so may be able to
confirm your bug report offline.

If an inline assembly statement immediately follows a for loop
and you try to set a breakpoint on it, then the breakpoint is hit at each
iteration of the loop, not after the loop finishes.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt >

[Chris Peters]

Jacob

Thanks for the reply.

I don't think it would be as hard to fix as you imagine - probably just a
case of adding a -g command line option when you call the assembler.

In my opinion this is a very serious problem, and you should consider
fixing it with high priority.

Thanks

Chris
On Mon, 28 Jul 2008 00:12:36 +0200, jacob navia wrote:

Chris Peters wrote:

>Hello Group

Can anyone confirm or suggest workrounds for the following bug in
lccwin32. If an inline assembly statement immediately follows a for loop
and you try to set a breakpoint on it, then the breakpoint is hit at each
iteration of the loop, not after the loop finishes.

Thanks

Chris

The compiler does NOT emit any debug info when using
inline assembly. That is why the debugger get's confused.

One workaround is to write
_asm("int\t$3") ;
and you will get a breakpoint without any ambiguity.

The problem of not emitting debug info for inline
assembly is an old one. Fixing it would take a lot
of effort.

Soryy about this problem.

jacob

[Flash Gordon]

Chris Peters wrote, On 29/07/08 00:40:

Jacob

Thanks for the reply.

Please don't top-post, your reply should be interspersed with or after
the text you are replying to. See most messages in this group
*including* the one you were replying to for examples.

I don't think it would be as hard to fix as you imagine - probably just a
case of adding a -g command line option when you call the assembler.

You think you know more about Jacob's code and what is easy to do to it
than he does?

In my opinion this is a very serious problem, and you should consider
fixing it with high priority.

I don't see any reason why Jacob should. If you mess about interspersing
assembler with C you should expect it to cause problems using high level
tools on the result.

Any further discussion of this belongs in comp.compilers. lcc or private
correspondence with Jacob.
--
Flash Gordon

[jacob navia]

Chris Peters wrote:

Jacob

Thanks for the reply.

I don't think it would be as hard to fix as you imagine - probably just a
case of adding a -g command line option when you call the assembler.

There is no external assembler in lcc-win. It is
integrated with the compiler. It relies on the
debug information that comes with the compiler

In my opinion this is a very serious problem, and you should consider
fixing it with high priority.

Mr Peters:

As far as I see you do not have a maintenance agreement.
Maybe I will do it when I return from holidays, at the end
of August, maybe not.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ian Collins]

jacob navia wrote:

Chris Peters wrote:

Mr Peters:

As far as I see you do not have a maintenance agreement.
Maybe I will do it when I return from holidays, at the end
of August, maybe not.

"Chris Peters" is probably the same troll who regularly bates you here.
Just ignore it.

--
Ian Collins.

[Bartc]

"jacob navia" <ja***@nospam.c omwrote in message
news:g6******** **@aioe.org...

Chris Peters wrote:

>Hello Group

Can anyone confirm or suggest workrounds for the following bug in
lccwin32. If an inline assembly statement immediately follows a for loop
and you try to set a breakpoint on it, then the breakpoint is hit at each
iteration of the loop, not after the loop finishes.

The compiler does NOT emit any debug info when using
inline assembly. That is why the debugger get's confused.

One workaround is to write
_asm("int\t$3") ;
and you will get a breakpoint without any ambiguity.

The problem of not emitting debug info for inline
assembly is an old one. Fixing it would take a lot
of effort.

Have you thought of putting in a Bug Report option in your IDE? Then this
can send a private email or post to the right forum.

--
Bartc

[santosh]

Bartc wrote:

>Chris Peters wrote:

>>>
Hello Group

Can anyone confirm or suggest workrounds for the following bug in
lccwin32.

[ ... ]

Have you thought of putting in a Bug Report option in your IDE? Then
this can send a private email or post to the right forum.

He would need to add a whole lot of network/http code for that function.
It makes sense for huge commercial products like MSVC, not so much for
lcc-win.

[Richard Heathfield]

santosh said:

Bartc wrote:

>>Chris Peters wrote:

Hello Group

Can anyone confirm or suggest workrounds for the following bug in
lccwin32.

[ ... ]

>Have you thought of putting in a Bug Report option in your IDE? Then
this can send a private email or post to the right forum.

He would need to add a whole lot of network/http code for that function.
It makes sense for huge commercial products like MSVC, not so much for
lcc-win.

Oh, it shouldn't be that hard. It can even be done in ISO C.

#include <stdio.h>

extern int compile(int, char **);

int main(int argc, char **argv)
{
int ch;
const char *name = "jacob";
const char *domainname = "fixme.com.inva lid";
compile(argc, argv);
printf("Please type an 'at' character, ");
printf("of the kind found in email addresses.\n");
ch = getchar();
printf("If you have any bug reports,");
printf(" please send them to: %s%c%s\n",
name, ch, domainname);
return 0;
}

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999