Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 224719 - dev-embedded/gputils-0.13.6 produces bad files when using CODE_PACK directive
Summary: dev-embedded/gputils-0.13.6 produces bad files when using CODE_PACK directive
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Embedded Team (OBSOLETE)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-03 08:12 UTC by David Barnett
Modified: 2008-06-03 08:36 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
code_pack.patch (code_pack.patch,6.25 KB, patch)
2008-06-03 08:15 UTC, David Barnett
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Barnett 2008-06-03 08:12:49 UTC
As reported on gputils bug tracker:
gpasm produces wrong line number addresses in 18F code_pack
Consider the following source file (with line numbers prepended for
reference):

[1] radix dec
[2] processor 18F4550
[3] #include <p18f4550.inc>
[4]
[5] code_pack
[6] db 1,2,3
[7] db 4,5,6
[8] end

Compiling this source file with "gpasm -c test.asm" produces a file
"test.o". Running "gpvo test.o" produces this output:

[snipped]
Data
000000: 0201 mulwf 0x1, 0
000002: 0403 decf 0x3, 0, 0
000004: 0605 decf 0x5, 0x1, 0

Line Number Table
Line Address Symbol
6 0 test.asm
6 0x2 test.asm
7 0x4 test.asm
7 0x6 test.asm
[snipped]

Clearly the line number table is horribly wrong! In fact, as a result of
this broken line number table, gplink later crashes with an assertion
failure (lst.c:171: write_src: Assertion `data & 0x80000000' failed).

This is with 0.13.6 beta.

Reproducible: Always
Comment 1 David Barnett 2008-06-03 08:15:09 UTC
Created attachment 155337 [details, diff]
code_pack.patch

Patch from upstream (myself) to fix the problem.
Comment 2 Denis Dupeyron (RETIRED) gentoo-dev 2008-06-03 08:36:31 UTC
Fixed. Thanks for letting us know.

Denis.