Gary,

The linker needs to lookup the address of the ENTRY label in the ELF tables 
loaded from the obj files.  This means it must be declared as public in the ASM 
file where it is defined.  This is done with a line  (typically at the top of 
the file) like this:

   .public. START

This will create an entry in the obj ELF symbol table for the label with the 
associated address.

Ken

Sent from my iPhone

> On Aug 10, 2017, at 11:37 AM, Gary Weber <g...@web8201.com> wrote:
> 
> Of course, I could be misinterpreting how it is supposed to work.  Given that 
> we have an ORG address which is an actual physical address, I was expecting 
> that the START label which is going to end up referring to an address that is 
> calculated with an offset from ORG (because it is further into the file) 
> would end up being available for the linker script.    
> 
> But, is it rather the case that ENTRY actually also does have to refer to a 
> physical address?  I'd have to compile it once and then look at the .LST 
> output to find out at what address START ends up being, to then be able to 
> modify the linker script with the correct entry address.  
> 
> Thanks,
> Gary
> 
> 
> 
>> On Wed, Aug 9, 2017 at 8:28 PM, Gary Weber <g...@web8201.com> wrote:
>> Ken,
>> 
>> Thanks for the advice.  I did try that, but something else must be wrong.
>> 
>> I have a label called "START" at the entry address in my main .ASM file.    
>> In the linker script, after putting in the line you suggest, I try to 
>> compile but it gives an error:
>> 
>>     Error during linking: Unresolved entry address START - not defined in 
>> any object file
>> 
>> Is there something else I am missing in the linker script or elsewhere?  
>> Something like a .aseg or .cseg assignment?
>> 
>> Thanks!
>> Gary
>> 
>> 
>>> On Wed, Aug 9, 2017 at 7:16 PM, Kenneth Pettit <petti...@gmail.com> wrote:
>>> Gary,
>>> 
>>> I'm the linker script, try adding the following:
>>> 
>>> ENTRY entry_label
>>> 
>>> This should work I believe.
>>> Ken
>>> 
>>> Sent from my iPhone
>>> 
>>> > On Aug 9, 2017, at 7:08 AM, Gary Weber <g...@web8201.com> wrote:
>>> >
>>> > I was able to create a LKR file (based off of Ken's Sample.LKR), and I
>>> > did get it to compile and my .CO file gets loaded into RAM just fine,
>>> > however the LOAD & EXE addresses are way off so I know there has to be
>>> > a problem somewhere.
>>> >
>>> > If anyone out there can offer a bit of guidance for using the VirtualT
>>> > IDE, particularly how to properly control the load & exe addresses for
>>> > a compiled .CO file (because it is more than just simply an ORG
>>> > statement in the ASM file), I could really use the help.
>>> >
>>> > Thanks!
>>> > Gary
>>> >
>>> >
>>> >> On Mon, Aug 7, 2017 at 1:49 AM, Gary Weber <g...@web8201.com> wrote:
>>> >> Up until now I've been doing things the "old fashioned" way and using
>>> >> an 8085 Cross assembler on my Windows PC.  (Okay, I kid..   The truly
>>> >> old fashioned way would be to use an assembler running on a Model T.)
>>> >>
>>> >> I'm transitioning my UltrascreenNEC project to VirtualT IDE.  I've got
>>> >> v1.7.   Problem is, it seems the documentation on the IDE portion is
>>> >> not fully fleshed out.   Does anyone have an example on how to set up
>>> >> a linker file (.lnk) for an assembly project in the IDE?  Or can you
>>> >> point me to the right docs?
>>> >>
>>> >> Many thanks,
>>> >>
>>> >> --
>>> >> Gary Weber
>>> >> g...@web8201.com
>>> >
>>> >
>>> >
>>> > --
>>> > Gary Weber
>>> > g...@web8201.com
>> 
>> 
>> 
>> -- 
>> Gary Weber
>> g...@web8201.com
> 
> 
> 
> -- 
> Gary Weber
> g...@web8201.com

Reply via email to