Getting VBCC and Enforcer to Play Together

[tygre]

Hi all!

I read a lot of discussions (here, here, here, and here...) and docs. but I still can't get VBCC and Enforcer to play together on my Amiga

When my C code causes an Enforcer hit (not that often! ), Enforcer doesn't give me the hunk and offset information needed to find the line causing the hit. Because I have this information with LawBreaker, I think that I'm not compiling/linking "right"...

I compile my C code with VBCC v0.8j and the flags:

• CFLAGS += -g -hunkdebug;
• LDFLAGS += -Bamigahunk.

that I pass to vc, which I use both for compiling and linking. I receive a warning that the flag hunkdebug is used twice (because of -g, I guess) and my executable is 2-3 larger than without these flags, but still...

What am I missing here?

Cheers!

PS. I tried Hunk and BDebug too... Hunk shows some hunks (code and data) but BDebug tells me that there are no symbols to pick a line to put a breakpoint...

[PeterK]

Sorry, I didn't check your problem very well and I don't use C compilers with debug options, but do you have SegTracker running?

http://aminet.net/package/dev/debug/SegTracker

[tygre]

Hi PeterK!

Originally Posted by PeterK

Sorry, I didn't check your problem very well, but do you have SegTracker running?

http://aminet.net/package/dev/debug/SegTracker

Thank you for your swift answer

Yes, I do have SegTracker and I think that the combo SegTracker/Enforcer works well because I get the hunk/offset from Enforcer when running LawBreak... Or am I wrong?

Cheers!

[phx]

Originally Posted by tygre

still can't get VBCC and Enforcer to play together on my Amiga

They don't even need to play together. It's already sufficient if you get the hunk-offsets from your hits via Enforcer/SegTracker (or MuForce with the appropriate option).

Enforcer doesn't give me the hunk and offset information

Enforcer only gives you absolute addresses. SegTracker translates these addresses into section-offsets of a specific process.

I compile my C code with VBCC v0.8j

Wow! That's what I call retro-development, using a release which is nearly 13 years old!

Although, the compiler shouldn't have any influence on Segtracker reporting your section-offsets or not. I admit I prefered to use MuForce over the last years, but I remember that Enforcer always worked as well.

• CFLAGS += -g -hunkdebug;
• LDFLAGS += -Bamigahunk.

that I pass to vc, which I use both for compiling and linking. I receive a warning that the flag hunkdebug is used twice (because of -g, I guess) and my executable is 2-3 larger than without these flags, but still...

Yes, -hunkdebug is already in the aos68k config file, but will be inactive until -g is given.
Looking at the LDFLAGS: do you link with vlink yourself, or do you use the vc frontend? When calling vlink then watch your options, so you don't strip the debugging information again.

PS. I tried Hunk and BDebug too... Hunk shows some hunks (code and data) but BDebug tells me that there are no symbols to pick a line to put a breakpoint...

Then you stripped them! BDebug definitely works with vbcc's source level debugging information. I'm using that frequently.

Now I'm confused about your actual problem. Is it that SegTracker doesn't report any offsets when a hit happens, or is it that your FindHit-tool doesn't see any debugging information in the executable, or both?

Any FindHit-tool, which also works with SAS/C, should be able to translate the information from SegTracker into a source line. I also wrote such a tool, many years ago, which you find here:
http://sun.hasenbraten.de/~frank/projects/download/FindHunkOffset.lha

[tygre]

Hi Phx!

Thanks for you answer and your advice

Originally Posted by phx

They don't even need to play together. It's already sufficient if you get the hunk-offsets from your hits via Enforcer/SegTracker (or MuForce with the appropriate option).

Enforcer only gives you absolute addresses. SegTracker translates these addresses into section-offsets of a specific process.

Wow! That's what I call retro-development, using a release which is nearly 13 years old!

Although, the compiler shouldn't have any influence on Segtracker reporting your section-offsets or not. I admit I prefered to use MuForce over the last years, but I remember that Enforcer always worked as well.

Yes, -hunkdebug is already in the aos68k config file, but will be inactive until -g is given.
Looking at the LDFLAGS: do you link with vlink yourself, or do you use the vc frontend? When calling vlink then watch your options, so you don't strip the debugging information again.

Then you stripped them! BDebug definitely works with vbcc's source level debugging information. I'm using that frequently.

Now I'm confused about your actual problem. Is it that SegTracker doesn't report any offsets when a hit happens, or is it that your FindHit-tool doesn't see any debugging information in the executable, or both?

I was confused too Sorry about that! It seems that I have SegTracker+Enforcer working on my Amiga. When Enforcer reports a hit, it shows the hunk and offset in the last line of a "hit block":

Name: "Background CLI"  CLI: "AmiModRadio"  Hunk 0000 Offset 00049CF2

Good!

But, when I use FindHit on the executable (AmiModRadio) with the given offset (0:49CF2), FindHit says that "the object is of incorrect type" (translated from French). Does this mean that the hunks were stripped or that they are not the "right" ones? I use vc to link my code, so could that be the reason why hunks are stripped/mistyped? Though, I can't see anything on the command line that would explain that the hunks are stripped:

vbcc:bin/vc -lmieee -cpp-comments -I... -I... -I... -I... -I... -L... -L... -L... -lamiga  -lmiami -lposix -Bamigahunk -o bin/vbcc-classic/debug/AmiModRadio o/vbcc-classic/debug/... o/vbcc-classic/debug/... o/vbcc-classic/debug/...

(The ... are long paths to includes/libraries drawers or to .o files.)

What am I missing? Should I use explicitly vlink? With what "default" options?

Originally Posted by phx

Any FindHit-tool, which also works with SAS/C, should be able to translate the information from SegTracker into a source line. I also wrote such a tool, many years ago, which you find here:
http://sun.hasenbraten.de/~frank/projects/download/FindHunkOffset.lha

Will give it a try, thanks! Update: I tried and it says "no known symbol" (as expected?).

Cheers!

[phx]

Originally Posted by tygre

But, when I use FindHit on the executable (AmiModRadio) with the given offset (0:49CF2), FindHit says that "the object is of incorrect type"

Sounds like your FindHit-tool encountered a hunk-type which it doesn't know. Typical would be HUNK_RELOC32SHORT ($000003fc), which exists since OS2.0, and still there are many tools which don't know how to deal with it.

vbcc, or more precisely, the vc-frontend calling vlink, outputs these hunks by default, because it makes the executable much shorter. On the other hand, when you call vc with -g option, then it will automatically disable this feature, because I knew that many debuggers are too stupid to understand it.

So I still suspect that you forgot -g while linking with vc, or stripped the executable...

vbcc:bin/vc -lmieee -cpp-comments -I... -I... -I... -I... -I... -L... -L... -L... -lamiga  -lmiami -lposix -Bamigahunk -o bin/vbcc-classic/debug/AmiModRadio o/vbcc-classic/debug/... o/vbcc-classic/debug/... o/vbcc-classic/debug/...

I see no -g option there. So the executable will be stripped and uses short-reloc hunks. This would explain all the problems you described.

What am I missing? Should I use explicitly vlink? With what "default" options?

If you call vlink yourself, make sure to not specify either -s (strip all symbols) or -S (strip debug info) and do not specify -Rshort for short-relocs.

Update: I tried and it says "no known symbol" (as expected?).

Yes. As expected. My tool can deal with short-relocs, of course, but there is still no debug-info in the executable.

[tygre]

Originally Posted by phx

Sounds like your FindHit-tool encountered a hunk-type which it doesn't know. Typical would be HUNK_RELOC32SHORT ($000003fc), which exists since OS2.0, and still there are many tools which don't know how to deal with it.

vbcc, or more precisely, the vc-frontend calling vlink, outputs these hunks by default, because it makes the executable much shorter. On the other hand, when you call vc with -g option, then it will automatically disable this feature, because I knew that many debuggers are too stupid to understand it.

So I still suspect that you forgot -g while linking with vc, or stripped the executable...

I see no -g option there. So the executable will be stripped and uses short-reloc hunks. This would explain all the problems you described.

If you call vlink yourself, make sure to not specify either -s (strip all symbols) or -S (strip debug info) and do not specify -Rshort for short-relocs.

Yes. As expected. My tool can deal with short-relocs, of course, but there is still no debug-info in the executable.

Thank you!!!

I didn't realise that the -g option was necessary in both the compilation and linking phase, what a n00b! I added the -g option to the linking phase and I can now use FindHit or FindHunkOffset...

Let's the debugging begin

[tygre]

PS. To follow-up, I have yet-another question about using SegTracker+Enforcer: I have hits in a task that I create from the main task but Enforcer doesn't report hunk and offset for this task...

Is that expected? Or am I missing something else?

If that's normal, how can I pinpoint the line(s) causing the hits?

[phx]

Never tried that myself. Not sure. I guess that SegTracker needs a real process, which has a valid pr_SegList pointing to the loaded segments (sections) of an executable file.

[tygre]

Originally Posted by phx

Never tried that myself. Not sure. I guess that SegTracker needs a real process, which has a valid pr_SegList pointing to the loaded segments (sections) of an executable file.

Ah, okay!

Would you know of any ways with SegTracker or alternatives to get them to work with tasks?

[tygre]

Hi Phx and all!

Would you have any suggestion how to debug a task that I start from the main task? The Enforcer hits happen only when the two tasks run "in parallel", not when I remove the second task and run my code "sequentially"

(So I know that must have something to do with sharing some variables but hard to find which one and in which conditions! )

Cheers!

[Samurai_Crow]

Are you semaphore protecting the shared resources? Not doing so results in undefined behavior. Sharing variables should be done in a "mutex".

[tygre]

No, I'm not yet

I'd like to know first what variables are causing troubles...
Any idea maybe to get SegTracker or something else to give me the hunk/offset?

[bebbo]

Originally Posted by tygre

No, I'm not yet

I'd like to know first what variables are causing troubles...
Any idea maybe to get SegTracker or something else to give me the hunk/offset?

How do you start your threads? Maybe you could set the seglist for your threads?

newProc = CreateNewProcTags(NP_Entry, (ULONG )startProc,
            NP_FreeSeglist, 0,
            ...);


newProc->pr_SegList = mainProc->pr_SegList;

[tygre]

Hi Bebbo and thank you for your suggestion!

I tried but, even with a valid seglist from the main process (I checked), assigning it to the new process just crashes my Amiga I must miss some checks or something?

Best!

[phx]

What you say is confusing (again).

First you wrote that you want to debug a new Task (which likely runs from the same context as your main Process?), but now it seems to be a full Process? Or did you make it a process now? This is an important difference.

Also you wrote earlier that Enforcer shows illegal memory accesses from this new Task (or Process). What made you sure about that, when it runs the code from the main process? Does it show a different task id?

And now there are no Enforcer hits anymore, but the program crashes the machine immediately? Has that always been the case, or as a result of trying to implement Bebbo's suggestion (which I think is a good one)? Maybe you just did a mistake there. When the crash is easily reproducible you should be able to narrow it down.

[Thomas Richter]

Originally Posted by bebbo

newProc->pr_SegList = mainProc->pr_SegList;

*cough* pr_SegList is probably not what you think what it is. In particular, this is *not* a pointer to the seglist of the process. It is a pointer to an array of segments that are used by the BCPL runtime "binder" to fill the GlobVec, and as such it is not particularly useful for anything nowadays. This pointer should better not be touched or read by anything.


SegTracker, in particular, does not get its information from here, but from its own database that is patched into the system loader, aka "LoadSeg" and "UnloadSeg".

[tygre]

Hi Phx!

Originally Posted by phx

What you say is confusing (again).

Sorry about that! Thanks to bear with me

Originally Posted by phx

First you wrote that you want to debug a new Task (which likely runs from the same context as your main Process?), but now it seems to be a full Process? Or did you make it a process now? This is an important difference.

Ah, yes, mmh... So, I'm actually creating a process (?) like that:

_player_listener_task = (struct Task *)CreateNewProcTags(
		NP_Entry,       &_player_listener_loop,
		NP_Priority,    1,
		NP_Name,        LISTENER_NAME,
		NP_Output,      Output(),
		NP_CloseOutput, FALSE,
		TAG_DONE);

but I use this code really because I don't know any better way... I think that a task would make more sense in my context because I want tasks working for my main process/program... How should I create "true" tasks?

Originally Posted by phx

Also you wrote earlier that Enforcer shows illegal memory accesses from this new Task (or Process). What made you sure about that, when it runs the code from the main process? Does it show a different task id?

Yes: Enforcer shows the name that I gave to my new tasks (processes) on the last line of the Enforcer hit "block", whenever there is a hit. (And only when I enable this new feature that I want to add to my program.)

Originally Posted by phx

And now there are no Enforcer hits anymore, but the program crashes the machine immediately? Has that always been the case, or as a result of trying to implement Bebbo's suggestion (which I think is a good one)? Maybe you just did a mistake there. When the crash is easily reproducible you should be able to narrow it down.

Generally, my programs with its tasks (processes) runs well It's only when I enable my new feature that I have Enforcer hits. And it's only when I enable the feature and add the line suggested by Bebbo that my Amiga crashes immediately...

Cheers!

[Thomas Richter]

Originally Posted by tygre

It's only when I enable my new feature that I have Enforcer hits. And it's only when I enable the feature and add the line suggested by Bebbo that my Amiga crashes immediately...

As stated before, this line cannot work. In fact, it will cause a double-memory release of the seglist array. This array is better left alone.

[tygre]

Hi Thomas!

Originally Posted by Thomas Richter

As stated before, this line cannot work. In fact, it will cause a double-memory release of the seglist array. This array is better left alone.

You beat me at answering your previous post

How could I "trace" the code responsible for the Enforcer hits in this new process then? Is there a way? (Besides printfs...) Maybe if it was a real task, it would be "linked" to the main process and the question would be moot?

Cheers!