I have an interesting update on this :
The file src/cpu/exetracer.cc
has the following code snippet :
******************************************************************************************
std::string sym_str;
Addr sym_addr;
Addr cur_pc = pc.instAddr();
if (debugSymbolTable && Debug::ExecSymbol && !inUserMode(thread)
&& debugSymbolTable->findNearestSymbol(cur_pc, sym_str, sym_addr)) {
if (cur_pc != sym_addr)
sym_str += csprintf("+%d",cur_pc - sym_addr);
outs << "@" << sym_str;
} else {
outs << "0x" << hex << cur_pc;
******************************************************************************************
There are 2 potential issues with this code/other code related to the code
here
1) The debugSymbolTable variable has the starting address of the symbol
table,
but the findNearestSymbol function returns a null string to sym_str. Why is
that
happening ? I know that the Symbol table exists because if I run the code
with
the flag "Loader", the Symbol table gets printed out to the trace
2) Also, the outer "if" statement checks for the value returned by the
inUserMode()
function, which always returns 1, so the "if" condition fails and the PC
value gets printed
out instead of the symbol
Thanks,
Umesh
On Thu, Feb 28, 2013 at 6:07 PM, Korey Sewell <[email protected]> wrote:
> It looks like the problem is the ARM ISA isn't dumping the function
> symbols despite using the "Exec" group debug flag (that flag group has
> "ExecSymbol" in it).
>
> Does anyone that worked on the ARM ISA have experience w/successfully
> generating the symbol table and getting that into trace output?
>
> If that works, Umesh can just generate the trace and "grep" for the
> relevant assembly instructions by function name (Assuming that function
> doesnt call other functions).
>
> -Korey
>
> On Thu, Feb 28, 2013 at 2:46 PM, Mitch Hayenga <
> [email protected]> wrote:
>
>> Not that I know of. For a poor man's version, since it seems you are
>> just trying to generate various traces from a region of interest.... You
>> could just use the existing m5ops to checkpoint @ the beginning of the
>> region of interest and exit @ the end. That way you could just run from
>> the checkpoint with the trace flags enabled.
>>
>> Alternatively, I bet it would be possible to define your own m5ops that
>> dynamically enable/disable trace flags. But that would take a bit of work
>> and hacking on the simulator.
>>
>>
>> On Thu, Feb 28, 2013 at 4:25 PM, Umesh Bhaskar <[email protected]>wrote:
>>
>>> Hi Gem5 users,
>>>
>>> The command I issued is :
>>>
>>> build/ARM/gem5.debug --debug-flags=Exec configs/example/se.py -c
>>> tests/test-progs/hello/bin/arm/linux/hello
>>>
>>> One line from the trace is shown below:
>>>
>>> 2263500: system.cpu T0 : 0x9cf8.5 : ldr_uop r35, [r34, #16] :
>>> MemRead : D=0x00000000000511fc A=0xbefffcac
>>>
>>> I have a 2 part question
>>>
>>> 1) Is there anyway I can limit the tracing to just the main() or a
>>> subset of instructions inside the main function
>>> and not the preliminary setup instructions ? --trace-start is not very
>>> suitable for this since it is dependent on simulator
>>> ticks
>>>
>>> 2) If this is not possible, can I, in any way, dump the function and
>>> data structure names to the
>>> trace file, so that we can easily filter out information relating to a
>>> subset of instructions.
>>>
>>> Thanks,
>>> Umesh
>>>
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> [email protected]
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>
>>
>> _______________________________________________
>> gem5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>
>
> --
> - Korey
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
