• Per =?UTF-8?B?Tm9yZGzDtnc=?= (22/22) Feb 10 How do I make LDC stacktraces like
• Per =?UTF-8?B?Tm9yZGzDtnc=?= (40/44) Feb 12 So it turns out that ldc2 doesn't show symbols in stack traces by
• ryuukk_ (5/5) Feb 12 I agree, debug builds should show proper stack trace by default
• Johan (5/18) Feb 12 LDC does not support etc.linux.memoryerror, due to issues with

Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

How do I make LDC stacktraces like

```test-library(+0x1fb232)[0x562230d82232]
test-library(+0x2a35b7)[0x562230e2a5b7]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f6ad2242520]
test-library(+0x7521a)[0x562230bfc21a]
test-library(+0x79083)[0x562230c00083]
test-library(+0x2a35f5)[0x562230e2a5f5]
test-library(+0x2b0627)[0x562230e37627]
test-library(+0x2b0b59)[0x562230e37b59]
test-library(+0x2b05cc)[0x562230e375cc]
test-library(+0x2a7b9f)[0x562230e2eb9f]
test-library(+0x2a34a4)[0x562230e2a4a4]
test-library(+0x2aac5b)[0x562230e31c5b]
test-library(+0x2aab87)[0x562230e31b87]
test-library(+0x2aa9dd)[0x562230e319dd]
test-library(+0xa71d2)[0x562230c2e1d2]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f6ad2229d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f6ad2229e40]
test-library(+0x4db45)[0x562230bd4b45]
Error Program exited with code -11```

show symbols instead of adresses? I am compiling with `-g 
--d-debug -fsanitize=address`.

Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

On Sunday, 11 February 2024 at 06:43:19 UTC, Per Nordlöw wrote:
 How do I make LDC stacktraces like

 ```test-library(+0x1fb232)[0x562230d82232]

So it turns out that ldc2 doesn't show symbols in stack traces by 
default.

IMHO, in debug mode D should adhere to what other languages do.

Meaning a sane behavior like what

```d
int main(string[] args) {
	import etc.linux.memoryerror : registerMemoryErrorHandler;
	registerMemoryErrorHandler();
	int*x = null;
	*x = 42;
	return 0;
}
```

does when using compiled and run via

```sh
dmd -g -debug -run app
```

gives

```
etc.linux.memoryerror.NullPointerError src/etc/linux/memoryerror.d(322)
----------------
??:? void etc.linux.memoryerror.sigsegvUserspaceProcess(void*) 
[0x55fd3461e4f6]
??:? void etc.linux.memoryerror.sigsegvDataHandler() 
[0x55fd3461e42e]
./app.d:4 _Dmain [0x55fd345e53e6]
```

. Doing the same thing with LDC via

```sh
ldc2 -g --d-debug -run app
```

gives

```
ld: error: undefined symbol: 
_D3etc5linux11memoryerror26registerMemoryErrorHandlerFNbZb
 referenced by app.d:3
               /tmp/objtmp-ldc-dec7a7/app.o:(D main)



collect2: error: ld returned 1 exit status
Error: /usr/bin/cc failed with status: 1
```

.

ryuukk_ <ryuukk.dev gmail.com> writes:

I agree, debug builds should show proper stack trace by default

You should submit a PR for dmd and call what ever is that 
function behind a `debug` block when it hooks the C main function

As for LDC, it's weird that it doesn't work, they should share 
the same runtime no?

Johan <j j.nl> writes:

On Monday, 12 February 2024 at 16:14:27 UTC, Per Nordlöw wrote:
 . Doing the same thing with LDC via

 ```sh
 ldc2 -g --d-debug -run app
 ```

 gives

 ```
 ld: error: undefined symbol: 
 _D3etc5linux11memoryerror26registerMemoryErrorHandlerFNbZb
 referenced by app.d:3
               /tmp/objtmp-ldc-dec7a7/app.o:(D main)



 collect2: error: ld returned 1 exit status
 Error: /usr/bin/cc failed with status: 1
 ```

LDC does not support etc.linux.memoryerror, due to issues with 
it. See:
https://github.com/ldc-developers/ldc/issues/1915

-Johan