Re: Problems with startup code symbols (Copious warnings)

[Steven Johnson <sjohnson@sakuraindustries.com>]

Jim Blandy wrote:

>Jim Blandy <jimb@codesourcery.com> writes:
>  
>
>>Steven Johnson <sjohnson@sakuraindustries.com> writes:
>>    
>>
>>>Will post an app tomorrow that does this, once I've made one.
>>>      
>>>
>>I see your post in the archive, but for some reason it didn't reach
>>me.  I'll take a look.
>>    
>>
>
>Okay.  I think I understand part of the problem.
>
>If you run 'readelf -wi' on your executable, you should see two
>DW_TAG_compile_unit entries. Each has DW_AT_high_pc and DW_AT_low_pc
>attributes.  The DWARF data claims that the crt0.c compilation unit
>covers addresses zero to zero, and that the vectors.S compilation unit
>covers addresses from zero to 0x104.
>  
>
Well that was a problem.  crt0.c shouldn't have been there, I got rid of
it with -nostartfiles.  Now its not present in the readelf -wi, i only
have vectors.s covering the range 0-0x104.  It doesn't change the
problem, so its probably down to the link-once stuff below.

>Then, each of them has a DW_AT_stmt_list that points to line number
>information, which you can dump with 'readelf -wl'.  The crt0.c line
>number info definitely seems to cover addresses outside the range
>given in the crt0.c DW_TAG_compile_unit entry.  Which is odd.  Where
>did the code from crt0.c really go? 
>  
>
Don't know, it shouldn't have been there in the first place. I've never
noticed it before in debugging, because it seems only its debug info was
hanging around, no code from it seems to be in my projects???

>Is there some reason relocs against the debugging information aren't
>getting applied?  I didn't quite get everything that was going on in
>your link line.
>  
>
You have lost me here, I don't know what you mean?  Specifically, I
don't understand "relocs against the debugging information aren't
getting applied"?

>The other part of the problem is that GDB distrusts DW_AT_low_pc
>attributes whose values are zero, presuming that they refer to a
>discarded 'linkonce' section.  Here's the code:
>
>  /* When using the GNU linker, .gnu.linkonce. sections are used to
>     eliminate duplicate copies of functions and vtables and such.
>     The linker will arbitrarily choose one and discard the others.
>     The AT_*_pc values for such functions refer to local labels in
>     these sections.  If the section from that file was discarded, the
>     labels are not in the output, so the relocs get a value of 0.
>     If this is a discarded function, mark the pc bounds as invalid,
>     so that GDB will ignore it.  */
>  if (low == 0 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0)
>    return 0;
>  
>
This is without question what is breaking my debug session.  I commented
out this code and all works fine, and the error goes away.  I also
dumped the assumed discarded bfd information, to see if there was any
difference in my main project with the original code and any .linkonce
sections in it that could be identified, but it turns out I don't have
any .linkonce sections in my project.

I was about to suggest a flag that conditions off this test, instead of
the warning.  However I then received Freds post, and if that would
work, it would be better, cause it is automatic.  Unfortunately I am
quite lost here and wouldn't even know where to begin to check "If one
loadable section has a VMA of 0" otherwise I would throw a test together
to see if it fixed it.

Steven J