Introducing Profyler

	Bottom Previous Topic Next Topic
Register To Post

« 1 2 (3)

kas1e

Re: Introducing Profyler

Posted on: 2022/1/28 8:48 #41

Home away from home

@msteed
I don't get much answer about ObtainDebugSymbols issue, but yeah, Dos.library's autodoc for loadseg() also says that "Please note that LoadSeg() functions call the TrackSegmentList() function internally, and UnLoadSeg() calls UnTrackSegmentList()".

As you say we can see what DOS is tracking by using Ranger in that DOS tab for [DOS]->TrackedAddr section. And then if all is ok there, then the problem is somewhere else, but if things are not ok there already, then it can be something about connections between obtaindebugsymbol() and additions to the TrackSegmentList by DOS.

Is it always the case that via Ranger from terms of DOS all is ok and tracking is done correctly?

Join us to improve dopus5!
AmigaOS4 on youtube

Kamelito

Re: Introducing Profyler

Posted on: 2022/1/28 17:13 #42

Just popping in

Does it mean that AmigaOS 4.1 do have resource tracking and free them when an app crash?

msteed

Re: Introducing Profyler

Posted on: 2022/1/29 2:28 #43

Just popping in

@kas1e

Quote:

Is it always the case that via Ranger from terms of DOS all is ok and tracking is done correctly?

It has looked correct the few times I've checked, but that's not the sort of thing I look at on a regular basis.

I couple of times now I've used Ranger to confirm that the 'Simple' test program is being tracked, when at the same time Profyler is unable to display the source file name and line number information for the program. So in those cases at least I'd say that address tracking is correct, but ObtainDebugSymbol() still does not return those fields.

Of course, just because it shows up in Ranger doesn't mean that all of the associated debug information is being correctly extracted from the ELF file, but I have no way to test that.

328gts

Re: Introducing Profyler

Posted on: 2022/1/31 3:46 #44

Home away from home

@msteed

welcome aboard

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

kas1e

Re: Introducing Profyler

Posted on: 2022/1/31 20:27 #45

Home away from home

@msteed
Quote:

It has looked correct the few times I've checked,

Ok, it was fixed by Frederik. That was just an oversight while copying the code out of an exception handler. Because in DSI or similar exception, the actual fault address is not the instruction pointer in the exception context, but one instruction in front of that, so ip-4. And that ip-4 was here as well when things were copied and that was an oversight. You can even get the correct line/source numbers right now by doing main+4 in your code (just for sake of fun of course only).

In other words with the next kernel release, things should work as you expect them to work. Thanks for pointing out, one bug less.

Join us to improve dopus5!
AmigaOS4 on youtube

msteed

Re: Introducing Profyler

Posted on: 2022/2/1 2:40 #46

Just popping in

@kas1e

So if I understand correctly, ObtainDebugSymbol() assumed it was always being called from an exception context, and so always adjusted the address it was given. When called from a normal task context the adjustment is not required, and when it made the adjustment anyway, the address ended up being incorrect. (At least that's the effect, if not the actual problem.) Interesting.

To confirm this, I added a harmless DSI (a read from address zero) to my earlier example program. When the program "crashes" I can use Grim Reaper to display a stack trace, and indeed the source file name and line number are present. (The DSI can be ignored and the example program will terminate normally.)

And as you suggested, compensating for the bug by adding four to the address given to ObtainDebugSymbol() allows the source file name and line number to appear, confirming a workaround.

For those following along, here's the updated example program. By adding and removing comments you can demonstrate the bug or confirm the workaround. You can also remove a comment to trigger the DSI. Use the makefile from my earlier post (#26) to build the program.


// Simple example to demonstrate lack of source file name and line 

// number in symbol information returned by ObtainDebugSymbol().



#include <exec/types.h>

#include <exec/debug.h>

#include <stdio.h>

#include <proto/exec.h>



int main(int argc, char **argv)

{

    struct DebugSymbol *Ourself;

    UNUSED uint32 Dummy;



    // Get symbol information about ourself. Source file name and line

    // number will not be displayed.

    // Ourself = IDebug->ObtainDebugSymbol(&main, NULL);



    // Get symbol information about ourself, with address adjusted to

    // account for Exec bug. Source file name and line number will be

    // displayed.

    Ourself = IDebug->ObtainDebugSymbol(&main + 4, NULL);



    // Display the base name.

    if(Ourself && Ourself->SourceBaseName)

        printf("Base name: %s\n", Ourself->SourceBaseName);

    else

        printf("No base name!\n");



    // Display the function name.

    if(Ourself && Ourself->SourceFunctionName)

        printf("Function name: %s\n", Ourself->SourceFunctionName);

    else

        printf("No function name!\n");



    // Display the source file name.

    if(Ourself && Ourself->SourceFileName)

        printf("Source file name: %s\n", Ourself->SourceFileName);

    else

        printf("No source file name!\n");



    // Display the source file line number.

    if(Ourself && Ourself->SourceLineNumber)

        printf("Source line number: %ld\n", Ourself->SourceLineNumber);

    else

        printf("No source line number!\n");



    // We're done with the symbol info.

    IDebug->ReleaseDebugSymbol(Ourself);



    // Uncomment to cause a harmless DSI. Source file name and line number

    // will be displayed in stack trace.

    // Dummy = *(uint32 *)0;



    // All done.

    return(0);

}

I modified Profyler to adjust the function address before passing it to ObtainDebugSymbol(), and confirmed that the source file name and line number now appear for programs being profiled. Nice!

Of course, once the new version of Exec comes out the workaround needs to be removed. If I wanted to test the version of Exec and only apply the workaround to versions prior to the fix, what version of Exec might I want to check for?

kas1e

Re: Introducing Profyler

Posted on: 2022/2/1 7:02 #47

Home away from home

@msteed
Quote:

Of course, once the new version of Exec comes out the workaround needs to be removed.If I wanted to test the version of Exec and only apply the workaround to versions prior to the fix, what version of Exec might I want to check for?

Dunno at the moment (as the fix was applied to svn, but what version of the kernel will be with that fix dunno). But something after 54.46 for sure.

Join us to improve dopus5!
AmigaOS4 on youtube

nbache

Re: Introducing Profyler

Posted on: 2022/2/1 23:16 #48

Just can't stay away

It would probably be a very good bet to test for >= 54.47. I can't imagine a reason why the fix wouldn't be in the next beta kernel, where we currently have 54.46.

But yeah, we can't know for sure until it's released. And which version will make it to public (and when) is another question altogether.

Best regards,

Niels

msteed

Re: Introducing Profyler

Posted on: 2022/3/6 7:33 #49

Just popping in

I waited for a bit in case anything else came up, but nothing did. So I've released version 1.1 of Profyler, which adds a workaround for the bug in ObtainDebugSymbol() and so can now display the source file name and line number for every profiled function.

The workaround shuts off starting with Exec version 54.47, so hopefully the bug fix will be present in that version when it appears.

Register To Post	« 1 2 (3)
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )