Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
62 user(s) are online (28 user(s) are browsing Forums)

Members: 0
Guests: 62

more...

Headlines

 
  Register To Post
« 1 2 (3)

Re: Introducing Profyler
Home away from home
Home away from home


See User information
@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?

Go to top
Re: Introducing Profyler
Just popping in
Just popping in


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

Go to top
Re: Introducing Profyler
Just popping in
Just popping in


See User information
@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.


Go to top
Re: Introducing Profyler
Home away from home
Home away from home


See User information
@msteed

welcome aboard

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

Go to top
Re: Introducing Profyler
Home away from home
Home away from home


See User information
@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.

Go to top
Re: Introducing Profyler
Just popping in
Just popping in


See User information
@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 argcchar **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 4NULL);

    
// 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?

Go to top
Re: Introducing Profyler
Home away from home
Home away from home


See User information
@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.

Go to top
Re: Introducing Profyler
Just can't stay away
Just can't stay away


See User information
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

Go to top
Re: Introducing Profyler
Just popping in
Just popping in


See User information
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.

Go to top

  Register To Post
« 1 2 (3)

 




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




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project