Closed
Description
#![feature(macro_rules)]
macro_rules! call2( ($e:expr) => ($e()) )
macro_rules! call( ($e:expr) => (handle(call2!($e))) )
fn bar() {
unsafe {
*(0 as *mut uint) = 0;
}
}
fn foo() {
call!(bar);
}
fn handle(_:()) {}
fn main() {
foo();
} $ rustc foo.rs -g
$ gdb ./foo
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...done.
(gdb) r
Starting program: /home/alex/code/foobar/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
main::bar () at src/main.rs:8
8 *(0 as *mut uint) = 0;
(gdb) bt
#0 main::bar () at src/main.rs:8
#1 0x000055555555f32e in main::foo () at src/main.rs:4
#2 0x000055555555f39e in main::main () at src/main.rs:19
#3 0x00005555555950eb in start::closure.8511 ()
#4 0x00005555555acbfc in rust_try_inner ()
#5 0x00005555555acbe6 in rust_try ()
#6 0x00005555555aa533 in unwind::try::hd12740a912640cc1imd ()
#7 0x00005555555aa3fc in task::Task::run::ha62f1c0aea75bedcWBc ()
#8 0x0000555555594f27 in start::h239c3a425c3165f7ehe ()
#9 0x0000555555594d68 in lang_start::hb36b8d7630529d77xge ()
#10 0x000055555555f3ef in main ()
The line number for the stack frame of main::foo says it's on line 4, when it should actually be lower than that. I have noticed, however, that if there's only one macro (e.g. call2 goes away) the source location is correct. This may be a bug in debuginfo, but it may also be a bug in macros in general (source locations aren't always quite correct I think).