| stekern | at least running 'readelf --debug-dump=decodedline' on the elfs produced by the old as and the new gives different results | 06:42 |
|---|---|---|
| stekern | and the or32 one looks strange (even to the layman I am) | 06:46 |
| stekern | http://pastie.org/4869217 | 06:55 |
| stekern | not sure if the or1k one looks sane | 06:55 |
| stekern | but i guess the 'starting address' is the offset in the function | 06:55 |
| stekern | just realised it's hard to see the line numbers of the .c the way I pasted it | 06:56 |
| stekern | http://pastie.org/4869252 | 06:57 |
| stekern | maybe my guess is wrong... line 16 is main, and the .loc is placed before the first instruction and that's not 0 | 07:03 |
| stekern | I probably should read up on the format and stop guessing ;) | 07:04 |
| stekern | ah, no, how silly of me... it's the offset in the section | 07:13 |
| stekern | http://pastie.org/4869380 | 07:16 |
| stekern | so .loc 16 is clearly wrongly encoded in the or32 case (0x30) since it's on the first line in main, that starts at address 0x20. or1k has the correct starting address (0x20). | 07:19 |
| stekern | doesn't prove that it'd be safe to turn on DWARF2_ASM_LINE_DEBUG_INFO, but at least it proves or1k does something right where or32 do it wrong. | 07:21 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!