Re: [Tinycc-devel] Your revert of a gdb-helping patch breaks gdb

[Michael Matz]

Hi,

On Mon, 9 Mar 2015, Sergey Korshunoff wrote:

> This behavior may depend on the gdb version. I use a rhide v1.5 for
> debuggin (i386, Linux). A gdb version embedded in it is 6.1.1

This version is more than ten years old.

> And which version of the gdb you use?

Various ones, 7.3, 7.5.50, 7.8.

> I think a tcc switch must be 
> introduced to select a stabs handling behavior.

I don't think so.  I rather think we should do what a normal linker does 
in this respect, and that's relocating the input sections.  So you're 
saying that a hello world compiled by gcc -gstabs (and linked by ld) 
doesn't work in rhide?  In that case rhide is simply buggy and needs 
fixing.  If it does work OTOH, then you should find out why and make tcc 
emulate gcc+ld better.

> PS: grishka don't explain in his patch why he change a behavior of the 
> previous patch.

Well, neither did you, but the way it's not working without relocated 
.stabs is very obvious, as I showed in my mail.  When not relocating 
.stabs no program compiled by tcc -g will be debuggable in gdb.

On Mon, 9 Mar 2015, Sergey Korshunoff wrote:

> > By the way: after appling a patch CValue (replacing various integer
> > types with int64_t) rhide works well independed of stabs behavior
> > (with relocating stabs section and w/o this). What this means?
>
> Sorry, this is not true.  With grishka patch on rhide don't work.

So, what exactly doesn't work?

> PS: You can test this itself (www.rhide.com)

Well, you want to use age-old software, so IMO it's you having the 
burden of debugging your IDE.  But some other hint: you can also use 
objdump to inspect the debug output of tcc:

% objdump -g hello.broken

hello:     file format elf64-x86-64

/home/matz/hello.c:
<undefined> main ()
{ /* 0x0 */
  /* file /home/matz/hello.c line 5 addr 0x0 */
  /* file /home/matz/hello.c line 5 addr 0xb */
  /* file /home/matz/hello.c line 6 addr 0xb */
  /* file /home/matz/hello.c line 7 addr 0x1f */
} /* 0x2b */
...

(That's a full executable).  As you can see, the addresses are wrong by 
starting at zero.  A working executable shows this:

% objdump -g hello.ok

hello.ok:     file format elf64-x86-64

/home/matz/hello.c:
<undefined> main ()
{ /* 0x400303 */
  /* file /home/matz/hello.c line 5 addr 0x400303 */
  /* file /home/matz/hello.c line 5 addr 0x40030e */
  /* file /home/matz/hello.c line 6 addr 0x40030e */
  /* file /home/matz/hello.c line 7 addr 0x400322 */
} /* 0x40032e */
...

I have one other idea, that _might_ be the cause for your problems: tcc 
usually emits all input sections to the output, and that includes the 
applied .rela.<secname> sections.  So, in a way, the produced executables 
contain the relocations twice: once in the target section, once in the 
relocation section again.  This is normally harmless (only dynamic 
relocations are processed for executables, not those additional ones), but 
possibly the old tools you use do apply them again.

You can check this if you remove that section: with a program 
compiled/linked by a tcc with your revert reverted (i.e. relocated 
.stabs), do this:

% objcopy -R .rela.stabs input output

If input isn't debuggable in rhide, but output is, then this is the 
problem, and the right fix for tcc is to not emit those needless .rel(a) 
sections in linked files.


Ciao,
Michael.