(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]

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

 

[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

 

[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.

 

[jacob navia]

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.

 

[Ian Collins]

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.

 

[Bartc]

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.

 

[santosh]

[ ... ]

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.

 

[santosh]

santosh said:

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.invalid";
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;
}

I would place the compile invocation after the bug report message and
add an fflush(stdout) after the printfs. Now even an abortion or
segmentation fault during compile cannot affect the output of the
support message.

 

[Bartc]

santosh said:

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.

Since this is for Windows it can be done easily (emailing anyway) using
something like:

#include <shellapi.h>

int main (void)
{
ShellExecute(0,"open","mailto:[email protected]",0,0,1);
}

 

[santosh]

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.

Since this is for Windows it can be done easily (emailing anyway)
using something like:

#include <shellapi.h>

int main (void)
{
ShellExecute(0,"open","mailto:[email protected]",0,0,1);
}

You've just exposed jacob's carefully munged email address to all the
spam harvesters of the Internet.

 

[santosh]

santosh said:

Bartc wrote:

{
ShellExecute(0,"open","mailto:[elided]",0,0,1);
}

You've just exposed jacob's carefully munged email address to all the
spam harvesters of the Internet.

Er, so did you, just now.

(I, on the other hand, very carefully did not do that, either in my
original reply or in this one. I know Jacob thinks (wrongly, as it
happens) that I'm out to get him, and of course it's common knowledge
that we have massive disagreements from time to time, but I reckon he
and I *can* agree that there are some things you just don't do to
people, no matter how bad the relationship between you, and
deliberately increasing their exposure to spam is right up there in
the top three. Having said that, I'm very sure that the exposures in
this thread were a result of thoughtlessness rather than malice. And
this parenthetical comment now vastly exceeds the length of the text
to which it is a parenthetical comment, so I'd better stop.)

And I on my part would like to apologise to jacob for thoughtlessly
perpetuating Bartc's mistake for one post more than it should have. I
noticed it immediately after hitting the Send button, but alas, Usenet
cancels are not honoured. However I have deleted my post from Google
Groups.

 

[Bartc]

santosh said:

Bartc wrote:

{
ShellExecute(0,"open","mailto:[elided]",0,0,1);
}


You've just exposed jacob's carefully munged email address to all the
spam harvesters of the Internet.

Er, so did you, just now.

And I on my part would like to apologise to jacob for thoughtlessly

Yes. I apologise too. And I've removed my post from google, if that makes a
difference.

So much for trying to make my example authentic...