<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 2:24 PM Andrew Kelley <<a href="mailto:andrew@ziglang.org">andrew@ziglang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/3/18 5:10 PM, Rui Ueyama wrote:<br>
> I think Eli made a good point.<br>
<br>
Eli's point seems to be "your use case is not valid", which I will<br>
consider, but it doesn't really work towards solving the problem as stated.<br>
<br>
> In addition to that, if you are writing a<br>
> OS kernel, I guess you are also writing a loader, so you can map<br>
> anything as you want, no?<br>
<br>
Well, I don't have a loader written yet, and I want to use this stack<br>
trace feature while working on it. But even if I did, the addresses in<br>
the ELF file produced by LLD are incoherent, and so it would not be<br>
possible to map them.<br>
<br>
Another alternative would be to ship debug symbol files separately on a<br>
file system. I also don't have a file system written yet.<br>
<br>
The bottom line is that, there's no fundamental reason this cannot work;<br>
it is a quirk of conventions that is unnecessarily preventing the debug<br>
info from being mapped into memory.<br></blockquote><div><br></div><div>Yes, there's no fundamental reason this cannot work. Rather, it should work. It does not immediately mean that lld needs to work for such linker script, since we intentionally try to not work too hard to support 100% linker script compatibility with GNU ld, as it's not strictly doable due to the lack of a formal specification, and as it is sometimes extremely tricky. That said, it is probably worth taking a look at why this doesn't work.</div></div></div>