gnupic: Re: [gnupic] gpasm `relocatable mode' and org directives (bugfix,patch)
Subject:
Re: [gnupic] gpasm `relocatable mode' and org directives (bugfix,patch)
From:
Craig Franklin ####@####.####
Date:
6 May 2005 03:23:23 +0100
Message-Id: <427AD546.9080307@users.sourceforge.net>
Ian Jackson wrote:
>When gpasm is producing an object file for future linking, which the
>manual calls `relocatable mode', there is an infelicity in the
>processing of `org' directives without explicit section names.
>
>If the program contains two such directives, they'll use the same
>autogenerated section name, producing the following error from the
>linker:
> error: section ".org_0" is absolute but occurs in more than one file
>
>
>
mpasm/mplink does the same thing. That is not saying it is correct.
It is simple enough to work around. Use CODE instead of ORG and name
the sections.
>gpasm/directive.c (gputils 0.12.4) tries to generate a unique section
>name, but the names are only unique within a file - not unique
>throughout the whole program. I suggest the simple patch below, which
>additionally encodes the address (from the RHS of the .org) into the
>autogenerated name. Thus a program which says `org X' in one file and
>`org Y' in another will link so long as X != Y. I've tested this and
>it seems to work for me.
>
>
>
This is very similar to the original gpasm implementation. I only
changed it to the numbered version after it was pointed out that it
didn't match mpasm. That really isn't a good enough reason.
I have sent a bug report to Microchip.
I will revert back to my original implementation (.org_{address}).
>You'll see that in the patch I moved the assignment of new_sec_addr.
>This is so that I could use it in the snprintf. r could be used
>instead, but it is a gpasmVal and would have to be cast to a concrete
>C type (eg to unsigned long) so that the right printf format specifier
>could be known and be used (%lx in that case). new_sec_addr is an int
>so it can be printed with %x. I should point out that it is (at least
>technically) wrong that ints are used for PIC addresses, because the
>guarantee made by the C Standard is only that an int can hold at least
>16 bits' worth. gpasm will go wrong on hosts with 16-bit ints (for
>example, certain DOS memory models). Fixing that would require fairly
>widespread changes and I think it's best left for another day :-).
>
>
>
Feel free to fix it.
>Thanks,
>Ian.
>
>--- gpasm/directive.c~ Fri Sep 24 21:56:28 2004
>+++ gpasm/directive.c Mon Apr 25 02:45:25 2005
>@@ -1634,8 +1634,8 @@
> } else {
> /* Default section name, this will be overwritten if a label is
> present. */
>- snprintf(state.obj.new_sec_name, sizeof(state.obj.new_sec_name), ".org_%d", state.obj.org_num++);
> state.obj.new_sec_addr = r;
>+ snprintf(state.obj.new_sec_name, sizeof(state.obj.new_sec_name), ".org_%d_%x", state.obj.org_num++, state.obj.new_sec_addr);
> state.obj.new_sec_flags = STYP_TEXT | STYP_ABS;
> state.lst.line.linetype = sec;
> state.next_state = state_section;
>
>
>
