filenames mangled in *.dbg output

[cdsteinkuehler]

The *.dbg file output generated by this version of pasm mangles the filenames, making it cumbersome to use debugging utilities (which search for and cannot find the incorrectly named files). A simple test case is provided, which results in the following incorrect filenames in the test.dbg file:

Filename	test.dbg Filename
test.p	.test.p
a.h	.a.h
../b.h	./..b.h

machinekit@beaglebone:~$ mkdir PRU-Test
machinekit@beaglebone:~$ cd PRU-Test/
machinekit@beaglebone:~/PRU-Test$ touch a.h
machinekit@beaglebone:~/PRU-Test$ touch ../b.h
machinekit@beaglebone:~/PRU-Test$ echo -e '#include "a.h"\n#include "../b.h"\nMAIN: JMP MAIN\n' > test.p
machinekit@beaglebone:~/PRU-Test$ pasm -b -L -d -V2 test.p

PRU Assembler Version 0.86
Copyright (C) 2005-2013 by Texas Instruments Inc.

test.p(3) Warning: Using default code origin of 8

Pass 2 : 0 Error(s), 1 Warning(s)

Writing Code Image of 9 word(s)

machinekit@beaglebone:~/PRU-Test$ strings test.dbg
MAIN
.test.p
.a.h
./..b.h
machinekit@beaglebone:~/PRU-Test$

[jadonk]

Got a fix?

[cdsteinkuehler]

On 10/17/2016 11:08 AM, Jason Kridner wrote:

Got a fix?

Not yet. I took a quick look at the code, but whatever the issue is, it's non-obvious (to me) and doesn't look like it's in the code that creates the *.dbg file. :-/

Charles Steinkuehler charles@steinkuehler.net

[zultron]

I got curious and took a look. I have a fix, but can't explain why nobody found this earlier, unless everyone's using really old code, or unless everybody's using Windogs. See the description in PR #54.

[cdsteinkuehler]

On 10/17/2016 3:35 PM, John Morris wrote:

I got curious and took a look. I have a fix, but can't explain why nobody found this earlier, unless everyone's using really old code, or unless everybody's using Windogs. See the description in PR #54 https://github.com/beagleboard/am335x_pru_package/pull/54.

The actual INCLUDING of the files was working fine. It's the filenames that got put into the *.dbg output file that were mangled.

My guess is virtually nobody is using the *.dbg output...the options for PRU debuggers are pretty slim, so you have to be pretty desperate to try to use one. I break out Michael Haberler's HAL based PRU debugger when I get particularly stuck on a problem, which is how I discovered the problem.

Charles Steinkuehler charles@steinkuehler.net